I think people should use all of them. Some problems are much better expressed with logic programming, others with inheritance, others with polymorphic functions.
There is one school which says people ought to be giving a powerful programming language to better write powerful programs in the best way. The idea is to amplify what a single programmer can produce.
Another school says you should give programmers a non-powerful language because they aren’t to be trusted. The goal is to make changing enormous codebases easy (or maybe to maximise lines of code).
Perl fits into the first category and java is representative of the second. So I think this argument isn’t so much about Perl as it is a complaint about its philosophy. It could equally go on an article about the next c++ feature.
Any business problems that can be shown, objectively, to be better solved by one paradigm versus another can also be isolated into its own code base/module where said paradigm is canonical and ubiquitous.
The problem is, this rarely happens and with a language like Perl and Java you end up with a mish mosh of hard to reason about code bases because the authors at the time were just trying to muddle through as best they could with whatever approach resonated with them.
I'd like a definition of "powerful" that is more than just "agrees with my personal prejudices"; Perl lacks the power of a strongly checked type system, for example.
This is what finally killed it for me and Python. I'm inclined to functional programming and writing SQL instead of using an ORM. This was easily possible in Python, but my coworkers would often refer to it as "hacky" even though my tests would show it was more performant than marshaling objects to do a simple transform. My direct lead would often only write imperative code, and one off scripts with very little reuse possible (let alone tools that could be handed off to other team members). Very frustrating.
I find more opinionated languages like Clojure help. On that note, is the title a riff on "Simple Made Easy"?
Your problem was in environment which didn't embrace the ways you like, not that language was multi-paradigm. "I love Python cooked functionally, but my colleagues do only OO" is equivalent to "I love Clojure, but my colleagues do only Java".
I think the problem with almost all mainstream languages today that they are morally outdated. I feel for the next decade the industry will be striving for programming languages optimized either for developer's productivity, for correctness or for the execution performance and/or minimized footprint. Most languages today, including Python and Perl (and many others) sadly are not making progress in any of those directions. That's why programmers are desperately trying to find better ways, jumping from OOP to functional, from dynamically typed to statically typed, creating new frameworks, trying all sorts of hacks to improve concurrency, performance characteristics, etc. Burnout rates are high, and writing software is more complicated than ever. You can literally choose any PL from TIOBE's top 10 and if you get enough expertise - you'd realize that it is nothing but a big clusterfuck of a language.
The whole point of the comment was that Clojure, by and large, forces you to work one way and Python doesn't.
The point of my comment is that it's not true (except in a narrow educational meaning). Your working environment (managers, colleagues, existing codebase) is what defines your limits in general, including language, approach, style, and frameworks. If your current shop can't accept your call to write more functional code in whatever language is used there, it obviously won't start developing in Clojure. It works exactly this way, not in the opposite direction. Ergo, the guy's problem was that his environment wasn't inclined to switch from OO. He couldn't say "Mates, let's use Clojure, because it will finally FORCE you to discover the beautiful world of FP", because they just want to keep doing what they were doing yesterday.
Fixed that for you.
It's not a correction, and I hope you see now what I mean.
You have a point, but coming to a consensus within a working environment can lead to a lot of friction and politics.
Sadly also software is hardly ever one working environment. In Python, the libraries are a strong feature, and each library will have different contributors. Each with their own opinion on what is the most effective programming style.
Take Python's Django framework for an example, it contains both OO and functional ways of doing most things. This can be confusing for newcomers who just want to know what is the best methodology going forward. One of the key features of using a framework is it allows you to add new developers to your project and they will know how to get things done.
Clojure is kinda unique. It minimizes vector of frustration by merely not allowing needless garbage. Commas are the whitespace - totally makes sense. No bullshit stuff like semicolons. How many precedence rules are there, for example in Javascript? Like 19. In Scala? 14. In Clojure? Zero. How many things in Javascript can be falsy? (evaluate to false) - Seven. In Clojure - only two. How many reserved words there in Javascript? 64! How many in Clojure? Zero. Yes, that's right: there are no reserved words in Clojure. Do you know how many rules are there in ESLint? A lot! In contrast, Clojure teams have to agree to a single styleguide rule - either they align things or indent them - and that's it.
Does that all make Clojure less powerful than other languages? It turns out it, actually that makes it a lot more fun to work with. So yes, I agree with you, the article takes "Simple Made Easy" and turns it upside down. That talk is absolutely not about what was demonstrated in the article.
Frankly speaking its surprising Perl 6 hasn't taken off yet. Its a language which has Java like potential. Not sure where the efficiency/speed story has gone so far(Which was preventing adoption?). But pretty much any one I have shown the language has been floored by it so far.
More people are writing Perl everyday than may be even Java, Let's put this Perl is dwindling argument to rest. Perl's niche, more like empire is glue language for anything Unix. That is a huge empire to govern on. Unless Unix is going away, Perl is here to stay.
>> 5) Perl in general doesn't have a good "name" with todays devs
>> Node got the web/services niche
Most dynamic languages are in the same bucket. Today everybody is hesitant to start any serious big project in a dynamic programming language. Even in case of JavaScript most things will move to TypeScript eventually. And that too is more or less a totally new language.
>>Go got the backend niche
Go got nothing. Heck, merely shell scripting exceeds Go usage by several multiplicative factors.
>> 7) Python got the data/science niche
Most of the use case for Python's 'Data science' library is basically spread sheet automation. Perl has been used to that kind of work since early 90s.
>>what's left for Perl 6?
Firstly, and entire universe exists outside of web development. And most that universe is far more exciting than majority of api and json plumbing work in web dev work.
Secondly, Not sure, but no one can rebut an argument that says there is no scope for any new software to be ever written anymore.
>More people are writing Perl everyday than may be even Java, Let's put this Perl is dwindling argument to rest.
Err, that's just a link to a submissions page. That's not a statistic, and it doesn't even show if Perl kept its people or lost them. Perl could even have more people than 1999, but much smaller mindshare given how hugely larger the dev market is in 2019 vs 1999.
Actual long term analysis look like "Perl is dwindling" is right:
>Perl's niche, more like empire is glue language for anything Unix. That is a huge empire to govern on.
And that "empire" is already lost for Perl. Dev ops have moved to Ansible, Puppet, Chef, etc, and Python and other languages are used as the glue. The "Perl gluing admin" is a relic.
>Most of the use case for Python's 'Data science' library is basically spread sheet automation. Perl has been used to that kind of work since early 90s.
Which is irrelevant as to who does it now (and it's not even right, Pandas, Numpy and co are not "spread sheet automation").
>Most dynamic languages are in the same bucket. Today everybody is hesitant to start any serious big project in a dynamic programming language.
Actually millions start serious big projects in JS, Python and other dynamic languages. There's a movement towards static typing but not that strong in actual practice. Typescript is tiny compared to the size of greenfield JS being written.
>Firstly, and entire universe exists outside of web development. And most that universe is far more exciting than majority of api and json plumbing work in web dev work.
Also far smaller, devs wise. And I didn't just mention web work, but also data science, microservices, and so on.
(And my point wasn't that Perl 6 can't do those, but that people aren't doing those with Perl 6 -- people as in, "people in quantities large enough to matter").
> So it's a kind of research language - which is important and has its place
I'd rather say that Perl 6 is an inspirational language. With other languages stealing ideas and features from it. But also a complete, production ready language on its own. Based on MoarVM, a virtual machine specifically designed to run Perl 6 on, but with more general applicability as well.
And with some exciting developments for the GSOC: one of which should allow creation of a single executable for a Perl 6 application on Linux / MacOS and Windows.
- grammars, mutable at that
- simple declarative class definitions
- easy to use async primitives
- easy to use event driven primitives
- unicode support based on graphemes
Have you looked at Cro? Cro is a set of libraries for building reactive distributed systems taking advantage of all Perl 6 has to offer. The high level APIs make the easy things easy, and the asynchronous pipeline concept at Cro's heart makes the hard things possible. https://cro.services . With HTTP/1.1 / HTTPS, HTTP/2.0 and Web Sockets support out the box.
> 10) Maturity of implementation, tooling, support, etc.
Comma is an IDE for Perl 6, based on the JetBrains platform, with detailed syntax highlighting, grammar support, auto-completion, refactoring support, integrated test runner / graphical debugger, stack explorer and direct profiling. https://commaide.com
>*
Have you looked at Cro? Cro is a set of libraries for building reactive distributed systems taking advantage of all Perl 6 has to offer. The high level APIs make the easy things easy, and the asynchronous pipeline concept at Cro's heart makes the hard things possible. https://cro.services . With HTTP/1.1 / HTTPS, HTTP/2.0 and Web Sockets support out the box.*
None of that seems "killer app", or anything more impressive than what e.g. Node or Golang offer out of the box...
One person posted to #perl6 on freenode.net code written in both Perl6 and C/C++. They reported that the Perl6 code was faster. (I'm sure that the difference is mainly because the C/C++ code had to copy strings around, and iterate over them to locate the null terminators.)
Unless you are doing something where you might consider writing parts of it in assembly, Perl6 may be fast enough already. (I wouldn't write a first person shooter in it yet.)
There are some parts of it that are still in need of optimization. (If you find something that is egregiously slow, file a bug report.)
Startup time is still egregiously slow compared to Perl 5. But, that couldn't be a major determining factor for people working in languages that are also slow to start (of which there are many, probably one could say most are slower than Perl 5). And, it's not a major concern for long-running applications and services, but for one-liners it feel sluggish.
If you realize that Perl 6 basically has Moose in its core, and you compare startup time of Perl 5 with Moose with Perl 6, then it's not that bad at all:
$ time perl6 -e ''
real 0m0.120s
$ time perl -MMoose -e ''
real 0m0.131s
And that's without all of the fancy type checking stuff of several Moose plugins that comes standard with Perl 6.
So in that sense, if you are interested in Moose functionality, you're better of in Perl 6.
Those are all Perl 5 techs though – somewhat usable (or partially reimplemented) in Perl 6, but having written both for a living the Perl 6 ones are still way, way behind.
I do agree that Perl 6 could use some framework. But then Go did not need one to take off so I'm definitely not convinced it would help.
Perl 6 is an entirely different language though - IMHO a mistake to call it Perl at all, it's just so confusing outside of the community, but the damage is done with no obvious way to fix that, making people think it's kind of a Python 2 to Python 3 breaking change - so it's like saying Crystal does not run Rails.
One has to think of it as 'Perl6', not 'Perl v6.0'. Perl (the language whose current version is 5.22) is very much alive and will continue to be so for the foreseeable future, regardless of progress of 'Rakudo Perl 6'.
> using all-lowercase letters for the compiler and title case for the language
'rakudo' is an implementation of 'Rakudo', huh? It's only natural for one to tag the specification and an implemention of it with different nouns in one's mind, even when there's only one implementation. I tend to think of 'go' being the reference implementation of the language called 'Golang', although its Google backers don't differentiate their official names.
> 'rakudo' is an implementation of 'Rakudo', huh? It's only natural for one to tag the specification and an implemention of it with different nouns in one's mind
I get your point theoretically, yet this is not without significant previous occurences: from the top of my head 'Java', 'Ruby', 'Python', 'Go', 'Lua' the languages have 'java', 'ruby', 'python', 'go', 'lua' as the official implementations†. Alternative names for the implementations are merely informal. People even still call the official Ruby implementation 'MRI' when it's not that anymore ever since 1.9 (It's actually YARV or KRI). TBH 'Golang' is more of a search engine hack.
Regarding Perl 6 they could have done so too, but they locked in on theory and wanted to leverage Perl's heritage, which backfired hard. IMHO had they done some initial announcement like "Meet Rakudo, Perls' heir", they would have achieved the same goal with none of the drawbacks. Now the community web has built itself around the Perl 6 name so it's too late.
† I'm perfectly aware that there are significant other examples though, like Common Lisp, Haskell, C, C++ that make that distinction. But then again, many of those implementations turn out to have specifics implemented that turns the actual implementation into a slight to extensive variant of the language, which turns into its own bag of hurts. Naming things definitely is Hard.
oh wow, the "say" keyword is quite nifty. also, straightforward iterative solutions often lead to inefficient implementations. which is why most of us fall prey to complicated implementations that use all the tricks in the book... i don't know much about perl anymore, but in some languages, creating a new date object every time through that loop might not be space efficient.
The magic isn't really in say. say is just print with an automatic linefeed at the end (and, two fewer keystrokes for the keyword). Perl's print (even in very old versions of Perl, dating long before say arrived) also accepts expressions as arguments, so you can write: `print join "\n", @array;`
Obviously, the Date (and other) type stuff is new to Perl 6, and is quite lovely.
>Perl's print (even in very old versions of Perl, dating long before say arrived) also accepts expressions as arguments, so you can write: `print join "\n", @array;`
How's that different from any other language? Isn't the expression argument evaluated before being passed to print, so at that point it's just a string anyway?
>>> print ", ".join(["a","b","c"])
a, b, c
Or, if the point is about omitting the automatic newline, comma in python suppresses it:
Mostly I was just saying that `say` isn't the interesting bit of the examples given. But, sure, Perl is nice in how flexible/expressive it is (and Perl 6 takes that even further). I think maybe that's even the most interesting thing about the article. I mean, the date math is super cool and impressive and elegant, but the various paradigm examples is maybe more fun for me, since munging dates is rarely a thing I do.
TIMTOWTDI can get out of hand, at times, but it's really nice to have such beautiful concise ways to solve a problem in OO, functional, parallel, etc. styles all of which are very readable and quite concise.
I think a more relevant title for this post would be: "any paradigm made straightforward in Perl 6".
The problem with this: if you give people a multi-paradigm language, they'd be using all of them. Often in the same codebase.
There is one school which says people ought to be giving a powerful programming language to better write powerful programs in the best way. The idea is to amplify what a single programmer can produce.
Another school says you should give programmers a non-powerful language because they aren’t to be trusted. The goal is to make changing enormous codebases easy (or maybe to maximise lines of code).
Perl fits into the first category and java is representative of the second. So I think this argument isn’t so much about Perl as it is a complaint about its philosophy. It could equally go on an article about the next c++ feature.
The problem is, this rarely happens and with a language like Perl and Java you end up with a mish mosh of hard to reason about code bases because the authors at the time were just trying to muddle through as best they could with whatever approach resonated with them.
I find more opinionated languages like Clojure help. On that note, is the title a riff on "Simple Made Easy"?
Fixed that for you. The whole point of the comment was that Clojure, by and large, forces you to work one way and Python doesn't.
The point of my comment is that it's not true (except in a narrow educational meaning). Your working environment (managers, colleagues, existing codebase) is what defines your limits in general, including language, approach, style, and frameworks. If your current shop can't accept your call to write more functional code in whatever language is used there, it obviously won't start developing in Clojure. It works exactly this way, not in the opposite direction. Ergo, the guy's problem was that his environment wasn't inclined to switch from OO. He couldn't say "Mates, let's use Clojure, because it will finally FORCE you to discover the beautiful world of FP", because they just want to keep doing what they were doing yesterday.
Fixed that for you.
It's not a correction, and I hope you see now what I mean.
Sadly also software is hardly ever one working environment. In Python, the libraries are a strong feature, and each library will have different contributors. Each with their own opinion on what is the most effective programming style.
Take Python's Django framework for an example, it contains both OO and functional ways of doing most things. This can be confusing for newcomers who just want to know what is the best methodology going forward. One of the key features of using a framework is it allows you to add new developers to your project and they will know how to get things done.
Does that all make Clojure less powerful than other languages? It turns out it, actually that makes it a lot more fun to work with. So yes, I agree with you, the article takes "Simple Made Easy" and turns it upside down. That talk is absolutely not about what was demonstrated in the article.
Never mind that functional and imperative programming have been attached to OO languages since at least SmallTalk…
I guess a killer framework is lacking too.
1) The Perl 5 community itself was dwindling before Perl 6.
2) Perl 6 took a good chunk of time to arrive.
3) It's still not 100% baked.
4) Perl 6 is mostly a different language.
5) Perl in general doesn't have a good "name" with todays devs
6) There's no killer app
7) Python got the data/science niche, Node got the web/services niche, Go got the backend niche - what's left for Perl 6?
8) The libs are also lacking.
9) Too complex to begin with (kitchen sink offering), at a time when devs started valuing simplicity more than before.
10) Maturity of implementation, tooling, support, etc.
11) No major commercial backing...
https://metacpan.org/recent
More people are writing Perl everyday than may be even Java, Let's put this Perl is dwindling argument to rest. Perl's niche, more like empire is glue language for anything Unix. That is a huge empire to govern on. Unless Unix is going away, Perl is here to stay.
>> 5) Perl in general doesn't have a good "name" with todays devs >> Node got the web/services niche
Most dynamic languages are in the same bucket. Today everybody is hesitant to start any serious big project in a dynamic programming language. Even in case of JavaScript most things will move to TypeScript eventually. And that too is more or less a totally new language.
>>Go got the backend niche
Go got nothing. Heck, merely shell scripting exceeds Go usage by several multiplicative factors.
>> 7) Python got the data/science niche
Most of the use case for Python's 'Data science' library is basically spread sheet automation. Perl has been used to that kind of work since early 90s.
>>what's left for Perl 6?
Firstly, and entire universe exists outside of web development. And most that universe is far more exciting than majority of api and json plumbing work in web dev work.
Secondly, Not sure, but no one can rebut an argument that says there is no scope for any new software to be ever written anymore.
Err, that's just a link to a submissions page. That's not a statistic, and it doesn't even show if Perl kept its people or lost them. Perl could even have more people than 1999, but much smaller mindshare given how hugely larger the dev market is in 2019 vs 1999.
Actual long term analysis look like "Perl is dwindling" is right:
https://insights.dice.com/2018/04/05/perl-uncertain-future-t...
>Perl's niche, more like empire is glue language for anything Unix. That is a huge empire to govern on.
And that "empire" is already lost for Perl. Dev ops have moved to Ansible, Puppet, Chef, etc, and Python and other languages are used as the glue. The "Perl gluing admin" is a relic.
>Most of the use case for Python's 'Data science' library is basically spread sheet automation. Perl has been used to that kind of work since early 90s.
Which is irrelevant as to who does it now (and it's not even right, Pandas, Numpy and co are not "spread sheet automation").
>Most dynamic languages are in the same bucket. Today everybody is hesitant to start any serious big project in a dynamic programming language.
Actually millions start serious big projects in JS, Python and other dynamic languages. There's a movement towards static typing but not that strong in actual practice. Typescript is tiny compared to the size of greenfield JS being written.
>Firstly, and entire universe exists outside of web development. And most that universe is far more exciting than majority of api and json plumbing work in web dev work.
Also far smaller, devs wise. And I didn't just mention web work, but also data science, microservices, and so on.
(And my point wasn't that Perl 6 can't do those, but that people aren't doing those with Perl 6 -- people as in, "people in quantities large enough to matter").
>>Dev ops have moved to Ansible, Puppet, Chef, etc, and Python and other languages are used as the glue.
This is glue? Sorry but we seem to come from very different worlds.
>>Also far smaller, devs wise.
Wow, Just wow!
You probably won't like to hear this, but this how most of the software world works:
1. C based backend language: Java. C Based embedded/speed requirement systems: C/C++
2. Glue: Shell/Perl
3. Web dev: Node, Java(Webservices)
4. Lisp Based languages backend: Clojure/Racket.
5. ML based languages backend: F#, OCaml, Haskell.
6. Database: SQL.
There are other special languages which rule their domain. But this is how bulk of the world works.
Data science area is still a extremely small part of even the web dev world, let alone the broader software ecosystem.
Imagine a start-up that didn't set out to solve a problem...
So it's a kind of research language - which is important and has its place.
I'd rather say that Perl 6 is an inspirational language. With other languages stealing ideas and features from it. But also a complete, production ready language on its own. Based on MoarVM, a virtual machine specifically designed to run Perl 6 on, but with more general applicability as well.
And with some exciting developments for the GSOC: one of which should allow creation of a single executable for a Perl 6 application on Linux / MacOS and Windows.
What ideas have come out of Perl 6?
Have you looked at Cro? Cro is a set of libraries for building reactive distributed systems taking advantage of all Perl 6 has to offer. The high level APIs make the easy things easy, and the asynchronous pipeline concept at Cro's heart makes the hard things possible. https://cro.services . With HTTP/1.1 / HTTPS, HTTP/2.0 and Web Sockets support out the box.
> 10) Maturity of implementation, tooling, support, etc.
Comma is an IDE for Perl 6, based on the JetBrains platform, with detailed syntax highlighting, grammar support, auto-completion, refactoring support, integrated test runner / graphical debugger, stack explorer and direct profiling. https://commaide.com
None of that seems "killer app", or anything more impressive than what e.g. Node or Golang offer out of the box...
13) perl6 is above most mainstream languages conceptually, people aren't ready to use it IMO
One person posted to #perl6 on freenode.net code written in both Perl6 and C/C++. They reported that the Perl6 code was faster. (I'm sure that the difference is mainly because the C/C++ code had to copy strings around, and iterate over them to locate the null terminators.)
Unless you are doing something where you might consider writing parts of it in assembly, Perl6 may be fast enough already. (I wouldn't write a first person shooter in it yet.)
There are some parts of it that are still in need of optimization. (If you find something that is egregiously slow, file a bug report.)
So in that sense, if you are interested in Moose functionality, you're better of in Perl 6.
Perl 6 is an entirely different language though - IMHO a mistake to call it Perl at all, it's just so confusing outside of the community, but the damage is done with no obvious way to fix that, making people think it's kind of a Python 2 to Python 3 breaking change - so it's like saying Crystal does not run Rails.
One has to think of it as 'Perl6', not 'Perl v6.0'. Perl (the language whose current version is 5.22) is very much alive and will continue to be so for the foreseeable future, regardless of progress of 'Rakudo Perl 6'.
https://perl6.party/post/The-Hot-New-Language-Named-Rakudo
'rakudo' is an implementation of 'Rakudo', huh? It's only natural for one to tag the specification and an implemention of it with different nouns in one's mind, even when there's only one implementation. I tend to think of 'go' being the reference implementation of the language called 'Golang', although its Google backers don't differentiate their official names.
I get your point theoretically, yet this is not without significant previous occurences: from the top of my head 'Java', 'Ruby', 'Python', 'Go', 'Lua' the languages have 'java', 'ruby', 'python', 'go', 'lua' as the official implementations†. Alternative names for the implementations are merely informal. People even still call the official Ruby implementation 'MRI' when it's not that anymore ever since 1.9 (It's actually YARV or KRI). TBH 'Golang' is more of a search engine hack.
Regarding Perl 6 they could have done so too, but they locked in on theory and wanted to leverage Perl's heritage, which backfired hard. IMHO had they done some initial announcement like "Meet Rakudo, Perls' heir", they would have achieved the same goal with none of the drawbacks. Now the community web has built itself around the Perl 6 name so it's too late.
† I'm perfectly aware that there are significant other examples though, like Common Lisp, Haskell, C, C++ that make that distinction. But then again, many of those implementations turn out to have specifics implemented that turns the actual implementation into a slight to extensive variant of the language, which turns into its own bag of hurts. Naming things definitely is Hard.
s/5.22/5.30/
However, I'm not sure having to parse 3-4 very different syntax constructs to arrive at the same mental model is an advantage.
I do appreciate the terseness though.
Obviously, the Date (and other) type stuff is new to Perl 6, and is quite lovely.
How's that different from any other language? Isn't the expression argument evaluated before being passed to print, so at that point it's just a string anyway?
Or, if the point is about omitting the automatic newline, comma in python suppresses it:It's true for all perl functions. Unusual part, if I got you right, is that parenthesis are optional in perl. So, this:
is equivalent to: (unless bar has ($) prototype, anyway; but then it all gets ambiguous)TIMTOWTDI can get out of hand, at times, but it's really nice to have such beautiful concise ways to solve a problem in OO, functional, parallel, etc. styles all of which are very readable and quite concise.
Though that is more about time optimization than space optimization.