Perl 6 Optimism(p6weekly.wordpress.com)
p6weekly.wordpress.com
Perl 6 Optimism
https://p6weekly.wordpress.com/2018/01/22/2018-04-its-time-for-optimism/
231 comments
Pretty much. I used to use Perl 5 a lot but I never considered using Perl 6 and eventually moved on from the Perl ecosystem altogether. The huge advantage of Perl ~10 years ago was the massive amount of CPAN packages but in the meantime python & friends mostly caught up in my experience.
Meanwhile the shiny new revolutionary Perl 6 took forever to release and when it finally did nobody cared anymore. Quoting Wikipedia:
>The design process for Perl 6 began in 2000. [...] on December 25, 2015, the first stable version of the specification was announced.
I can respect taking the time to do things right but when your development history resembles that of Duke Nukem Forever something is off. That in my opinion hurt Perl more than anything else, even more so than the lack of compatibility between Perl 5 and Perl 6. If Perl 6 had released in early-to-mid 2000 I think there would've been enough interest out there to bridge the gap. It would've been messy but it could've worked.
Instead Perl 5 felt a bit like a legacy language "while we wait for Perl 6 to be finished" and Perl 6 was nowhere to be found. And Perl went from the de-facto scripting language for un*x to people asking "Is Rakudo Perl 6 used in production?".
Meanwhile the shiny new revolutionary Perl 6 took forever to release and when it finally did nobody cared anymore. Quoting Wikipedia:
>The design process for Perl 6 began in 2000. [...] on December 25, 2015, the first stable version of the specification was announced.
I can respect taking the time to do things right but when your development history resembles that of Duke Nukem Forever something is off. That in my opinion hurt Perl more than anything else, even more so than the lack of compatibility between Perl 5 and Perl 6. If Perl 6 had released in early-to-mid 2000 I think there would've been enough interest out there to bridge the gap. It would've been messy but it could've worked.
Instead Perl 5 felt a bit like a legacy language "while we wait for Perl 6 to be finished" and Perl 6 was nowhere to be found. And Perl went from the de-facto scripting language for un*x to people asking "Is Rakudo Perl 6 used in production?".
Yeah... sometime around 2007 or so they finally admitted as much and started updating Perl 5 more regularly. But it's been a ridiculous journey. No project that starts out to rewrite a long-established and entrenched piece of software from the ground up ever ends up being a smooth transition. It's best to admit as soon as it's clear what's happening that you are doing something entirely new, and let the old project live out its own lifecycle.
What I've heard about Perl 6 does sound intriguing, and probably a solid language platform does take a good decade-plus to get on solid footing. But re-using the name of a once-well-loved and established language is a bad move for both the old and the new versions.
What I've heard about Perl 6 does sound intriguing, and probably a solid language platform does take a good decade-plus to get on solid footing. But re-using the name of a once-well-loved and established language is a bad move for both the old and the new versions.
The progress on Perl 5 has been remarkable too. Complex data structures no longer require you to wave a dead chicken and spelunk through StackExchange for hours. Unicode just works most of the time. Useful new features appear in the language, even though you would rightfully expect it to be in maintenance mode.
> Complex data structures no longer require you to wave a dead chicken
Do you have a reference on changes to data structure syntax in 5.x? Probably my biggest frustration was trying to use anything beyond a scalar list - it always ended up a mess of hashrefs.
Do you have a reference on changes to data structure syntax in 5.x? Probably my biggest frustration was trying to use anything beyond a scalar list - it always ended up a mess of hashrefs.
Mostly it is deref operators being smarter now so you don't have to wrap everything in curly braces to get it to dereference properly.
> It's best to admit as soon as it's clear what's happening that you are doing something entirely new
Larry said something similar on day one.
> and let the old project live out its own lifecycle.
Larry did exactly that. It's still living out its own lifecycle and will for another N decades.
> re-using the name of a once-well-loved and established language is a bad move for both the old and the new versions.
I agree that this has likely turned out to be the case for Perl 6.
Larry said something similar on day one.
> and let the old project live out its own lifecycle.
Larry did exactly that. It's still living out its own lifecycle and will for another N decades.
> re-using the name of a once-well-loved and established language is a bad move for both the old and the new versions.
I agree that this has likely turned out to be the case for Perl 6.
Perl 6 seems to have one of the worst cases of the second system effect in modern history. It didn't help that Larry Wall got sick halfway through the development either.
As a Perl 5 developer, I look at it and go "If I have to learn a new language I might as well make it a popular one like Python 3 or Rust."
As a Perl 5 developer, I look at it and go "If I have to learn a new language I might as well make it a popular one like Python 3 or Rust."
Python - ok, but Rust? How many Rust jobs do you see posted on major job sites?
Python will get you a job today, but Rust may well be more valuable in the future. Or it may be a flash in the pan that never catches on in a big way. The future is hard to predict.
I always find this logic a little troublesome; there are certainly many more Python jobs than Rust, but there are also many more Python programmers than Rust programmers. Wouldn't it make sense to optimize for the best ratio of available jobs to qualified applicants rather than just the largest number of available jobs? (I'm not saying that the ratio is better for Rust, just that the metric itself being used seems flawed).
Of course, there are also reasons to learn a programming language beyond job listings; GP might work on things that don't require a specific language, be looking for a language for dude projects, or just want to learn a language for fun.
Of course, there are also reasons to learn a programming language beyond job listings; GP might work on things that don't require a specific language, be looking for a language for dude projects, or just want to learn a language for fun.
The failure to admit it was going slowly was another killer. It will be released at Christmas, we just aren't telling you which one. After a few years of hoping, I gave up and am in the world of Python and Django. Its a shame as Perl feels like a more powerful / expressive language than Python.
I'm one that moved to Python and don't want to look back. It is not that Python is easier read (I would say it is less noisy) but it is almost impossible to write your own "DSL" like you can do with Perl or Ruby.
YMMV but for me this is what makes it easy to maintain: you just need to learn Python not the personal programming style of the previous developer.
YMMV but for me this is what makes it easy to maintain: you just need to learn Python not the personal programming style of the previous developer.
If you have such a strong preference for Python isn't it fair to say that any version of Perl - 5 or 6 - wouldn't be right for you as Perl falls on the expressive end of the language spectrum like Ruby and Clojure? You could have left Perl for Python before Perl 6 was even invented.
Of course, the Perl 5/6 soap opera was not the reason for jumping the ship.
10 years ago RIA platforms were the rage (Silverlight, Flex). By this time I was working in operations but willing to switch career to software development. Finally the opportunity presented and I picked OpenLazlo and PHP/MySQL. Two weeks later it was clear that I would not be able to meet the deadline using this platform. I googled for something like "productive web frameworks" and the top entries were about Rails, followed by Django. I could not make Rails work on my local development environment but the the Django tutorial worked like a charm.
So the truth is that I started using Python more seriously because I was not smart enough to make through the Rails tutorial. But no complaints - Python/Django is paying my rent since then!
10 years ago RIA platforms were the rage (Silverlight, Flex). By this time I was working in operations but willing to switch career to software development. Finally the opportunity presented and I picked OpenLazlo and PHP/MySQL. Two weeks later it was clear that I would not be able to meet the deadline using this platform. I googled for something like "productive web frameworks" and the top entries were about Rails, followed by Django. I could not make Rails work on my local development environment but the the Django tutorial worked like a charm.
So the truth is that I started using Python more seriously because I was not smart enough to make through the Rails tutorial. But no complaints - Python/Django is paying my rent since then!
Generally, yes, but at least in organizations you can enforce some style. The problem definitely arises (and often) when you can't write and enforce that standard. Python and Perl definitely have diametrically opposed philosophies on that front.
This.
Being "forced to use Python" sucks as a Perl developer.
Being "forced to use Python" sucks as a Perl developer.
The only thing I miss about Perl was the immediacy of the regexes. There's a LOT I won't miss.
If you want that regex behaviour in a more modern language than Perl5 then Ruby is there.
If you want that regex behaviour in a more modern language than Perl5 then Ruby is there.
On the flip side, being forced to use Perl always sucks.
I mean it only as a half joke, unfortunately.
I mean it only as a half joke, unfortunately.
I would love to be forced to use Perl :)
As a side note, "forced" often means "we have a lot of beginners here and they want to do Python".
As a side note, "forced" often means "we have a lot of beginners here and they want to do Python".
Find a job maintaining some legacy code (there's plenty of it there). At which point you'll quickly realise that maintaining a complex perl program (particularly that someone else wrote) is painful. And the only remaining production perl programs are complex or they would have been rewritten.
I would not mind actually.
Better than rewriting failing Python or Node projects once a year.
Better than rewriting failing Python or Node projects once a year.
The worst parts are the conversations of the form: Would you use something like perl for this? Why not? Python has 100% of the “write only” problems you mention, except that there are less syntactic clues to help the reader.
sigh
(And for the record, I’ve dealt with 100K+ sloc perl and python projects, and the perl one was more maintainable than the python projects, even after multiple python rewrites. It doesn’t have to go that way, but it certainly can!)
sigh
(And for the record, I’ve dealt with 100K+ sloc perl and python projects, and the perl one was more maintainable than the python projects, even after multiple python rewrites. It doesn’t have to go that way, but it certainly can!)
Better than Java or VB by a long way. You can do most stuff just not as cryptically.
I agree, it definitely hurt mainline Perl development when Perl 6 was this promised great new thing. At least Perl 5 never got abandoned, and there is development and bugfixing still going on today.
Perl 5 has a feeling of being 'complete' as a language. I guess this makes it unsexy and it'll never be the cutting edge where all the cool devs want to work, but it's rock solid stable and reliable.
Now, if only Perl 5 could get a JIT compiler...
Perl 5 has a feeling of being 'complete' as a language. I guess this makes it unsexy and it'll never be the cutting edge where all the cool devs want to work, but it's rock solid stable and reliable.
Now, if only Perl 5 could get a JIT compiler...
> Now, if only Perl 5 could get a JIT compiler...
Perl 5 running as a slang on MoarVM or JVM would give it a JIT compiler
Perl 5 running as a slang on MoarVM or JVM would give it a JIT compiler
If only language completeness was all that mattered. Module ecosystem health and community matter a lot more in the rise and fall of languages and CPAN now has a lot of unmaintained modules due to Perl's dwindling community. Languages themselves don't really decline once they've reached maturity.
> I guess this makes it unsexy
Nah, what makes it unsexy is the Perl syntax. The world has moved on. The readability of modern languages like Python is on another level.
Nah, what makes it unsexy is the Perl syntax. The world has moved on. The readability of modern languages like Python is on another level.
The "readability of Python" meme always strikes me as an appeal to mediocre programmers who can't be bothered to learn a full-featured language. It's like trying to avoid musical notation in the teaching of musicians for fear it'll get too complicated for the poor student. Can you imagine a civil engineer being spared the discipline of physics and maths? In which other professional discipline does one expect the language to be dumbed down to the size of the student's brain instead of requiring the student to raise his/her game to gain mastery of the subject?
I disagree. To me Perl is more readable than Python. What is so modern about Python? It was released in 1991.
>>To me Perl is more readable than Python.
There's a phrase I never thought I'd see.
There's a phrase I never thought I'd see.
Compared to Perl, the overall under-use of special characters and the forced indentation make it objectively more readable; there is a reason it's often compared to pseudocode.
Age of release is a meaningless metric, btw. For starters, what Python was in 1991 is very different from what it was in the early 2000s, when it reached critical mass. Its modernity is measurable by the influence it had on most languages designed after its success, like Go and Swift.
Age of release is a meaningless metric, btw. For starters, what Python was in 1991 is very different from what it was in the early 2000s, when it reached critical mass. Its modernity is measurable by the influence it had on most languages designed after its success, like Go and Swift.
To me python and perl and two extremes. Perl is almost comical with its use of special characters (which they've embraced even more in Perl 6 with the optional use of unicode symbols in built-in operators) but python went too far the other way IMO. "It looks like pseudocode" sounds nice in theory but people don't typically write huge projects in pseudocode. I don't really like the significant indentation but my main problem is with the awkward scoping rules. I also find that it makes it harder to refactor code (if I copy/paste a snippet at a different level of indentation I can't blindly trust the editor to re-indent it properly).
That being said I agree that these days the tendency across all languages is to go towards fewer special characters, not more. In this context Perl 6's syntax feels a bit anachronistic.
Maybe you'll be able to win a few new user by telling them that in Perl 6 they can use × for *, Ⅻ for 12 and [unicode atom symbol]++ (ironically HN automatically removes the actual symbol when I submit) for atomic incrementation but I expect that many more will recoil in horror. I won't even talk about »=» and the ascii equivalent >>[=]>>.
That being said I agree that these days the tendency across all languages is to go towards fewer special characters, not more. In this context Perl 6's syntax feels a bit anachronistic.
Maybe you'll be able to win a few new user by telling them that in Perl 6 they can use × for *, Ⅻ for 12 and [unicode atom symbol]++ (ironically HN automatically removes the actual symbol when I submit) for atomic incrementation but I expect that many more will recoil in horror. I won't even talk about »=» and the ascii equivalent >>[=]>>.
> That being said I agree that these days the tendency across all languages is to go towards fewer special characters, not more. In this context Perl 6's syntax feels a bit anachronistic.
This is just a comeback of a recurring dumb trend based on the fallacy that describing the operations of a program using English words is always superior to using appropriate specialized notation. The core of the fallacy is assuming that because something looks like a familiar English word, people who do not understand programming will understand the corresponding semantics of the operation in the programming language, because they know English. Which is complete nonsense - people who do not understand programming will reason by analogy, and through trial and error end up at a partially wrong and misguided understanding of that operation. English words only start you off with unnecessary baggage in the learning process.
It is even worse for people who already know programming. A C for loop is not a JavaScript for loop is not a Python for loop... The details of their semantics are very different, and you will introduce bugs if you just assume "I know how for loops work!"
There is nothing new about this trend either; it was the central premise behind COBOL, and a big motivation for BASIC. What BASIC was in the 1980s, Python is today.
What is ironic about this trend resurfacing today is that it has never been easier to use special characters - Unicode is everywhere, and even making custom keyboards has turned from a major manufacturing endeavor to an accessible hobby: https://www.youtube.com/watch?v=uk3A41U0iO4
This is just a comeback of a recurring dumb trend based on the fallacy that describing the operations of a program using English words is always superior to using appropriate specialized notation. The core of the fallacy is assuming that because something looks like a familiar English word, people who do not understand programming will understand the corresponding semantics of the operation in the programming language, because they know English. Which is complete nonsense - people who do not understand programming will reason by analogy, and through trial and error end up at a partially wrong and misguided understanding of that operation. English words only start you off with unnecessary baggage in the learning process.
It is even worse for people who already know programming. A C for loop is not a JavaScript for loop is not a Python for loop... The details of their semantics are very different, and you will introduce bugs if you just assume "I know how for loops work!"
There is nothing new about this trend either; it was the central premise behind COBOL, and a big motivation for BASIC. What BASIC was in the 1980s, Python is today.
What is ironic about this trend resurfacing today is that it has never been easier to use special characters - Unicode is everywhere, and even making custom keyboards has turned from a major manufacturing endeavor to an accessible hobby: https://www.youtube.com/watch?v=uk3A41U0iO4
Special characters, clear visual markers of scope etc. that Python lacks is part of the appeal of Perl to me.
I feel like a dyslectic when I read Python (projects of significant size) due to it being much less visually helpful and that the idea of simplicity falls apart when the problems are not trivial and when multiple devs have touched the code over multiple years.
YMMV of course but that is why your POV is not objective and I disagree.
I feel like a dyslectic when I read Python (projects of significant size) due to it being much less visually helpful and that the idea of simplicity falls apart when the problems are not trivial and when multiple devs have touched the code over multiple years.
YMMV of course but that is why your POV is not objective and I disagree.
The visual marker of scope is there and it's massive: indentation.
You can write bad code in every syntax, but when a language carries jokes about being "write-only" and the other has a reputation for being anal about indentation (the single most helpful scope-marker in any syntax), I don't think you can argue about objectivity when discussing readability.
This said, I'd like to see scientific comparisons, which are lacking. Some studies suggest terse languages using more special characters are more readable to experienced programmers than ones with simpler syntax, which seems to match your experience. That might well be true; but when applied to the real world, this still means than only a minority will ever prefer that style over a simpler one. As the number of coders naturally rises, this will only become more and more true over time.
You can write bad code in every syntax, but when a language carries jokes about being "write-only" and the other has a reputation for being anal about indentation (the single most helpful scope-marker in any syntax), I don't think you can argue about objectivity when discussing readability.
This said, I'd like to see scientific comparisons, which are lacking. Some studies suggest terse languages using more special characters are more readable to experienced programmers than ones with simpler syntax, which seems to match your experience. That might well be true; but when applied to the real world, this still means than only a minority will ever prefer that style over a simpler one. As the number of coders naturally rises, this will only become more and more true over time.
If Python's identation-based scope is so obvious why does the language have to resort to "global" and "nonlocal" all over the place? Python is a crippled language hiding behind a veil of readability.
Bro, literally every language does indentation. Python just does indentation badly by making it syntactically significant.
Also. If you're going to come back to me with the argument that it forces people to use indentation, I've got some news for you. Literally everyone uses indentation. And if you somehow come across code written by the rare soul that doesn't use indentation, all I've to do is select the entire code and click "re-indent". Which, btw, in python is a chore to fix badly indented code with tabs and spaces mixed in together. And it's even more work to properly copy-paste python code, even in good editors.
Also. If you're going to come back to me with the argument that it forces people to use indentation, I've got some news for you. Literally everyone uses indentation. And if you somehow come across code written by the rare soul that doesn't use indentation, all I've to do is select the entire code and click "re-indent". Which, btw, in python is a chore to fix badly indented code with tabs and spaces mixed in together. And it's even more work to properly copy-paste python code, even in good editors.
> everyone uses indentation.
Yes, if you don’t you’re incompetent. If you do, the markers are then redundant.
Mixed indentation hasn’t been allowed in years.
Any good editor will show mixed indentation, guides, and indent properly with the tab key, get one.
Sounds like your knowledge of Python is about a decade behind. Not to mention those were nonissues from my experience even back in the day.
Yes, if you don’t you’re incompetent. If you do, the markers are then redundant.
Mixed indentation hasn’t been allowed in years.
Any good editor will show mixed indentation, guides, and indent properly with the tab key, get one.
Sounds like your knowledge of Python is about a decade behind. Not to mention those were nonissues from my experience even back in the day.
These issues are only there because python has significant whitespace. These issues should not have been there in the first place.
Ideally, I shouldn't need to use an editor geared specifically for python code to copy-paste some python code and run it. I have had no issues with the majority of other languages when copy-pasting some code and reindenting. Only in python have I had issues with it. Even in elpy-mode in Emacs, I have had issues. Another is Jupyter/IPython, a widely used python IDE for data scientists, where this problem crops up all the time. So lay off with the superior attitude.
Ideally, I shouldn't need to use an editor geared specifically for python code to copy-paste some python code and run it. I have had no issues with the majority of other languages when copy-pasting some code and reindenting. Only in python have I had issues with it. Even in elpy-mode in Emacs, I have had issues. Another is Jupyter/IPython, a widely used python IDE for data scientists, where this problem crops up all the time. So lay off with the superior attitude.
Don’t need a special editor, just an industry-standard one, that’s the whole point.
I was bothered by the whitespace too, for an hour one afternoon in the spring of ~2001. Then I got over it and realized what a masterstroke it was, removing ~15% of the redundant visual noise.
Firstly, if you cut and paste so often that you feel it should take precedence over everyday readability and conciseness, then that’s a dev smell. Code is read 10x as much as written, likely one reason perl declined.
Secondly, you could simply toggle view whitespace on your editor or have it replace the indent chars on the tab key. Geany does this automatically via pref and it’s Python-specific support is basic.
Thirdly, Python3 and pep8 make issues even less likely than they were. Which is approximately never in my experience in the last ten years or so.
So, this subthread could have been on slashdot in ‘98, hence the frustration.
It’s such a fucking non-issue and productivity boon. Like using yaml for config instead of json.
I was bothered by the whitespace too, for an hour one afternoon in the spring of ~2001. Then I got over it and realized what a masterstroke it was, removing ~15% of the redundant visual noise.
Firstly, if you cut and paste so often that you feel it should take precedence over everyday readability and conciseness, then that’s a dev smell. Code is read 10x as much as written, likely one reason perl declined.
Secondly, you could simply toggle view whitespace on your editor or have it replace the indent chars on the tab key. Geany does this automatically via pref and it’s Python-specific support is basic.
Thirdly, Python3 and pep8 make issues even less likely than they were. Which is approximately never in my experience in the last ten years or so.
So, this subthread could have been on slashdot in ‘98, hence the frustration.
It’s such a fucking non-issue and productivity boon. Like using yaml for config instead of json.
When I started writing C a million years ago I thought to myself -- why the f$# does the compiler need to be told twice what the structure of my code is? Once with {} and once with indentation. It's not as if anyone half-sensible is going to write good code with bad indentation.
With that thought in mind, I am pathetically grateful for Python.
With that thought in mind, I am pathetically grateful for Python.
Python was designed for doing quick throw away prototypes. Perl 5 was designed to support devops before that was a word. If you are writing a large code base in either, there is a good chance you are doing something horribly wrong. (I still prefer perl though)
[deleted]
Indentation + characters for scope is a lot more visual IMO than just using indentation with no clear end marker.
> Its modernity is measurable by the influence it had on most languages designed after its success, like Go and Swift.
So you are measuring "modernity" by legacy?
Also, I don't see any Python influence in Go and from the brief exposure I've had to Swift, I'd say there isn't much influence there either.
By your axiom, one could argue that C is a modern language.
So you are measuring "modernity" by legacy?
Also, I don't see any Python influence in Go and from the brief exposure I've had to Swift, I'd say there isn't much influence there either.
By your axiom, one could argue that C is a modern language.
> I don't see any Python influence in Go
Well, in Google's own words[1]: "Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++". Some go datastructures are very python-like. Coming from a big Python shop, it's unsurprising.
Chris Lattner mentions Python[2] as an influence among others. Swift's lists and dicts are very python-like. The way python deals with datastructures is one of its strong points, and it's clearly more modern than anything C-like.
Both Go and Swift are more restrictive than Python in many ways, mostly for performance reasons since they are built for specific needs, but the influence is there and openly admitted.
[1] https://techcrunch.com/2009/11/10/google-go-language/
[2] http://nondot.org/sabre/
Well, in Google's own words[1]: "Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++". Some go datastructures are very python-like. Coming from a big Python shop, it's unsurprising.
Chris Lattner mentions Python[2] as an influence among others. Swift's lists and dicts are very python-like. The way python deals with datastructures is one of its strong points, and it's clearly more modern than anything C-like.
Both Go and Swift are more restrictive than Python in many ways, mostly for performance reasons since they are built for specific needs, but the influence is there and openly admitted.
[1] https://techcrunch.com/2009/11/10/google-go-language/
[2] http://nondot.org/sabre/
One of the bigger features of P6 is that it can use modules written in other languages such as python.[1]
Are you aware of the compatibility with Perl 5 that I mentioned in my prior comment in this thread? If so, why do you discount it?
[1] https://www.perl.com/article/plotting-with-perl-6/
Are you aware of the compatibility with Perl 5 that I mentioned in my prior comment in this thread? If so, why do you discount it?
[1] https://www.perl.com/article/plotting-with-perl-6/
P5 also has inline python, but it's nowhere near as easy as using a native library.
Stefan Seifert authored or maintains both the P5 and P6 versions of Inline::Python, the Inline::Perl5 for P6 and the Inline::Perl6 for P5.
Three of the four are at the first stage. They work in much the same way, using `.run( ... )` to run a line of code at a time.
One of the four is at the second stage. It works as easily as using a native library. No need for `.run` etc.
Three of the four are at the first stage. They work in much the same way, using `.run( ... )` to run a line of code at a time.
One of the four is at the second stage. It works as easily as using a native library. No need for `.run` etc.
> Perl 5 and 6 are still tied together as if they are the same language
P5 and P6 have been explicitly different languages since day one[1]. As Larry Wall said, "We had to make almost everything [in Perl 5] ... backward compatible [with previous Perls] ... But now it’s the first chance to [break bug-for-bug syntactic and semantic compatibility] and ... I think we should [take the chance]."
> There’s no compatibility between the two.
None?
With an appropriately compiled perl 5 binary installed one can install regular Perl 5 modules from CPAN and use them as if they were Perl 6 modules:
> You can’t write a library that works in both versions
Even the large complex Perl 5 package Catalyst works in both Perl 5 and Perl 6 per the above.
> so you lose CPAN and the thousands of packages that make Perl so powerful
Per the above, the majority of CPAN just works 100% correctly out of the box.
> If Perl 6 wanted backwards compatibility, they needed to have thought about it a long time ago.
P6ers thought about backward compatibility with Perl 5 from day one[1].
[1] https://www.perl.com/pub/2000/10/23/soto2000.html/
P5 and P6 have been explicitly different languages since day one[1]. As Larry Wall said, "We had to make almost everything [in Perl 5] ... backward compatible [with previous Perls] ... But now it’s the first chance to [break bug-for-bug syntactic and semantic compatibility] and ... I think we should [take the chance]."
> There’s no compatibility between the two.
None?
With an appropriately compiled perl 5 binary installed one can install regular Perl 5 modules from CPAN and use them as if they were Perl 6 modules:
use Some:Perl5::Module:from<Perl5> ;
> You can’t write a library that works in both versions
Even the large complex Perl 5 package Catalyst works in both Perl 5 and Perl 6 per the above.
> so you lose CPAN and the thousands of packages that make Perl so powerful
Per the above, the majority of CPAN just works 100% correctly out of the box.
> If Perl 6 wanted backwards compatibility, they needed to have thought about it a long time ago.
P6ers thought about backward compatibility with Perl 5 from day one[1].
[1] https://www.perl.com/pub/2000/10/23/soto2000.html/
>I don’t understand why Perl 5 and 6 are still tied together as if they are the same language.
A lot of people seem to have forgotten, or maybe they weren't around for it, but when Larry anounced Perl 6 it wasn't for a totally different language. It was the next version of Perl. Just as Perl 5 was to Perl 4, and 4 was to 3 and so on. This idea that it's a completely different language and has no relation with 5 is something people started saying when it was clear that Perl 6 wasn't just around the corner.
A lot of people seem to have forgotten, or maybe they weren't around for it, but when Larry anounced Perl 6 it wasn't for a totally different language. It was the next version of Perl. Just as Perl 5 was to Perl 4, and 4 was to 3 and so on. This idea that it's a completely different language and has no relation with 5 is something people started saying when it was clear that Perl 6 wasn't just around the corner.
> when Larry anounced Perl 6 ...
... he very clearly emphasized that it was NOT just the next version of Perl, in contrast with his approach with earlier Perls.
> This idea that it's a completely different language and has no relation with 5 is something people started saying when it was clear that Perl 6 wasn't just around the corner.
I think it's just a chinese whispers effect.
To folk who paid attention to what Larry said on day one, it was obvious that P5 and P6 were (are) not the same and are not totally different either and are related.
Around a decade ago some folk began repeating the mantra that P5 and P6 were different languages in the same family. The hope was that this would help.
But some folk don't like nuance so they arrived at clearly made up and extreme views like "completely different language ... no relation with 5".
... he very clearly emphasized that it was NOT just the next version of Perl, in contrast with his approach with earlier Perls.
> This idea that it's a completely different language and has no relation with 5 is something people started saying when it was clear that Perl 6 wasn't just around the corner.
I think it's just a chinese whispers effect.
To folk who paid attention to what Larry said on day one, it was obvious that P5 and P6 were (are) not the same and are not totally different either and are related.
Around a decade ago some folk began repeating the mantra that P5 and P6 were different languages in the same family. The hope was that this would help.
But some folk don't like nuance so they arrived at clearly made up and extreme views like "completely different language ... no relation with 5".
Almost. Perl 6 was always meant to be a step beyond Perl 5 rather than just an extension or evolution, but initially, Perl 5 was supposed to be a supported syntax. It would be one of many supported by the runtime, and the primary syntax people meant when they said "Perl 6" was going to be a clean break from the past — which excited many people such as myself who despised Perl 5 while envying its terseness — but the underlying engine was supposed to support Perl 5 with seamless interop from Perl 6.
When they gave that up, they needed to work out a completely new plan for maintaining interest and driving adoption, but instead of reassessing they seem to have decided "who cares, it's gonna be so awesome that it won't matter." It might work, but I'm not holding my breath.
When they gave that up, they needed to work out a completely new plan for maintaining interest and driving adoption, but instead of reassessing they seem to have decided "who cares, it's gonna be so awesome that it won't matter." It might work, but I'm not holding my breath.
You can actually use Perl 5 and even Python modules from Perl 6: https://github.com/niner
There are gotchas and unsupported functionality (e.g. 'since Perl 6 does not have the same concept of "context", Perl 5 methods are always called in list context.') which effectively mean that you've got no idea if library 'foo' will work or not without a thorough review of the code.
At best, it's a hack. Impressive, sure, but not something that you could rely upon. There's still no sane upgrade path here.
At best, it's a hack. Impressive, sure, but not something that you could rely upon. There's still no sane upgrade path here.
> At best, it's a hack. Impressive, sure, but not something that you could rely upon.
The same could be said for XS. And I do think that all of Perl 5 is relying upon that.
> There's still no sane upgrade path here.
FWIW, my blog post https://www.perl.com/article/an-open-letter-to-the-perl-comm... touches on that subject.
The same could be said for XS. And I do think that all of Perl 5 is relying upon that.
> There's still no sane upgrade path here.
FWIW, my blog post https://www.perl.com/article/an-open-letter-to-the-perl-comm... touches on that subject.
XS is the "same" hack all the time, though. A Perl library that can only be called in list context in Perl 6 is a substantial change from Perl 5. I've seen much smaller changes trash code bases before. I've got real code that would be affected by that. (I also think the context idea was a misfire in Perl <6, but as long as it is there, I've sometimes written code that had to deal with it.)
That said, why is it impossible to call a Perl 5 function in scalar context? Shouldn't the equivalent of Perl 5's "scalar" be fairly easy to implement? It may stink to have to manually use it, but it wouldn't be very often, and it's easy enough to use any of half-a-dozen Perl 6 features to minimize the syntactic hit.
That said, why is it impossible to call a Perl 5 function in scalar context? Shouldn't the equivalent of Perl 5's "scalar" be fairly easy to implement? It may stink to have to manually use it, but it wouldn't be very often, and it's easy enough to use any of half-a-dozen Perl 6 features to minimize the syntactic hit.
> why is it impossible to call a Perl 5 function in scalar context?
Has Stefan (who wrote IP5) said or written that it's impossible?
18 months ago he wrote "So far I've found 3 different ways to implement scalar/list context for method/function calls".[1]
He has left issue #31 open.[2]
Where did you read that it's impossible?
[1] https://irclog.perlgeek.de/perl6/2016-08-03#i_12961486
[2] https://github.com/niner/Inline-Perl5/issues/31
Has Stefan (who wrote IP5) said or written that it's impossible?
18 months ago he wrote "So far I've found 3 different ways to implement scalar/list context for method/function calls".[1]
He has left issue #31 open.[2]
Where did you read that it's impossible?
[1] https://irclog.perlgeek.de/perl6/2016-08-03#i_12961486
[2] https://github.com/niner/Inline-Perl5/issues/31
"Where did you read that it's impossible?"
Grandparent of my post, no further research.
Bear in mind that as I posted doubt, that I am indeed doubting it, so don't expect me to be too surprised if you confirm that it is worth doubting. :)
Grandparent of my post, no further research.
Bear in mind that as I posted doubt, that I am indeed doubting it, so don't expect me to be too surprised if you confirm that it is worth doubting. :)
Should have chosen a different name for the language.
I feel that there should probably be a name change, but ultimately I don't really care. I am enjoying the language and they can call it whatever they want. If and when they change the name I will just refer to it as the new name.
A new name would have kept momentum in Perl 5 and it would have made Perl 6 more sexy. It is sad, Perl is amazing, I still use it as my personal scripting language. Back in the day I wrote complete enterprise applications.
> Should have chosen a different name for the language.
I wonder if Fortran 2008 wasn't called Fortran, could it be sold to computer science people as a "fast, type-checked matlab".
I wonder if Fortran 2008 wasn't called Fortran, could it be sold to computer science people as a "fast, type-checked matlab".
There were numerous discussions about this and it was decided against it.
Eventually one would use Perl 5 from inside Perl 6 with the "use v5" statement.
Eventually one would use Perl 5 from inside Perl 6 with the "use v5" statement.
Clarification: Decided by the Perl 6 devs who want to keep the name and don't seem to care about the damage that decision does to Perl 5
One of the discussion was on the Perl blogs[1]. Most of the devs there are Perl 5 devs and they also decided against the name change. Perl 6 is the next iteration of Perl that has been redesigned from the ground up. Why should it bare a different name? Yes, the redesign took more than a decade and it's incompatible with Perl 5, but so is Python 3.6 compared to 2.7, albeit to a lesser extent. Even Perl 5.26 has changed a lot since 5.6. In fact the least common denominator is 5.10.1. Using older versions is discouraged since they're largely unsupported by the majority of CPAN modules.
1. http://blogs.perl.org
1. http://blogs.perl.org
The most recent discussion I saw on this subject[1] makes it very clear that there isn't a consensus. If there is, it's in the "Perl 6 should rename" direction.
[1]: https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter...
[1]: https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter...
> Yes, the redesign took more than a decade
Quite true! In fact, the redesign took more than a decade and a half (July 2000 to Dec 2015). A record worth breaking!
Quite true! In fact, the redesign took more than a decade and a half (July 2000 to Dec 2015). A record worth breaking!
It was a decision made by Larry Wall alone.Since it’s his language, he’s allowed to do that.
If this really had worked seamlessly it would be great.
But that includes /usr/bin/perl working this way on every OS etc... with a clear&easy upgrade path for existing code.
Well Perl 5 needs a spec in order to be supported inside Perl 5. Otherwise which version do you support? 5.6? 5.10.1? 5.16?
What ... like Ruby? :-)
Perl6 has some compatibility -- at the wetware level.
Which is not nothing.
Perl6 has some compatibility -- at the wetware level.
Which is not nothing.
Yeah, but I think it's because they have the same name, only the number on the right is different and people tend to assume that Perl 6 is the one after 5.
Also, how would similar functions even be enough? The average Perl script I had was full of special operators, etc. (they all changed and are impossible to Google anyway). And code bases have more than enough churn without being fundamentally rewritten multiple times to do the same thing.
It's the spiritual successor
I cut my teeth on Perl 5 in the early 2000s, and I've been curious about Perl 6 for a long time.
Last year I sat down with Perl 6 for long enough to form opinions on the language's merits, which are many. I'm told many of my criticisms have been addressed in the five months since the article was published, but perhaps some of you will enjoy reading the original review. Cheers!
https://www.evanmiller.org/a-review-of-perl-6.html
Last year I sat down with Perl 6 for long enough to form opinions on the language's merits, which are many. I'm told many of my criticisms have been addressed in the five months since the article was published, but perhaps some of you will enjoy reading the original review. Cheers!
https://www.evanmiller.org/a-review-of-perl-6.html
I applaud you for that, I feel like it would do good for most of the people here who are so quick to voice their opinion to actually try Perl6 out, as I get distinct feeling that majority probably haven't. I definitely feel the emotion here:
"current of frustration that Perl 6 isn’t more widely adopted. There’s a kind of righteous indignation that the language is very good — so dammit (I’m projecting), when will people start taking us seriously? "
despite not even being part of Perl 6 community in any way. So many are attacking it on such circumstantial, or even irrelevant, grounds instead of discussing the merits and failings of the language itself.
This is exactly the sort of thing that makes me frustrated (of tech world); people, myself included, scared to jump to new things, or even try out them leading to strong herd mentality. I suspect it is because everything has such strong network effects these days. And of course HN is kinda the worst because the business angle; there is always the question about if this makes commercial sense, which I'll admit might not be the strongest aspect of Perl6.
"current of frustration that Perl 6 isn’t more widely adopted. There’s a kind of righteous indignation that the language is very good — so dammit (I’m projecting), when will people start taking us seriously? "
despite not even being part of Perl 6 community in any way. So many are attacking it on such circumstantial, or even irrelevant, grounds instead of discussing the merits and failings of the language itself.
This is exactly the sort of thing that makes me frustrated (of tech world); people, myself included, scared to jump to new things, or even try out them leading to strong herd mentality. I suspect it is because everything has such strong network effects these days. And of course HN is kinda the worst because the business angle; there is always the question about if this makes commercial sense, which I'll admit might not be the strongest aspect of Perl6.
Perl Pessimism: https://trends.google.com/trends/explore?date=all&q=perl
I have happy memories of Perl, and it started me on the path that led to a nice career of Python awesomeness. Thanks, Perl! That said, I can't imagine a plausible scenario where I'd ever consider using it again. I almost certainly wouldn't use it professionally because it's not exactly going to light up a resume. Yes, there are still Perl shops. But no, there aren't very many of them, and I'd be highly suspicious of an engineering department still writing new code in it today without a very good reason.
I have happy memories of Perl, and it started me on the path that led to a nice career of Python awesomeness. Thanks, Perl! That said, I can't imagine a plausible scenario where I'd ever consider using it again. I almost certainly wouldn't use it professionally because it's not exactly going to light up a resume. Yes, there are still Perl shops. But no, there aren't very many of them, and I'd be highly suspicious of an engineering department still writing new code in it today without a very good reason.
>>Yes, there are still Perl shops. But no, there aren't very many of them
That's because any shop that needs to get job done quickly is a Perl shop. During my early career I even knew a architect who had sort of put a blanket ban on any Perl to be written. He was only stumped people were largely acting like pirates, were writing and running directories full of Perl code all the time.
Only a week back, I needed some stuff to be written. Talked to a Java guy, he tells me he can do it in a week. Told him to never mind. Went back to my desk and wrote in a afternoon in Perl. And we are a Java shop and write Java most of the time. But its just that Perl is unbeatable in getting things done.
And yeah Python. It doesn't even remotely hold a candle to Perl in terms of practicality and getting things done. Readability and all that, but frankly beyond that there is nothing in Python. Not even multiline lambdas, half baked, half implemented functional programming features. IO looks like somebody held a gun to the implementors head and he added it because he had to.
Some times I even find, sed and awk to be a million times more useful than Python.
That's because any shop that needs to get job done quickly is a Perl shop. During my early career I even knew a architect who had sort of put a blanket ban on any Perl to be written. He was only stumped people were largely acting like pirates, were writing and running directories full of Perl code all the time.
Only a week back, I needed some stuff to be written. Talked to a Java guy, he tells me he can do it in a week. Told him to never mind. Went back to my desk and wrote in a afternoon in Perl. And we are a Java shop and write Java most of the time. But its just that Perl is unbeatable in getting things done.
And yeah Python. It doesn't even remotely hold a candle to Perl in terms of practicality and getting things done. Readability and all that, but frankly beyond that there is nothing in Python. Not even multiline lambdas, half baked, half implemented functional programming features. IO looks like somebody held a gun to the implementors head and he added it because he had to.
Some times I even find, sed and awk to be a million times more useful than Python.
> That's because any shop that needs to get job done quickly is a Perl shop.
Be careful with that wild generalization. I’ve seen lots more “get job done quickly” in Ruby than Perl (but neither as much as with Python recently). I have nothing bad to say about Perl, but it’s not really defensible to claim it’s used as commonly as other languages.
Be careful with that wild generalization. I’ve seen lots more “get job done quickly” in Ruby than Perl (but neither as much as with Python recently). I have nothing bad to say about Perl, but it’s not really defensible to claim it’s used as commonly as other languages.
Just remember there is a lot of perl creeping around the linux ecosystem; it may not be fashionable today but availability of the perl command is still more common than python, second only to bash/sh.
[deleted]
HA! That gun-to-the-head bit is so true. Sometimes I feel like the only person who dislikes Python for its design principles.
[deleted]
We are one of those Perl shops. The reasons why we're still using it are: old codebase started in 2004, >95% rewritten, the language is stable, fast enough and it scaled well for our needs after we rewrote the web services using Mojolicious. I'd also pick Perl any day over PHP or Python.
We also write a fair amount of Javascript on the frontend but moving the backend to Node.js doesn't add any benefits. It just makes things harder, having to track constantly moving targets, using many different tools to accomplish the same jobs, having to fork stuff just to get it to work properly.
We also write a fair amount of Javascript on the frontend but moving the backend to Node.js doesn't add any benefits. It just makes things harder, having to track constantly moving targets, using many different tools to accomplish the same jobs, having to fork stuff just to get it to work properly.
That’s on the short list of “oh, that makes sense” reasons.
"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
― George Bernard Shaw
Not all great decisions are rational, follow your heart be happy
For me, Python is an uninspiring language, yet it inspired many people to build great things, a decision that to me, sound so .. irrational
― George Bernard Shaw
Not all great decisions are rational, follow your heart be happy
For me, Python is an uninspiring language, yet it inspired many people to build great things, a decision that to me, sound so .. irrational
The trouble with that syllogism is that some take it to mean that all unreasonable men create progress.
I would even say most unreasonable men fail
Very few succeed, but those who do, make big changes
It is a high risk high reward type of decision
But honestly, Perl 6 is not that bad of bet, there while small, a lively community around it filled with brilliant developers
Very few succeed, but those who do, make big changes
It is a high risk high reward type of decision
But honestly, Perl 6 is not that bad of bet, there while small, a lively community around it filled with brilliant developers
I'd advise you to remain curious beyond what's good for your resume, especially if you want to stay sharp and ahead of the curve. Perl 6 has some neat features, particularly around grammars and parsing, that make those tools easier to use for day-to-day problems.
To be sure! I’m not allergic to Perl and I like seeing the cool new stuff going on there. But afterward, I prefer to take those learnings and apply them to work I’m doing in other languages.
To begin to transfer P6 grammar/parsing features or techniques to another language you'd have to bundle NQP and one of its backends. Does that sound worthwhile?
Also, how would you handle strings in this other language?
In P6 and its grammar engine, a string is a sequence of characters, where characters are defined as the thing a human thinks of as a character.
Almost all other languages have adopted either a byte or a Unicode codepoint as being equivalent to a character, both of which are really profound problems that are still not being confronted to this day.
For example, the draft docs for Python 3.7 don't even mention characters (by which I mean what a user thinks of as characters, not bytes or codepoints).[1]
[1] https://docs.python.org/3.7/search.html?q=grapheme&check_key...
Also, how would you handle strings in this other language?
In P6 and its grammar engine, a string is a sequence of characters, where characters are defined as the thing a human thinks of as a character.
Almost all other languages have adopted either a byte or a Unicode codepoint as being equivalent to a character, both of which are really profound problems that are still not being confronted to this day.
For example, the draft docs for Python 3.7 don't even mention characters (by which I mean what a user thinks of as characters, not bytes or codepoints).[1]
[1] https://docs.python.org/3.7/search.html?q=grapheme&check_key...
If programming languages' impact on resumes would be a sensible metric I had never learned LISPs, prolog or MLs. Those experiences have been the key to many well-paying gigs, even though I more often than not was hired for some mainstream language/stack.
I too would hesitate to use it in a commercial context, but only because its development stalled for 15 years, leaving us with almost no developers that still speak perl and still work in the trenches... perl's cost of adaption in comparison to other dynamic languages skyrocketed :(
I too would hesitate to use it in a commercial context, but only because its development stalled for 15 years, leaving us with almost no developers that still speak perl and still work in the trenches... perl's cost of adaption in comparison to other dynamic languages skyrocketed :(
So many things are already written in Perl, so moving to another language just for popularity’s sake unnecessarily introduces another standard in an environment. There might be reasons a new language is needed, but sticking to Perl and Bash, if that’s mostly what your environment has, makes sense in many cases.
The popularity argument only makes sense in regards to hiring new people, which is a fair point.
The popularity argument only makes sense in regards to hiring new people, which is a fair point.
I don’t disagree with the first part. That’s a legit reason to stick with what you have.
But yes, it is going to make hiring more challenging.
But yes, it is going to make hiring more challenging.
As a former Perl programmer, dabbling in Python, I keep getting reminded how awesome Perl is.
For example: I'm collecting some stats indexed by (small) ints. In Perl, I'd just say
Edit: Fixed typo; meant "$stat" and not "%stat"
For example: I'm collecting some stats indexed by (small) ints. In Perl, I'd just say
$collection[$index] = $stat;
Edit: Fixed typo; meant "$stat" and not "%stat"
In Python:
dict[index] = stat
The Python version blows up if the slot isn't already populated. The Perl version works in either case (there is a typo in the Perl code though).
Only if you're using a list, not a dict. I just tried it in the REPL:
>>> foo = {}
>>> foo[3] = 72
>>> foo[64] = 80
>>> foo
{3: 72, 64: 80}The difference is more dramatic once you have two or more dimensions:
>>> foo = {}
>>> foo[3][4] = 42
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 3
DB<1> $foo{3}{4} = 42
DB<2> x \%foo
0 HASH(0x7f9f4315c940)
3 => HASH(0x7f9f432bb148)
4 => 42 tree = lambda: collections.defaultdict(tree)
foo = tree()
foo[3][4] = 42I don't think I'd want or need to try that...
[deleted]
\%stat;Arguably more interesting:
https://trends.google.com/trends/explore?date=all&q=perl%20t...
https://trends.google.com/trends/explore?date=all&q=perl%20t...
Is there anything "suspicious" about using Perl other than it's not as popular as Python, according to Google Trends?
No, there’s nothing inherently wrong with it. I’ve run across two distinct sets of Perl mongers, though:
- “We have lots of deployed code and don’t want to rewrite the whole thing.” That’s valid (although I still urge them to consider the hiring challenges down the road).
- “I’ve used Perl exclusively since I downloaded it over dialup and I’m not interested in those shiny new languages the kids like.” Run screaming.
- “We have lots of deployed code and don’t want to rewrite the whole thing.” That’s valid (although I still urge them to consider the hiring challenges down the road).
- “I’ve used Perl exclusively since I downloaded it over dialup and I’m not interested in those shiny new languages the kids like.” Run screaming.
I've never met a Perl developer who doesn't know and use other languages. By contrast it's much more probable that a "kid" writing Python or JavaScript has never been exposed to anything else.
When you say you wouldn't use Perl again, that's a fine personal choice, but has zero to do with the merits of the language or the people who use it.
When you say you wouldn't use Perl again, that's a fine personal choice, but has zero to do with the merits of the language or the people who use it.
No. It's not suspicious or dangerous in any way compared to Python.
I spent a huge amount of time in my 20's writing Perl 4 & 5 scripts. Even though I no longer use Perl, I still feel nostalgic about it.
That said, I can't find any reason to pick up Perl 6 and start learning it. With so many other useful and interesting languages out there: Python, Elixir, Elm, Rust, etc... what appeal should Perl 6 have to the masses these days?
Is anyone jumping into Perl 6 like they did with Ruby a decade ago and saying, "Wow, programming just got fun again"?
I'd love to see a Perl 6 breakthrough, but honestly it feels like those attempts to keep BeOS going... too little, too late. Its time has passed.
That said, I can't find any reason to pick up Perl 6 and start learning it. With so many other useful and interesting languages out there: Python, Elixir, Elm, Rust, etc... what appeal should Perl 6 have to the masses these days?
Is anyone jumping into Perl 6 like they did with Ruby a decade ago and saying, "Wow, programming just got fun again"?
I'd love to see a Perl 6 breakthrough, but honestly it feels like those attempts to keep BeOS going... too little, too late. Its time has passed.
Actually, I've been looking at Perl 6 and I think it's quite amazing. It's really the only language outside those I get paid to work with that I've considered doing a deep dive on.
I'm not really understanding the lack of love for Perl 6 unless it's from folks that have invested careers in Perl 5 and are miffed by the compatibility story.
For example can someone point to the analog of this https://docs.perl6.org/language/grammars in Python, Ruby, Groovy etc?
Also, https://modules.perl6.org/ seems to be growing.
I'm not really understanding the lack of love for Perl 6 unless it's from folks that have invested careers in Perl 5 and are miffed by the compatibility story.
For example can someone point to the analog of this https://docs.perl6.org/language/grammars in Python, Ruby, Groovy etc?
Also, https://modules.perl6.org/ seems to be growing.
> I'm not really understanding the lack of love for Perl 6 unless it's from folks that have invested careers in Perl 5 and are miffed by the compatibility story.
I think far more likely is the people that have decided to dislike "Perl" are letting their prejudice leak.
Perl 5 is one of those languages that is hides complexity, partially by accident. I'm sure a lot of people have looked at Perl and been unable to figure out what's going on, and why the same function returns different values sometimes when called with the same arguments[1], and not known what to make of it because many things work exactly as expected, especially for people familiar with C. This can be confusing to people that thought they were getting a handle on the language. The conclusion then is either they are failing to understand the language, or the language sucks. I imagine one choice is easier on the ego than the other.
1: Context. People skimp on the reading or targeted learning and context bites them in the ass, even if it's fairly simple once known.
I think far more likely is the people that have decided to dislike "Perl" are letting their prejudice leak.
Perl 5 is one of those languages that is hides complexity, partially by accident. I'm sure a lot of people have looked at Perl and been unable to figure out what's going on, and why the same function returns different values sometimes when called with the same arguments[1], and not known what to make of it because many things work exactly as expected, especially for people familiar with C. This can be confusing to people that thought they were getting a handle on the language. The conclusion then is either they are failing to understand the language, or the language sucks. I imagine one choice is easier on the ego than the other.
1: Context. People skimp on the reading or targeted learning and context bites them in the ass, even if it's fairly simple once known.
> can someone point to the analog of this https://docs.perl6.org/language/grammars in Python, Ruby, Groovy etc?
Those language grammars, if they've been properly implemented, could be the Perl 6 killer feature if well promoted. It could even lead to a sudden fall in brogrammers using regexes to parse html.
Looking at the ranking of those languages you mentioned on Tiobe, i.e. Python (4.7%), Ruby (2.4%) and Apache Groovy (0.3%), I guess if Python 3 took the initiative and implemented them, that would work as well.
Those language grammars, if they've been properly implemented, could be the Perl 6 killer feature if well promoted. It could even lead to a sudden fall in brogrammers using regexes to parse html.
Looking at the ranking of those languages you mentioned on Tiobe, i.e. Python (4.7%), Ruby (2.4%) and Apache Groovy (0.3%), I guess if Python 3 took the initiative and implemented them, that would work as well.
Nice that you mention "deep dive". :-)
https://www.packtpub.com/application-development/perl-6-deep...
Perl 5 is still as fun as ever. And newer things like Mojolicious keeps adding to the goodness.
Yes, Perl 5 is still fun, but I really like the chaining and FP in Perl 6, much like autobox but native. And native sets, rational number math instead of floating point math, the ability to use huge numbers without BigNum and lots of other awesoneness.
The top three Perl 6 features that make me say "Wow, programming is fun" are grammars, concurrency and gradual typing. There are many other features that also make Perl 6 a joy to use.
Ruby has replaced Perl for me as that get-things-done scripting language on the system. It would be weird to go back especially now that Ruby has the right ecosystem and fairly good backwards compatibility.
Ruby is both clean, expressive, has proper OO features and not it's not that alien from Perl. It feels a bit sluggish though, although to a lesser extent since 2.3. Perl 6 is slower for command line scripts anyway.
it is a really interesting language, in the sense of having many unique and unusual features.
Perl 6 appeals to me enough to make it my first new language to study, after a 20-year hiatus from any meaningful programming. This could be taken as an anti-endorsement. But for someone with no legacy skills, and no legacy codebase to draw on, I can afford to be arbitrary. What sold me is the cheat of storing floating point numbers as rationals composed of integers. Also when I tried python I missed the curly braces.
Another year, another chance for all involved to learn the important rationality skill of recognizing sunk costs and opportunity costs, and give up when giving up is the best option.
http://lesswrong.com/lw/gx/just_lose_hope_already/
http://lesswrong.com/lw/gx/just_lose_hope_already/
If Perl 6 were a centrally managed and funded effort to create a popular language, I would a agree that the one who funds it would look at adoption numbers and time spent, and declare it sunk cost, and try to achieve their objectives through other means.
But everybody who's working on Perl 6 does it because they enjoy it, learn by doing it etc. Why should they declare it a failure? Usage numbers are slowly, slowly creeping up, and working with and on Perl 6 can be real fun.
If I'd work on it regardless on how much of my previous time I invested in it, why should I even consider sunk costs?
But everybody who's working on Perl 6 does it because they enjoy it, learn by doing it etc. Why should they declare it a failure? Usage numbers are slowly, slowly creeping up, and working with and on Perl 6 can be real fun.
If I'd work on it regardless on how much of my previous time I invested in it, why should I even consider sunk costs?
Perl 6 was announced in the year 2000. 18 years is a long time. It should be a case study for software developers.
I don’t know if they should give up. Haven’t looked at Perl 6 in about 5 years. The best thing the community could do would be to turn the language into the solution to a particular problem:
Web development, machine learning, etc
Sure, anyone could build everything from scratch, but that’s usually not a good idea.
I don’t know if they should give up. Haven’t looked at Perl 6 in about 5 years. The best thing the community could do would be to turn the language into the solution to a particular problem:
Web development, machine learning, etc
Sure, anyone could build everything from scratch, but that’s usually not a good idea.
I went to OScon in something like 2009 or 10 and someone working on the python interpreter they were gonna share with Perl got on stage and showed how the roadmap and their velocity wouldn’t have Perl 6 done until 2016.
This kind of crazy has been identified in the ecosystem for a while.
This kind of crazy has been identified in the ecosystem for a while.
Why? Open source developers can work on whatever they want.
I hope that the Perl 6 core devs take notice of this and other threads from the past days. Somehow I think that the efforts have not been directed enough at things that perhaps are not that exciting for them but that matters a lot for potential users.
Examples:
I say this of course realizing that resources in an open source project are limited. But something has to happen to accelerate the usage.
Keep on writing more articles etc to spread information outside the P6 core dev echo chamber.
Examples:
- Better migration/transition from Perl 5
- Performance and stability
- Killer features and explaining these thoroughly
- Best in class tooling, editor support, super easy deployment
I say this of course realizing that resources in an open source project are limited. But something has to happen to accelerate the usage.
Keep on writing more articles etc to spread information outside the P6 core dev echo chamber.
The tooling might be more important than you think to gain corporate/enterprise usage.
Im just throwing out examples here:
Im just throwing out examples here:
- Official and optimized docker images
- Easy to build CI pipelines
- Fast and parallel execution of tests, easy to integrate in CI
- Quick compile times if any of language, libs etc. Fast downloads of binaries
- Great vendoring and packaging, don't need internet to deploy, deploy as binary
- Easy command line tools for enforcing linting, code standards etc. with well thought out defaults officially supported
- Editor support, out of the box experiencePerl 6 is 5 times slower than Ruby in parsing a typical Apache log file with a regex. Text parsing with a regex was Perl's claim to fame but it seems to be last on Perl 6's list of priorities.
Only 5 times now? I seem to recall it being 100x slower not too long ago.
Constructive criticism: Perl 6 needs to be at least as fast and preferably faster than the competition to start seeing some serious use outside the echo chamber.
"Lets move to Perl 6 since it will cut our infrastructure costs in half. It will also cut our time to market in half due to the fantastic tooling." Thats the kind of things business decision makers need to hear.
"Lets move to Perl 6 since it will cut our infrastructure costs in half. It will also cut our time to market in half due to the fantastic tooling." Thats the kind of things business decision makers need to hear.
> Better migration/transition from Perl 5
This is what the CPAN Butterfly Plan is all about. And after that the Butterfly Perl 5 Project.
This is what the CPAN Butterfly Plan is all about. And after that the Butterfly Perl 5 Project.
Yes but will it be enough?
For many Perl is tied to Unix and IMO a transition for /usr/bin/perl would be key.
I might not fully understand your plan but please do not throw away the "ubiquitous in Unix" legacy.
For many Perl is tied to Unix and IMO a transition for /usr/bin/perl would be key.
I might not fully understand your plan but please do not throw away the "ubiquitous in Unix" legacy.
I'm still wondering why they use non ASCII characters for operators.
Perl 6 has ASCII versions of every unicode operator:
https://docs.perl6.org/language/unicode_ascii
https://docs.perl6.org/language/unicode_ascii
Is there a key for it on my keyboard though?
Hey, we have docs for that :-) https://docs.perl6.org/language/unicode#Entering_Unicode_Cod...
yes, all of the ASCII characters are standard on most keyboards.
Here is a nickel kid, get yourself a real text editor: https://www.gnu.org/software/emacs/manual/html_node/emacs/In...
Do you realize people that speak more than two languages already use multiple keyboard layouts all of the time?
Do you realize people that speak more than two languages already use multiple keyboard layouts all of the time?
Once you decide your language is going to allow a programmer to have a variable called `meðaltal` instead of `average`, it's not much extra work to let them use an operator called `Σ`.
Why not? It's a neat way of showing off fundamental Unicode support, and AFAIK there are ASCII equivalents for all of them, in case you have no idea how to enter ⤐ or whatever.
Well, this way you will have 2 versions of code in the wild, ascii and non-ascii. We will need to memorize both, which makes it harder to learn, and also having 2 versions of syntax that you run into puts unnecessary mental strain on a developer having to switch between contexts. Perl's motto was always "There's more than one way to do it", but IMHO it was also the root of many of its weaknesses. It just makes code more complicated to understand, and this is one way to make it even worse (otherwise I love what they did with Perl6).
> Perl's motto was always "There's more than one way to do it", but IMHO it was also the root of many of its weaknesses.
So are you suggesting that Perl should discard its TIMTOWDI philosophy? It won't be Perl anymore then, would it?
So are you suggesting that Perl should discard its TIMTOWDI philosophy? It won't be Perl anymore then, would it?
> in case you have no idea how to enter ⤐ or whatever.
Did you mean to type a black square there, or is my Android phone missing a font? In any case, this shows a potential issue with using Unicode characters for operators or identifiers: unless it's from a common Unicode block (like basic Greek letters), it might not be readable. It's not just writing that can be a problem.
Did you mean to type a black square there, or is my Android phone missing a font? In any case, this shows a potential issue with using Unicode characters for operators or identifiers: unless it's from a common Unicode block (like basic Greek letters), it might not be readable. It's not just writing that can be a problem.
Android devices tend to lack a lot of Unicode characters for some reason. I typed the "rightwards two-headed triple dash arrow" (not used in Perl AFAIK, I just find the name funny for some reason) and it doesn't show up on my Android either. Another commonly missing character is schwa (ə), which is used quite a lot in IPA transcriptions, and I've seen accented Greek characters missing as well, so it's not like only very rare characters are neglected.
I heard many times that perl is «write only». Unicode operators takes it to the next level.
APL has used a huge set of non ASCII characters for more than 30 years in production by large companies.
Modern APL derivatives (namely J and K) have ditched them though in favor of pure ascii.
The character set and font constraints of the early 1990s, when J (1990) and K (1993) were developed, no longer apply. APL symbols are part of Unicode. There is no technical advantage left to ASCII-only syntax for APL-derived languages.
> There is no technical advantage left to ASCII-only syntax for APL-derived languages.
Except for that minor technical advantage of actually being on a standard keyboard.
That said, I would love standard keyboards to get more symbols. I actally like using symbols instead of words for operators, when done in a consistent and logical fashion as J and K do and unlike Perl's disaster of a syntax.
Map and reduce (each and over in APL lingo, in K ' and /) should be a symbol.
Except for that minor technical advantage of actually being on a standard keyboard.
That said, I would love standard keyboards to get more symbols. I actally like using symbols instead of words for operators, when done in a consistent and logical fashion as J and K do and unlike Perl's disaster of a syntax.
Map and reduce (each and over in APL lingo, in K ' and /) should be a symbol.
> Except for that minor technical advantage of actually being on a standard keyboard.
The IBM/Unicomp APL keyboard is a standard PS/2 PC/USB HID keyboard. Literally the only special thing about the IBM/Unicomp APL keyboards is what is printed on the keycaps (which you can buy separately https://www.pckeyboard.com/page/product/USAPLSET).
I don't understand this - how do people on Hacker News not realize that your keyboard does not determine your character encoding? You can easily remap your keys to whatever you want, have multiple layouts for human and computer programming languages, change the modifier and functions keys, whatever you want. All with the keyboard you already have; laptop, external, it doesn't matter.
Somehow multiple layouts are not a big deal for multi-lingual people, why is it so confusing for programmers?
The IBM/Unicomp APL keyboard is a standard PS/2 PC/USB HID keyboard. Literally the only special thing about the IBM/Unicomp APL keyboards is what is printed on the keycaps (which you can buy separately https://www.pckeyboard.com/page/product/USAPLSET).
I don't understand this - how do people on Hacker News not realize that your keyboard does not determine your character encoding? You can easily remap your keys to whatever you want, have multiple layouts for human and computer programming languages, change the modifier and functions keys, whatever you want. All with the keyboard you already have; laptop, external, it doesn't matter.
Somehow multiple layouts are not a big deal for multi-lingual people, why is it so confusing for programmers?
> Somehow multiple layouts are not a big deal for multi-lingual people, why is it so confusing for programmers?
I don't know. I would totally do it if others did it. There just isn't a critical mass enough.
Maybe the next APLish language needs to have both modes of display similar to how java editors fold old constructs into new ones. That would allow the extra symbols to be slowly adopted.
I don't know. I would totally do it if others did it. There just isn't a critical mass enough.
Maybe the next APLish language needs to have both modes of display similar to how java editors fold old constructs into new ones. That would allow the extra symbols to be slowly adopted.
Sounds like a lot of fluff added because some people want a slower ramp. I think there just needs to be more example material out there for beginners.
People realize that of course, but I don't think simply buying keycaps is an option for everyone. Will they work with my slightly non standard ergonomic keyboard?
None of my keyboards have Russian keycaps on them. I still somehow manage to type in Russian. Do you look at your keycaps when typing? If you want to, you can put stickers on your keycaps (you can purchase sets for foreign languages, and for APL), or use a quality permanent marker. A reference chart is also an option.
I don't look know that I know where everything is, but I'm guessing it takes awhile to learn where 72 weird APL symbols go when you're first learning you know?
Agreed on the keyboard thing. Dyalog sells an APL keyboard, but it isn't ergonomic, which I need.
I think "/" is a good symbol for map as it is easy access.
I think "/" is a good symbol for map as it is easy access.
I really want to do a stream based language that is like APL for streams. With the current event sourcing craze right now, I definitely see modern use cases.
True that J & K do, but Dyalog doesn't and is pretty modern in that it is still very actively developed...interfaces to Python/R, runs on Raspberry Pi, hooks into .NET, can run on GPU...etc.
[deleted]
Paste the character into Google search or Wikipedia URL to find out.
Which do people tend to use? Are there tools for converting back and forth?
I am tempted by the idea of being able to type e.g. ½x² in mathematical code, but overall it sounds like much more trouble than it's worth.
I am tempted by the idea of being able to type e.g. ½x² in mathematical code, but overall it sounds like much more trouble than it's worth.
how would one describe Perl 6 type system?
Is it dynamically typed, optionally typed, statically typed?
Is it dynamically typed, optionally typed, statically typed?
The Perl 6 answer to almost all such questions is simply "Yes". It is an incredible mess. Whether it is a glorious mess is something that we are finally coming up on the ability to determine.
It has optional static typing:
> sub f(Int $x) { $x + 1 }
sub f (Int $x) { #`(Sub|140221097113944) ... }
> sub g(Str $x) { f($x) }
===SORRY!=== Error while compiling:
Calling f(Str) will never work with declared signature (Int $x)It's gradually typed. Which means there are dynamic type checks, and optional static type declarations as well.
If the compiler can prove the outcome of a type check at compile time, it can throw a type error or optimize out the runtime check, depending on the outcome.
If the compiler can prove the outcome of a type check at compile time, it can throw a type error or optimize out the runtime check, depending on the outcome.
Is Perl 6 sill so damn slow?
Performance has improved a lot since the initial release:
https://perl6advent.wordpress.com/2017/12/16/day-16-%F0%9F%8...
https://perl6advent.wordpress.com/2017/12/16/day-16-%F0%9F%8...
Performance improved a lot but it's still very bad. e.g. there is some csv-game[1] where there is perl6 code that used to take 16 minutes but now 'only' takes 5 minutes.
perl5 completes the task in <3s.
[1] https://bitbucket.org/ewanhiggs/csv-game/src/9604dc176b6303e...
perl5 completes the task in <3s.
[1] https://bitbucket.org/ewanhiggs/csv-game/src/9604dc176b6303e...
Too bad there are is no P6 code on the benchmarks game[1]. Probably a good opportunity to learn P6.
https://benchmarksgame.alioth.debian.org
https://benchmarksgame.alioth.debian.org
"If you're interested in something not shown on the benchmarks game website then please take the program source code and the measurement scripts and publish your own measurements."
https://benchmarksgame.alioth.debian.org/play.html#languagex
Like this guy does -- https://pybenchmarks.org/
https://benchmarksgame.alioth.debian.org/play.html#languagex
Like this guy does -- https://pybenchmarks.org/
I used perl when dinosaurs still roamed the land. Can somebody explain why it took so long for Perl 6? I read first p6/parrot vm textbook as a schoolboy more than a decade ago.
Because parrot development was mismanaged and ran into ground. Similar to perl5 management in the last 15 years.
Is there any hope of seeing your cperl efforts in mainstream perl? Would you be able to disregard recent history with p5p if you were welcomed back?
> be able to disregard recent history with p5p if you were welcomed back
It is essentially impossible to do so, as the problems are systemic and run extraordinarily deep.
Would you honestly consider any possibility of working on a "level" with people like this: https://www.nntp.perl.org/group/perl.perl5.porters/2018/01/m...
So I can't fault rurban for walking away. The project still has merit. Its current leadership - none.
It is essentially impossible to do so, as the problems are systemic and run extraordinarily deep.
Would you honestly consider any possibility of working on a "level" with people like this: https://www.nntp.perl.org/group/perl.perl5.porters/2018/01/m...
So I can't fault rurban for walking away. The project still has merit. Its current leadership - none.
I never walked away. I was banned with trumped-up charges.
Their former pastime was that my criticism had no technical merits, they now changed course and claim that my criticism is uncivilized. Well, this is a good strategy to hold the community together. Create a common enemy. Get him fired. Collect the angry mob and give them powers.
Their former pastime was that my criticism had no technical merits, they now changed course and claim that my criticism is uncivilized. Well, this is a good strategy to hold the community together. Create a common enemy. Get him fired. Collect the angry mob and give them powers.
FWIW, an apology was later issued:
https://www.nntp.perl.org/group/perl.perl5.porters/2018/01/m...
https://www.nntp.perl.org/group/perl.perl5.porters/2018/01/m...
More of a self-flagellation than an apology, frankly… it was actively uncomfortable to read, unlike even his initial angry mail. I have yet to respond to him because I didn’t know what to say after that.
[deleted]
You have to ask them. They are the ones refusing any changes and cooperation, and are still actively destructive. In parrot the destructive people eventually burned out, and I could fix much stuff, but the big changes from around 2.7, the calling convention and the jit and runloop removal was eventually too much.
It took a while to design the language, which went through significant changes in both semantics and implementation (Parrot was abandoned for MoarVM, until recently, the main banch of the repository still was called 'nom' for 'new object model', there was a Great List Refactor, ...)
The language was finally deemed sufficiently stable in 2015 to have its first proper release (the 'Christmas' version 6.c). We're still waiting for an implementation with adequate performance for generic usage. The problem is that a lot of the implementation happens at a high level, which necessitates a sufficiently smart optimizer.
The language was finally deemed sufficiently stable in 2015 to have its first proper release (the 'Christmas' version 6.c). We're still waiting for an implementation with adequate performance for generic usage. The problem is that a lot of the implementation happens at a high level, which necessitates a sufficiently smart optimizer.
Main source of optimism for Perl is Booking.com using it :0
Of course they're using Perl 5, not Perl 6.
Would people feel differently (lots of talk in here along the lines of "why bother at this point?") if Perl 6 had a completely different name?
Is anybody here using perl 6 in production at the moment? Or perl 5 for that matter?
A surprisingly huge amount of the Amazon.com codebase is Perl 5. The various back-ends are primarily in Java, but most front-end code is Perl/Mason.
Wow! Still?
As one of the primary maintainers of Mason for many years I enjoyed telling non-technical friends that they used my work every time they went to Amazon. But I'd kind of assumed that was no longer the case these days. Apparently I can keep telling them the same thing!
As one of the primary maintainers of Mason for many years I enjoyed telling non-technical friends that they used my work every time they went to Amazon. But I'd kind of assumed that was no longer the case these days. Apparently I can keep telling them the same thing!
Mason is great. Thanks for your work! They are phasing it out but very slowly. It'll probably be around forever on internal tools.
Cool, I'm glad it's still helping people. For the record, I was not the creator of the package. That was Jon Swartz.
I did a lot of work on it for quite a few years in the early 2000s and maintained it for quite some time after that.
I did a lot of work on it for quite a few years in the early 2000s and maintained it for quite some time after that.
Perl 5? Off the top of my head: Deutsche Bank, Broadbean, Photobox, BBC, Booking.com, Net-A-Porter. I'm sure a more enthusiastic Perl user can provide a surfeit of examples.
All of FastMail is in Perl5 (minus the Cyrus parts, which are in C).
NVIDIA, Shutterstock, Symantec, Amadeus IT Group, Bank of America
My office has at least a few hundred thousand lines of perl 5 (v 5.8.0) running on legacy systems, though we've switched to python for new development.
We won't be using perl 6, and suggesting it in the office would get some good laughs out of everyone who's had to work on that codebase.
I'll still write perl when I need a quick one-off script to solve the kind of problem it's good for, like throwing a bunch of regexes at a bunch of text files.
We won't be using perl 6, and suggesting it in the office would get some good laughs out of everyone who's had to work on that codebase.
I'll still write perl when I need a quick one-off script to solve the kind of problem it's good for, like throwing a bunch of regexes at a bunch of text files.
I work full time as a Perl developer working on charter travel sites (not booking) using Mojolicious.
Pretty much anybody using Unix is using Perl one way or the other.
Its a bit like C. The language is so neatly integrated with the OS that its hard to beat it.
Its a bit like C. The language is so neatly integrated with the OS that its hard to beat it.
I've got billion dollars in revenue running on a Perl 5 batch system.
I have perl5 in production and we are pushing to migrate that codebase to python - for the plain and simple fact that it's getting harder and harder to find people with any interest in perl5.
If you would have actually read the blog post, you would have seen a "Rakudo Perl 6 in production" section in it.
The section in which obscure companies are using it for trivial tasks?
Sorry if that sounds harsh but in Python, Ruby, even Perl 5 large companies that bet the farm on the language are ten a penny
Sorry if that sounds harsh but in Python, Ruby, even Perl 5 large companies that bet the farm on the language are ten a penny
Yes, old established language are in heavier use at large, established organizations.
By that metric, COBOL is awesome.
By that metric, COBOL is awesome.
There are real companies doing real work in newer languages like Swift and Go too. Perl 6 is a toy in comparison.
Zoffix Znet I use it at $work for throw-away one-liners
Awesome
Zoffix Znet I use it at $work for throw-away one-liners
Awesome
Swift and Go are—dated from first stable release (and even giving them the benefit of counting Perl 6’s first stable spec as a stable release, but ISTR it took Rakudo a while to
catch the spec)—older, not newer, languages than Perl 6. Especially Go, which is nearly 10 years old.
There are real companies doing real work in newer languages like Swift and Go too
Apples and oranges, given that Swift and Go were started with the deep pockets of Apple and Google behind them.
Look at Ruby for a more fair comparison: It took 10 years to take off, stayed "hot" for ~3 years and has been in slow decline ever since.
Apples and oranges, given that Swift and Go were started with the deep pockets of Apple and Google behind them.
Look at Ruby for a more fair comparison: It took 10 years to take off, stayed "hot" for ~3 years and has been in slow decline ever since.
>Apples and oranges, given that Swift and Go were started with the deep pockets of Apple and Google behind them.
Go did not have "Google's deep pockets" behind it. It was something like 4-5 Google employees working on it in their spare time as a side project until it was released to the public, at which point it pretty much became an open source project like any other. The vast, vast majority of Go contributors are not Google employees.
It faced initial hostility everywhere, including at Google itself, and it's been incredibly hard work to get it promoted, marketed, etc.
Hell, I bet the core Go team has spent just as much time writing documentation, tutorials, shooting videos, creating news groups and irc channels and evangelizing as developing the damn thing.
Perl6 needs that - incessant, in-your-face promotion and marketing, conferences, videos, tutorials, the whole shebang. It's not the 90's anymore and I have choice when choosing a language to be productive in, so Perl6 better beef up its efforts to tell me why I should spend even 5 minutes of my time in learning it.
With Go, I was blown away with how easy it was to setup a scalable HTTP server, accept requests, parse JSON, reach out to multiple systems concurrently, the breadth and quality of its std. lib, etc - I had an immediate use-case for such stuff at work. I started investing time in learning Go before it hit 1.0, and it's paid off.
What's Perl6's killer use-case? Performance? compile-time safety? concurrency? scalability? Amazing std. lib? I don't know. It's not immediately clear. So if I'm comfortable scripting with bash/sed/awk or python for those harder use cases - why transition to Perl6? What does it offer in 2018?
Go did not have "Google's deep pockets" behind it. It was something like 4-5 Google employees working on it in their spare time as a side project until it was released to the public, at which point it pretty much became an open source project like any other. The vast, vast majority of Go contributors are not Google employees.
It faced initial hostility everywhere, including at Google itself, and it's been incredibly hard work to get it promoted, marketed, etc.
Hell, I bet the core Go team has spent just as much time writing documentation, tutorials, shooting videos, creating news groups and irc channels and evangelizing as developing the damn thing.
Perl6 needs that - incessant, in-your-face promotion and marketing, conferences, videos, tutorials, the whole shebang. It's not the 90's anymore and I have choice when choosing a language to be productive in, so Perl6 better beef up its efforts to tell me why I should spend even 5 minutes of my time in learning it.
With Go, I was blown away with how easy it was to setup a scalable HTTP server, accept requests, parse JSON, reach out to multiple systems concurrently, the breadth and quality of its std. lib, etc - I had an immediate use-case for such stuff at work. I started investing time in learning Go before it hit 1.0, and it's paid off.
What's Perl6's killer use-case? Performance? compile-time safety? concurrency? scalability? Amazing std. lib? I don't know. It's not immediately clear. So if I'm comfortable scripting with bash/sed/awk or python for those harder use cases - why transition to Perl6? What does it offer in 2018?
It took 10 years to take off
It’s been 18 years since Perl 6 was announced...
It’s been 18 years since Perl 6 was announced...
18 years since it was announced that language design would start. While development of the Parrot VM (ultimately abandoned) started in 2001, the apocalypses weren't all written until 2004 (never mind the Synopses), and Rakudo arguably was born that year as well, when pmichaud started working on PGE.
That's still 14 years, and it sucks for Perl as a brand, but as far as the quality of the final product is concerned, it's completely immaterial if it took 5 or 15 years to arrive...
That's still 14 years, and it sucks for Perl as a brand, but as far as the quality of the final product is concerned, it's completely immaterial if it took 5 or 15 years to arrive...
Thank you, I did read the post. I asked if anyone here (participating in this discussion) was using it.
A lot of zoopla.co.uk backend is Perl 5.
My first programming job was perl back in '97 for the LAMP stack. There was a lot of neat things that I did with it back then... and clever too. I remember writing a neat Tie::Array that was backed by a database... and then undoing it because it was too clever and not something that was maintainable.
The last time I touched perl professionally was in '09 during the perl winter. The web stack was moving in other directions - especially that of Java (I'm a corporate back end line of business keep the gears of the company turning type). I write boring code - which is good. Boring code doesn't surprise people and when I pull it up from 10 years ago, it still works. I try to avoid clever code now - it takes too long to get back into the mindset that I had when I wrote it. I'll admit to one bit of clever code with annotations on an enum that I've written in the past half decade... and that is in place to force what would be runtime errors to be compile time errors instead.
I looked at perl 6... there's even a bug report with my name on it ( https://github.com/rakudo/rakudo/commit/8d04bec ). I really want to like the language - it makes me think about some things differently... and here's the "but". But it all feels too clever. Code needs to be reasonable - something that I can come back to later and pick up again and continue on with minimal switching of the mind. Unicode operators, Junctions (as neat as they are), redefining operators... its letting me and encouraging me to write clever code.
I pull up the docs and see things from https://docs.perl6.org/language/operators that make me wonder if its gone too far. There's more than one way to do it... but there are more of them than Java 8's list ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.htm... ). I feel that there's more than one way is "more than one approach" not "more than one way to type '+'".
The code just doesn't feel reasonable anymore.
For what its worth, after not touching perl professional since '09, this past week I was called on to fix a LAMP stack. There's the CGI with a nice 'use CGI.pm' (the last change time on the file was from 2011). I was able to open it up, read it, debug it, and fix it in under an hour. It was straight forward, sensible, and reasonable code. I shutter to think what it will be like in another decade if someone comes by and asks someone to debug some 10 year old perl6 code and they open it up to find unicode scattered through it and trying to remember what =~= or ∘ does.
For my scripting needs now... I've been a Java coder for the past decade. When I want a script I'm more likely to fire up groovy. It runs, its stable, and it doesn't try to make me write clever code.
Sorry perl... you're just not my go to language for thought to code anymore.. and thinking in perl6 just isn't something that I'll find myself easily writing once or being able to figure out when coming back to later.
The last time I touched perl professionally was in '09 during the perl winter. The web stack was moving in other directions - especially that of Java (I'm a corporate back end line of business keep the gears of the company turning type). I write boring code - which is good. Boring code doesn't surprise people and when I pull it up from 10 years ago, it still works. I try to avoid clever code now - it takes too long to get back into the mindset that I had when I wrote it. I'll admit to one bit of clever code with annotations on an enum that I've written in the past half decade... and that is in place to force what would be runtime errors to be compile time errors instead.
I looked at perl 6... there's even a bug report with my name on it ( https://github.com/rakudo/rakudo/commit/8d04bec ). I really want to like the language - it makes me think about some things differently... and here's the "but". But it all feels too clever. Code needs to be reasonable - something that I can come back to later and pick up again and continue on with minimal switching of the mind. Unicode operators, Junctions (as neat as they are), redefining operators... its letting me and encouraging me to write clever code.
I pull up the docs and see things from https://docs.perl6.org/language/operators that make me wonder if its gone too far. There's more than one way to do it... but there are more of them than Java 8's list ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.htm... ). I feel that there's more than one way is "more than one approach" not "more than one way to type '+'".
The code just doesn't feel reasonable anymore.
For what its worth, after not touching perl professional since '09, this past week I was called on to fix a LAMP stack. There's the CGI with a nice 'use CGI.pm' (the last change time on the file was from 2011). I was able to open it up, read it, debug it, and fix it in under an hour. It was straight forward, sensible, and reasonable code. I shutter to think what it will be like in another decade if someone comes by and asks someone to debug some 10 year old perl6 code and they open it up to find unicode scattered through it and trying to remember what =~= or ∘ does.
For my scripting needs now... I've been a Java coder for the past decade. When I want a script I'm more likely to fire up groovy. It runs, its stable, and it doesn't try to make me write clever code.
Sorry perl... you're just not my go to language for thought to code anymore.. and thinking in perl6 just isn't something that I'll find myself easily writing once or being able to figure out when coming back to later.
This is a vastly larger change than python 2->3, and people are still using python 2.x. In short, there’s no sensible upgrade path, Perl 5 & 6 are very much their own language.
If Perl 6 wanted backwards compatibility, they needed to have thought about it a long time ago. Trying to hack in some Perl 5 style functions into it now seems futile...