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?".
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.
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.
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."
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.
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.
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.
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!
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.
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!)
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
My point is that you should be able to code python using Notepad but it is impossible to. Yeah, when multiple people complain of the same thing and you make up more and more complicated solutions for the problem, then you know where the problem lies. Also, you smell.
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.
But in the majority of editors that actual people use (mainly, jupyter/ipython), they are invisible. Not to distract from my point though, which is that a good programming language should be easily editable from Notepad.
This is where your bias shows. You define this "majority of people" by looking at your niche - you must be in academia or big data. I can tell you that in my niche nobody knows what the hell jupyter even is, and they use real editors like PyCharm, emacs, vim and so on, where whitespace is never a problem.
> 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.
Yeah, point taken about my bias. Dealing with python via jupyter has been my biggest source of frustration with python.
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.
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)
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.
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.
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?
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?".