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?".
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.
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.
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.
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."
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.
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.
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!
Being "forced to use Python" sucks as a Perl developer.
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!)
I mean it only as a half joke, unfortunately.
As a side note, "forced" often means "we have a lot of beginners here and they want to do Python".
Better than rewriting failing Python or Node projects once a year.
If you want that regex behaviour in a more modern language than Perl5 then Ruby is there.
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 running as a slang on MoarVM or JVM would give it a JIT compiler
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.
There's a phrase I never thought I'd see.
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.
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 >>[=]>>.
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
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.
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.
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.
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.
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.
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.
With that thought in mind, I am pathetically grateful for Python.
> a good programming language should be easily editable from Notepad.
The '90s called, they want their notepad back. Please. Not even Windows users run Notepad, anybody with a minimum of knowledge will use Notepad++. And guess what, N++ has plenty of features to deal with whitespace.
But there are still plenty of cases where you will come across python via a bad interface, such as a shell interface to a server that I haven't set up properly (I come across this a lot since I've a lot of code running in clusters), and new computers or other people's bad setups or computers.
Even when using elpy-mode in Emacs, I've had problems when I tried to tabify and untabify a file (to change indentation length), which completely changed program logic in multiple places, and resulted in subtle bugs that I caught much later.
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.
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.
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?
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.
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].
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.
... 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".
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.
At best, it's a hack. Impressive, sure, but not something that you could rely upon. There's still no sane upgrade path here.
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.
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.
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?
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. :)
I wonder if Fortran 2008 wasn't called Fortran, could it be sold to computer science people as a "fast, type-checked matlab".
Eventually one would use Perl 5 from inside Perl 6 with the "use v5" statement.
[1]: https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter...
Quite true! In fact, the redesign took more than a decade and a half (July 2000 to Dec 2015). A record worth breaking!
Perl6 has some compatibility -- at the wetware level.
Which is not nothing.
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...