Why Perl?
two-wrongs.com
two-wrongs.com
Yeah, because the ecosystem is dead. The flipside is that the bulk of Perl modules available are stale and don't receive any security updates or bug fixes. If I had a pound for every time I've seen a 10+ year old bug with no comments in the CPAN issue tracker...
> Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms.
Depends what you call "core syntax". The syntax available to you with a stock Perl install is certainly not small compared to other languages.
> With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems.
If you're disciplined, you can write complex systems pretty much as well as you could in Python or any other dynamically-typed language.
However, it requires a lot of discipline and experience, and with other languages you at least have good formatters and LSPs to help with that. Perl sorely lacks this kind of infrastructure.
I also think the lack of static types makes writing complex systems massively harder, but that's not a criticism of Perl in particular.
The way Py2to3 migration was handled was also some abomination. Meanwhile if I need my Perl code to work like old Perl I just write use v5.10 in header...
$ cat =latexmk | wc -l
10284
$ cat =latexmk | grep -v '^ *#' | grep -v '^ *$' | wc -l
5982
$
This basic build tool comes with a man page that is 26.5 thousand words long. Not your typical basic build tool.
To be fair, the way the Perl 5 to Perl 6 migration was handled was worse. It got so bad that they ended up renaming Perl 6 to something else, after it had already been released under the Perl 6 name.
Here is one of the earliest announcements: https://www.perl.com/pub/2000/07/perl6.html/ .. some quotes:
> So the upward migration path from Perl 5 to Perl 6 will probably be to run your code through a translator.
> Larry promised not to abandon Perl 5. The 5.6 maintenance track will continue as planned, and the 5.7 development track will eventually yield Perl 5.8, as planned. 5.8 will be the final release of Perl 5, but it will continue to be maintained and stable.
perl is at 5.37 now... so much for "5.8 will be the final release" :) Also, this does sounds awfully like Python 2->3 migration.
That's common in all large active open source project though.. like Firefox, Android, etc...
That’s true for any platform - Java or PHP. Perl has less support in modern IDE. Perl 5 to 6 transition failed many times so ecosystem lost many talents.
P.S. I wrote and supported large Perl codebases, no rocket science to manage it, if you do it right.
Some of us would call that "mature" or "stable". You don't have to change the basics of the language every two weeks and have people rewrite everything every three weeks (when the three week old version gets removed from ubuntu).
Look at LaTeX for example... ever goddamn academic uses latex, but it hasn't really changed for many years now... is it dead? Of course not.
I realize you're exaggerating and that you don't literally means 2 or 3 weeks, but I have Python programs I haven't touched in about 10 years that I still regularly use and that still work fine. Some of my oldest Go programs from over 7 years ago still work fine, and I'm pretty sure that if I were to try running some of my older Ruby or PHP programs (some of which is >10 years old) today it would still work either out of the box or with a few small changes (IIRC some of the defaults in PHP changed wrt. errors, so that might need a little bit of fiddling).
Even JavaScript – the poster child of "rewrite every 2 weeks" – is pretty compatible. You don't need to switch to $new_js_framework and many people use older stuff just fine. The language itself is pretty compatible (almost to a fault, arguably).
LaTeX is just packages (which do change, all the damn time, it's a curse) on top of Knuth's TeX. TeX, it's true, is feature frozen, Knuth has asked that when he dies the version is increased from a close approximation of Pi to Pi itself, and no further bugs are fixed. At that point TeX will be frozen solid, I'd be surprised if it lives another twenty to thirty years, its purpose is digital typesetting and er, you may not have noticed but we ain't printing so many books these days. Once we're not setting type anyway, TeX's purpose expires.
Knuth writes books. That's what TeX is for. If you write journal papers, eh, TeX is more likely to ensure you see in print what you intended, but increasingly Maths is done online in forums, nobody wants to wait six months to read a camera ready spell checked document - and meanwhile Unicode means squiggles are easier to write on a computer correctly, and programming means you can express what you meant in (terrible) Python instead of squiggles.
The Math professors at the University I work for do still write a lot of LaTeX (whereas in CS it's not so common as it was) but I wouldn't be surprised if an ordinary Maths undergrad can't write decent LaTeX today, so that's a smaller and ageing constituency.
Also, (La)TeX gives you a good-enough environment (especially with something like overleaf for sharing) for maths+crossrefs+citations that I'm not sure you can go simpler (I've tried with markdown and rst, but both end up being more of a pain, and the more maths you have, the harder it is to go without macros). Modern word remains a issue as I found out today, and most other word processors have even less support for throwing something vaguely academic together (i.e. with LaTeX I can just start dumping in content and refs and maths just work).
Is it?
(For Javascript, it would be several hundred pages per day - buts..lets not talk about JS).
Perl is an old geezer hacking out its dying last breaths. Calling it "stable" is fine. Death is a very stable state.
Back 15+ years ago, you'd see perhaps 2-3x more updates on CPAN recents per day than what's there today.
I'll always love Perl, but it's definitely on a long slow popular decline.
Python is today's Perl. It ditched the philosophical sermons of simplicity, minimality and all that, for practicality almost 15 years back. Since then, Python 3, has not shown any reluctance to add new syntactical features and sugar. The ecosystem is large. The language is flexible enough today to give Perl like feels from the 1990s and 2000s. Python is no longer big in web dev thanks to React, and its back to being a backend glue language(Java being a language for serious backend enterprise work) with Perl like philosophical leanings.
As of today think of Python as a Perl with mandatory tab based formatting.
I get what you're saying, but also that's kind of BS at the same time. If you're thinking Python type annotations are a great feature, then you're entitled to your opinion. Others might say static typing of a dynamic language is pointless, and yet type analysis does help find bugs in code... to which I would agree. And yet the cost of adding static type annotations, which are not very static, causes the cognitive load to increase, and increases line-noise in a very ironic way given how Python was originally parroted as a less obscure script.
To that last point, let's not forget about sigils in Perl, and how they sorta are a form of type indicator. There is not much ambiguity when the script uses a symbol out in front of any given type of variable ref. The topic of tokenizing variables/ constants, lists, arrays, hashes, or whatever... entities in a script is an academic topic, but it's not! Just look at GOlang for example, they made a huge mistake by exporting variables and things by using the First character of the object, upper or lowercase determines if that thing is exported. One does not need to go find the declaration of the object to see if there was an "Exported" key word annotated at the definition, as is the custom in Python. But the problem is now the language relies on latin language concepts of upper/lower case characters... which excludes many large spoken & written languages used around the world. Thing any Asian, or middle eastern typeset. Anyhoo, Python got that right... one could in theory write python in one's own native spoken language, and Perl can be written in Klingon if you want... any arbitrary spoken language. One of the reasons is because the sigil's are separate from the typeset, and can be changed. In this way, and many other ways, the pathological pragmatism of Perl is outstanding, and the lack of weird opinions is both a strength and weakness. One last bit about typing, performance, and correctness.... Perl is very fast. I'm always reading how in Python the `for` loop is preferable to the `while` loop because one is implemented in python itself, and the other is a very optimal C code implementation. Perl is optimised at every corner of the language, except modules, but also modules who choose... Python does that too for modules, like any math or data-science stuff.
On that last point, I want to throw a bone, and 100% agree most of the Perl libraries for modern practices are out dated, or non-existent, or security problems. A programming language is only as useful as it could be for any given college student to use for a 1st-year software-engineering program. So if the ecosystem is dead, the language is pretty much dead. That said, I know plenty of neck beards who still use IRC, and bang out Perl for quick prototyping... before moving to GO, C, or whatever...
Python is great to write well structured programs with modules, well defined classes, etc.
Perl is great to glue stuff together in place of shell scripts. I see way too often people attempting to write Python scripts to accomplish simple tasks and they inevitably end up being full of boilerplate, third party modules, stuff that breaks at every python update, etc. Perl is changing but it always stays backward compatible, it's installed literally everywhere and it has unmatched regex support, so it's super easy to run a few commands and process their output.
Perl is also arguably a better awk than awk and a better sed than sed, imho. I haven't used sed in ages because 99% of the time
`per -pE 's/reg/ex/g' -i <file>` is way more convenient and portable than `sed`.
Java is great for well structured programs and scalability.
Python is great for scripts, just don't let the programs grow too much in size.
(Not my opinion, I am impressed with how well Python programs can scale in size if using a proper framework e.g. Django)
Generic sneering in direction of "scripting languages", sure.
The very second a quick and dirty script grows into a full-fledged program, it immediately becomes technical debt.
It often becomes a business asset which delivers far more value to the business than any maintenance (often very low) which is needed
Other than that I agree, awk runs out of steam rather quickly. Shell runs out of steam fast as well(my cutoff for moving out of shell to a better language is the moment I need arrays.) But the killer feature of shell, the thing I wish was in more languages is pipes. The ability to flow one process into another process with a single character. I never did learn perl. but doing the equivalent to a pipe in python is a lot of awkward wrangling with subprocess and manually assigning streams. The way shell can pipe into and out of control flow is magical to me.
In Perl you can just run commands using backticks or qx// and get their output, and so you can pipe them in any way you want:
my @a = map { chomp; $_ } `ls -1 | sort | uniq`
open my $output, '-|', 'ls -1 | sort | uniq';
while (<$output>) { .. }Same with shell. You begin to give on it for non trivial work.
And if I have to fallback to perl periodically, why bother with awk at all? It probably made sense in the past, when machines were slow and awk was way more popular; but that does not matter now. Might as well go with more powerful option.
Eh? Python backward compatibility is excellent.
Most Python 3.3 scripts still run on 3.11. The only big breaking changes have been in asyncio, which was explicitly marked as provisional for years and if you were using it in ~3.6 you knew and were warned that things would change.
Packaging is another story, but we're talking about scripting, not distributing software.
Sure, so long as one wilfully ignores the 2.x to 3.x transition, that took 10 years. To be clear, to presume Python starts at version 3.3 is slightly weird, but we get it... One good example here is when pip stopped working for old python-2.x.
> Most Python 3.3 scripts still run on 3.11.
I would agree python forward compatibility is pretty good, but not so sure about backwards compatibility.
When the walrus operator first appeared, there was a period of time where scripts began using the new feature, and the version of the python interpreter used in all the places that script needed to run. Same thing for type annotations. And there have been plenty of breaking module changes.
> Packaging is another story, but we're talking about scripting, not distributing software.
That's fair, but avoids a big aspect of the problem statement, of when Python updates.
I'm now running mostly 3.10, solely because there are a few binary wheels for 3.11 that aren't yet on ARM for some reason (mostly ML stuff, which tends to be maintained by academia).
Any kind of argument that the 2.x -> 3.x transition is still relevant has to take in these timescales for context. Otherwise it just looks... dated.
The 2.x to 3.x transition was specifically an attempt at making a clean break, bookended by 10 years of compatibility before and after, so it doesn't really count here.
I deliberately chose 3.3 because that's the earliest 3.x version I'm aware of that started to see serious adoption.
> I would agree python forward compatibility is pretty good, but not so sure about backwards compatibility.
You're right. Forward compatibility is what's good, but that's what the thread here is about. Complaining about old Python scripts breaking in new versions is a complaint about forward compatibility. Backward compatibility is not good, but older Python versions are EoL anyway and if you want to use them you're on your own.
> That's fair, but avoids a big aspect of the problem statement, of when Python updates.
The relevant aspect here is that older packaging tools historically have relied on components of Python that have been deprecated for years and/or internals with no stability guarantee, which are gradually now being removed, and so older packaging tools (e.g. older versions of Pip) are finally starting to break. So yes, packages with complicated setup.py scripts from 2011 probably won't work as-is.
People love to complain about Python packaging tools, but the PEP 517 transition is much like the 2->3 transition in that most applications are not hard to upgrade, and most big open source packages have upgraded already. Python packaging was absolutely horrible for years, it's not surprise that something has to break in the process of making it less horrible. That most non-PEP-517 packages still install and work fine is a testament to how good forward compatibility actually is.
I get really annoyed when people complain about how Python ain't what it used to be. It's better than what it used to be, and a little breakage along the way is necessary to get there.
That happened because of what they were referring to - python 3.0 made a terrible decision with string handling that was remedied in 3.3, giving 3.3 significantly better backwards compatibility with 2 than earlier versions of 3 had.
If I recall correctly, they changed how `re.escape` worked between Python 3.6 and 3.8 (I'm not sure which minor change exactly) in terms of which symbols received a backslash before them, thereby breaking my code.
Python 3.8 supports tkinter, but not python 3.9. All my projects broke on that upgrade.
That's news to me.
Make sure you read Damian Conway's book "Perl Best Practices" as a guideline for crafting consistent and readable code. People's biggest gripes about this language generally revolve around poorly written code that is hard to read. Also, when writing regexes it helps to paste one or more example lines or matches above the regex so there is no question about what you are trying to do. 9/10 times I've found debugging SA perl scripts comes down to an unhandled pattern in a regex and this is what helps the most when re-writing it to ensure it doesn't break anything else.
For me, going through the llama book (Learning Perl) and actually doing the exercises was great. I would think I got it after reading the chapter, but when I went to do the exercise, I realized I had to look up the info again. Putting it into practice was great for internalizing the information. I can't believe there's an 8th edition now (from 2021!). I must have used the 2nd edition (1997) at the most, so I'm assuming it's still good.
Since you know sed/awk, you're going to see where a lot of the ideas came from.
It is dated but it's free online:
http://modernperlbooks.com/books/modern_perl_2016/index.html
I picked up a bunch of info from perl.org: https://perldoc.perl.org/perl#Tutorials
Perlmonks was a good source for certain specifics.
Doing is better than reading IMO. Open files, parse log data or such with regexes, sort them into a hash, and return that by reference. Perl has different ways of doing things that aren't common in some languages such as how it deals with binary data (see pack/unpack).
Coming from python, I would say forego the delving into OOP aspect of perl as it is more of an afterthought than a core feature. Focus on understanding data management with scalars, lists, hashes, and the core functions (Perl has native functions for things like sorting which are quite useful).
I managed to go from C to perl over a weekend but it takes hours of practice to improve.
I personally learn by practice. Writing stuff. I've read good things about the "Modern Perl" but I'll check out Conway if people here are vouching for it. Also, Perl's manpages actually teach you the language - another advantage of an older language from a time when people knew what manpages were and how to write them. They're not OpenBSD quality, but they're pretty good from my experience.
Extend this to any media you can by Conway. He's in my top 3 of tech presenters and I'm really not that into Perl.
If someone can't write readable, maintainable, understandable code unless the language has certain guard rails in place, then they aren't doing the above things and I would consider them a toxic team mate, no matter how much of a rock star programmer they are.
If someone can't write readable, maintainable, understandable code
it's about reading some books on clean code
Some of perl's features use syntax which is either very concise or uses implied operations or operands. Things like regexes, sorting, subroutine arguments, special variables can all be used in a manner which makes things more cryptic. In many instances you can be explicit (for instance with arguments):
my ($filename, $data_ref) = @_;
Rather than , randomly in code somewhere:
my $filename = shift;
If you cannot express something more explicitly in syntax to be clear you really should be using comments to elaborate.
Arguably this problem is the same across all languages. The issue with perl is that the brevity and flexibility of the language can exacerbate the grief one experiences when working with unfamiliar code.
A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".
I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure).
I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything.
Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.
Definitely you can keep your Perl under control with a strict(ish) culture but that tends to be the kind of culture Perl acolytes traditionally chafe against. I do somewhat blame the "there's more than one way to do it" Perl culture - that definitely encourages a, uh, "cowboy" approach to development that I've seen a lot in Perl houses (compared with, e.g., the Go houses that I now deal with because Go has a definite "one way to do it" culture.)
But yeah, pretty much any language can be twisted into a monstrosity if you let the devs run wild.
Any time I've ever tried to look into <insert random open source C project>, I typically find the most esoteric and tersely named functions inhumanly imaginable. Variables like gt, pn, r8, _on, etc. I mean terse to a point of cruelty. And yet these projects often have hundreds of contributors who are happy to gloss over said unreadability, or at least forgive it more than Perl.
Oh, and you're fully expected to speak their argot fluently, of course, otherwise you're a castaway to be thrown stones at.
Maintaining that in house codebase that used it was such a pain. I had to help keep that ORM up to date with the new data models after the acquisition.
Compare that to PHP where theres generally one way to do something right.
I worked on (and modernized) a distributed ETL system all in Perl some time ago, and applying the long-codified ideals of Modern Perl made it one of the cleanest codebases I've ever worked in.
I see lots of Java that's written in a simple and direct manner, but that has no documentation/comments and where it's a pain to find the execution flow in between so many classes and layers (especially when there's dependency injection).
If it were just dependency injection it would be one thing but when you have all the opaque behavior that comes with a framework like Spring you get a bunch of spooky action at a distance code that can't be followed simply by traversing the call stack.
Comments don't compile, so the only documentation of what code is doing guaranteed to be correct is the code itself.
Really like comments for providing edge cases and information that can't be found by reading and understanding the code.
You can write some absurdly powerful, really terse programs that make absolutely no fucking sense to anyone else.
Some people see this as a point of pride - Perl golfing etc.
My point is that there are extremes here that are worth considering: and Perl is on the bad side of any exchange involving the question of readability. The community doesn't help, either: they're as bad as the Rust Evangelism Strike Force, but in different ways.
Who do you think RESF learned their ropes from? ;-)
This article has aged pretty well: https://www.perl.com/pub/2000/12/advocacy.html/
I love Perl, but that's the part I don't like. If you, for example, have to parse a very deeply nested piece of JSON, you're very quickly into that weak spot. Lots of crazy sigils, braces, etc...all mushed together. Worse if you're having to use refs, globs, etc.
What you're running into is insufficient modeling of the problem, not a deficiency unique to any language.
I can still _read_ Perl code (and used to read PerlMonks for the koans), but it is definitely an acquired taste when whomever wrote it decided to golf a bit to save typing or do some clever re-use.
CPAN is better than its equivalents. The consistent documentation style and location, focus on tests, and so on is excellent. Miss CPAN.
Python is a fine language. Its type system feels like a toy after using TypeScript, but last time I used Perl in anger there was nothing. The scoping is weird, and I think makes readability worse, but you get used to it.
TypeScript is awesome, but setting up the compile step for a new project so it works with testing and so on, weird edge cases about which module system you’re using, these are irritating.
I love Perl, and I think in Perl, but given its ever-decreasing mindshare, I’m not sure what major new projects I’d start in it. At both the TS and Python role I’ve written Perl that acts as a superior bash, and it’s been excellent for this, long may it continue. The big issue is that I’m reluctant to share my Perl with the rest of the team because I’m the only one who knows it
> focus on tests
…which at critical moments may turn out to be just LARPing. I had to rewrite some tests for a dependency of a dependency of my project so that they had any meaning at all.
The test suite was unchanged for a decade and it had been talking to some random web services on the internets. There is an unanswered bug report that tests have stopped passing entirely some years ago.
Another project failed its tests due to a dependency being bumped, and there was a fixing suggestion unanswered since 2014. I don’t know if the author is actually alive.
I guess it’s soothing to see an endless output of “ok test x” from a test suite, makes you believe the project is real solid, or something.
Use whatever has the lowest TCO to you that lets you get the job done.
Perl is usually that tool for me, but yanno TIMTOWTDI. Basically every programming language is quite expressive and has adequate tooling to profile, test, cover, format and lint & run thru CI these days.
I have noticed pretty much everyone using X language still thinks the others don't have said features though. Good for a chuckle in dev chats.
Good question!
https://www.garagejournal.com/forum/threads/table-saws-recom...
I too care about my tools. Some feel good in the hands. Some get the job done better. Some I reject outright, despite their ability to get the job done. I care deeply about my tools.
Personally, I'm inclined to suggest that there are definitely "good enough" tools out there and you can get stuff done with those too, instead of spending a lot of money and time looking for the best out there, or getting attached to them. Kind of a utilitarian look, I guess.
As an example, I got a Chinese chainsaw (marketed as Lithuanian, but most likely just a white-label product) for cutting trees and prepping firewood, for about 100 EUR. It won't last me decades like a fancy Stihl saw, it will have more engine vibration and the fuel economy won't be great. Yet, none of that matters to me much, because it has the critical set of features that I need (it cuts wood, starts well, has decent throttle response and has a functional saw brake).
Whether the same applies to programming and how much is probably quite subjective. Personally I like something like IntelliJ IDEA or other JetBrains tools, but one get by with Eclipse or NetBeans or whatever. In my eyes, the same applies to programming languages - you most likely can write a decent codebase in Rust, Go, Java, .NET, Python, Node, Ruby, as well as languages like Perl and PHP.
Some might be more comfortable with one language over another for a variety of reasons and surely the average codebases will be a bit better/worse depending on the language, ecosystem and the community as a whole. But if it lets you pay bills and ship features, then I would be okay with someone picking PHP/Perl/whatever over one of the more favorable languages.
10 years ago: range 5 years ago: xrange Today: range again, LOL!
I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.
70% is python 2, 30% written/rewritten recently is python 3.
I hope they are paying for security updates since python 2 has hit EOL 3 years ago and libraries had been actively shamed if they didn't drop support for it long before that.
Python 2 code is being transitioned to 3 and there is a plan to do so for all of it, but it's definitely not a highest priority task. Usually done when new features are requested.
This isn't ideal, but it's not a reason to panic. None of the code is externally facing, none of it accepts user input directly beyond a press of a button in third party software that triggers it. All it does is pretty simple stuff. Infrastructure provisioning etc.
Also Python 2->3 transition was a one-time thing that developers had over a decade to perform, it may have been painful for some but saying it's a random thing that happens "every few years" is a bit dishonest.
Some of them (telnetlib) I can vendor in, but I wonder how many people who use them will be caught pantsless?
What has me a little bit confused is that we're in a thread talking about how Python somehow "flubbed" after 2->3, despite an explosion in popularity during that period culminating in it being arguably the most popular programming language around. And the counterexample is supposed to be Perl, a language which I have enjoyed using but which has fallen off a cliff during the same period, and which has had an even more enormous and self-defeating flub (Perl 6 aka "Raku").
As I said, I understand if Python 3.x was painful for some organizations. I think the suggestion that it was a failure and that Perl showed us the right way to go is a pretty silly one though.
It is weirdly comforting to observe how certain things never change over the years, even in tech. One of them is the hyperboles people deploy when attacking programming languages that they do not like: "I don’t know of any tech companies using Python for anything serious anymore". I mean, except for being the 4th most popular language amongst professional according to last year's Stack Overflow survey. Only JavaScript, SQL and HTML/CSS are more popular. Yes, yes, I am sure it is dying... any moment now.
My claim is that the big names don’t really use Python outside of data pipelines. Where I’ve worked (including an org that had had Guido on it for a while) usually had guidance saying “no new Python projects”. You can ask people at Google, Meta, etc when was the last time they wrote production Python code if you don’t believe me.
That’s not mutually exclusive with web devs on Stack Overflow using the language, nor does it take away from its success in academia.
Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?
And same question for grandparents. I'm not a great dev, average at best, but at least I control my systems.
It will then compile for that version.
[EDIT] Check out issue trackers for such projects, some time. "Build broke due to [thing] being too new" is a routine issue to encounter.
Stable features will never be removed or broken. If you don't use unstable features, and aren't relying on something that is unsound, your code will continue to compile. If it doesn't, this is considered a bug and should be reported.
This isn't just a hollow promise either, they run tests against most of the crates on crates.io when making changes to the language to ensure that old code is not accidentally broken.
Claiming that rust isn't a stable language is pure misinformation, but sadly not uncommon.
It's also worth noting that some of the language is specified informally, this is the "reference", there are also RFCs for new features that describe exactly how the feature is intended to work. This isn't a complete formal specification, and could use a lot of work, but I don't think a formal specification with a committee is any better than an informal reference, assuming the reference is exhaustive!
I have, more than once; it worked perfectly fine.
The only time it's broken for me is when the code had unstable nightly-only features, hidden behind a "nightly-only" feature flag, which was rejected by the parser on a newer Rust compiler, even though it would not be compiled due to the feature flag being disabled (even though it wouldn't be compiled, it still had to be parsed; IIRC, it was the change to the inline assembly syntax, and the fix was just to change from "asm" to "llvm_asm").
Outside of 2 -> 3, I can recall only one or two instances of dealing with this in the last 15 years. One was the introduction of "with" and "as" as a keyword. The other one I can't even remember.
None of the code I have written on my personal PC in all these years needed modification due to these changes (all of them were in 3rd party code I needed to patch). I still have Python 2 scripts continually running! I have Python 3.10 installed, and never had to fix a broken script of mine since I switched to Python 3 several years ago.
> 10 years ago: range 5 years ago: xrange Today: range again, LOL!
Eh? When I began using it heavily (before Python 3 existed), both range and xrange were heavily in use - one was a list the other was a generator. Since Python 3 has been stable and fast (circa 2013 or 2014), it's been only range.
Your sample size of one needs expanding.
Citation needed? Just a week ago I used a Python library completely unchanged from 2013.
> Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years.
"Seemingly random" is both wrong and insulting. The BDFL did step down and was replaced with a steering council, so maybe that's what you're seeing. I do agree that `match` was a bad addition to the language, but that's one small example among many supporting the opposite opinion.
> 10 years ago: range 5 years ago: xrange Today: range again, LOL!
Huh? Python 3.x has only ever had range(), so it's been range() for at least 10 years.
perl you really had to properly abuse it to make it actually crash.
Now, some people see that as a feature not a bug (for either perl or python's behaviour)
https://www.tiobe.com/tiobe-index/
This whole Python/Perl competition was always a bit silly. Both languages had and have their place. I would say Python is so much more popular because it found a niche in ML because of how much more easy it is in Python to interface fast C modules. So you get to write simple Python programs leveraging blazingly fast math libraries. That was always a bit more tricky to do in Perl.
But Python as a language is definitely not as flexible as Perl 5. Last time I checked Python didn’t even support multi-line lambdas because its inventor hates those. Python is very much designed in a top-down approach and tries to guide all Python programmers into how there are supposed to solve their problems. Perl 5 was designed with its famous „easy things should be easy, hard problems possible to solve” philosophy. It allows for meta-programming in all the right places which a seasoned Perl developer can reach to when necessary. Perl 5 is a nice middle way between C and Lisp.
That being said modern JavaScript turned into a powerful language that fits well into both the frontend and backend side of a web application nowadays and, hence, kind of replaced Perl as glue language for the web. It will also push Python out of web backends at some point I believe.
Raku / Perl 6 has been the R&D project it set out to be with interesting new features and smoothed out syntax.
You can use either freely as meets your needs. If there's a "debacle" here it's the misunderstanding.
Perl 6 was meant as the bravest experiment with C-like syntax in 30(?) years - attempt to nicely mix few programming paradigms and styles. And that we really have in Raku.
They was talking "Perl is dead" but it never was and isn't. Maybe it looked as clinically death with out of body experience into ideal language heavens but since decade or so it is back. Solid and backward compatible as always.
And there was problem for some with "parallel language versions" marketing so Perl 6 was renamed to Raku. The harder question was "Which one I need to learn ?", but it is newbie programmer question, you need to know many languages because it is standard programmer life experience. And it is XXI century and many technologies are around.
On the other hand Python usage is scientifically researched as being a "write abandonware" language :)
Sorry, but originally it was meant as the replacement (and I was physically present at its announcement at OSCON in 2000). It wasn't until 2008 when the "sister language meme" was generally accepted, that the paths diverged instead of being sequential.
Ok, multi-lang virtual machines wanted to replace Perl5 binary.
But: :)
- multi-lang vm's are proof that v5 syntax wasn't mean to be eradicate at all cost
- there was no plan or push to instantly obsolote, uninstall and deny of Perl 5 usage
- I'm sure there was a conviction that some Perl 5 installations will stay for long time period into the future. Or as long as possible ~~ forever.
So it wasn't like Python 2.7 replacement. And plans even assumed continuation. And some from the start wanted to have both langs :)
To counter that, Inline::Perl5 (https://raku.land/cpan:NINE/Inline::Perl5) was developed. It gives you access to 99.9% of Perl's functionality transparently, such as being able to subclass Perl classes in Raku, and vice-versa.
> Unless it is going through the deprecation process below, the behavior of an API must not change in an incompatible fashion between any two consecutive releases. Python’s yearly release process (PEP 602) means that the deprecation period must last at least two years.
In practice, it's usually longer than two years, except on features that were considered provisional in the first place.
That was a good, "Why Perl?" for me. YMMV.
This is actually a deep flaw, rather than an advantage. There are so many ways to do a single thing in Perl that you just give up seeing them in the wild. It would take months or years of practice to get comfortable with every nuance of Perl. Even Google fails to help often (try Googling what "$_%@" means). I get it; the terseness can feel for an advanced user, but folks like me, the verbosity of Python and Javascript is much more preferable.
(You could imagine at a stretch those characters as part of an unrealistic expression, like "print $_%@array" meaning "print the value of $_ modulo the length of @array", but you can write messy code without spaces like that in many languages.)
I used to think heavy criticism of Perl's use of punctuation characters were valid, until I looked at PHP, Ruby and Rust, and realised that some of the more popular and even loved languages are punctuation-heavy too. I prefer languages with less punctuation (despite doing expert level Perl), so I think the use of sigils ($variable) is not the best design space, but I think the criticisms of that kind which single out Perl are more like a have-a-go meme than a level-headed comparison by now.
The mandatory dollar sign in variable names looks dumb in php, I grant you that. As well as the dot for string concatenation. But perl insists on the distinction between $variable, @variable, and %variable; which is just wild. How is it that python works fine without all that noise, for chrissake? Or javascript?
You would prefer *ref like in C? You can actually do that (it's a GLOB type).
The place people get tripped up is that $scalar can be a string, or a ref.
You check that easily with ref $scalar eq 'ARRAY' or whatever guard you want.
> but you can write messy code without spaces like that in many languages
I think it's fair to say that Perl forces these extra hoops more than any other language.
I have thought for a long time to try out Raku as Ive never tried Perl and it feels like the modern version might be easier to get into as it maybe avoids some of the baggage.
Is this true, or do I miss something by skipping the original?
I believe Matz intended Ruby to please admins, not only programmers, from the very beginning. Following this, me and few buddies used it mainly for admin tasks for over a decade, doing things somewhat orthogonal to the then-emerging RoR crowd.
Although ofc the author is right about Perl's unbeatable ubiquity..
Rails definitely sucked up a lot of the use case attention.
(Personally for simple admin scripting work, I tend to use ABS-lang.org and turn on Ruby syntax highlighting...)
Much of the fun was due to influence from Yusuke Endoh:
Honestly I don't know how it behaves in practice - still on my list to check.
Over the years I more use Go where I used Ruby - for a single feature of delivering a single no-deps binary to the server / container where it's supposed to do something.
But I still love Ruby for exploratory stuff.
And I see there was a lot of progress with the VM - one of my favorite side activities is to disassemble the opcodes for trivial and non-trivial sources... (doing same in Python, actually..)
[Looks like I just answered to several different commenters at once ;)]
That's good and it's actually the Perl way, Perl was always about helping getting stuff done.
After I moved on to the next job, working on Python was so much easier. I have never written a line in perl since then.
And everyone knows how system administration scripts always grow to more than five pages, so it's better to just start in Python.
I can understand why someone who prefers Python would go that route, but it is definitely not more capable than Perl in that domain.
Not true anymore. FreeBSD dropped it from base.
>With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems.
History shows different. Perl was never designed for this.
>I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators.
I concur. I also have 10-ish lines perl scripts running on my systems since 10-ish years, doing exactly what it was written to do. And if the data protocol changes I will just drop 10-ish lines of code and write new 10-ish lines of weird looking, compact and efficient code. I never care understanding my code. If i ever read it again it's just to have a "wow, what does this even do" moment at my own code. For me, write-only is a feature.
>Perl can be used nearly as a shell replacement for very quick scripting.
Yet there is no generally available shell (like Bash or zsh) written in Perl. This is a weird thing I'm still trying to cope with in 2023. It may be because the term "shell replacement" is used wrong. Did you mean "shell programming"?
>Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms.
... I don't know. 27 years later, I still like to flex my reptilian brain reading perlsyn manpage. I like to think of perl syntax as a set of loose rules which you can bend to your liking. And the things you can come out with... oh, boy.
Perl is good tool for coming up with a solution really quick. And most of the times, you will just keep running that code for ten-ish years to come. Also, Perl is more of a philosophy than a programming language, like Forth is.
Its biggest disadvantage was the community itself. They just kept using it wrong, over and over, trying to serve the greed of a corporate world. The proof of this is Perl 6, the community rewrite of Perl. Looks cool. Won't use it. I think that's why it's now mostly referred to as "raku" instead of "Perl 6". It's not a Perl.
> History shows different. Perl was never designed for this.
I beg to differ - after all, what was Perl 5 about? Adding objects and modules were features only needed for large programs. Just looking at CPAN shows numerous modules of significant size and complexity.
The thing I hated most about it was that it had several ways to the same thing, which made it extremely hard to read code because you had to understand the nuances and could cause bugs. For example I vaguely remember that Perl had 2 ways to specify “or” but they had different preferences. The fact that scalars and vectors had different namespaces meant that you could get absurd looking code like $a[$a].
I’m glad that Perl is all but dead.
And I think it is possible to write very readable, maintainable Perl, but one has to really want to and make it a habit. Perl has a couple of footguns, and one needs to be aware of those.
The main reason Perl dropped out of favor, IMHO, was the combination of the Perl 6 debacle and Ruby on Rails taking its place for web development. But in its original niche, Perl remains a great choice.
You can convert an IP to its hex representation and change a symlink in one line. That's a superpower.
Cramming things in one line can sometimes be neat but Perl took that concept and went bananas, and now Perl has because the punchline to many jokes, justified or not.
$hexip = sprintf("%02X%02X%02X%02X",split('\.',$ip));
system ("cd <REDACTED_PATH>; ln -fs $boothd $hexip");
I think, in this case, perl being hard to understand is the joke itself.
cgi-bin scripts have little in common with the above model.
If you're using containers, then IMO, you're no longer serverless. The reason being...
> Nothing to maintain or update outside of your own code
Unless your Dockerfile uses something like "FROM python:latest", you'll find yourself having to update your Dockerfile to pull in new images on a regular basis in order to get the latest package updates.
People usually like to have reproducible builds though, so will instead use something like "FROM:python:3.7.16-alpine3.18". Except, sorry, that's out of date now. You need to update to "python:3.7.17-alpine3.18."
It's quite easy to use with statically compiled languages, and a bit less so with interpreted ones like Python, but you need to use a multi-step build with first an image containing your dependencies to compile, and then a stage from scratch copying just the resulting artifacts. That way your production image is extremely light and has no attack surface or stuff to update outside of your own code. The main downside is that debugging live is not easy (if you have some networking errors, you can't just exec inside and do some ping/curl/netstat/etc. to check stuff, because you can't even exec inside due to no shell being present), and requires extra tooling like cntr/cdebug or Kubernetes Ephemeral Containers which will attach a fuller container (e.g. busybox) to the running scratch one to be able to debug.
https://chemidy.medium.com/create-the-smallest-and-secured-g...
https://medium.com/analytics-vidhya/dockerizing-a-rest-api-i...
For example, developers who are really focused on up-to-date skills will likely recognize that cgi-bin has had a "scent" to it since the early 2000s.
Developers who are of a systems mindset will automatically think about contingencies. How will this scale as a system, what if I need to hire developers, what if cgi-bin goes away or gets expensive for various reasons, what about security, who is watching it, etc.
This sounds like enterprise level thinking but a lot of people think this way for a hobby, even.
Just like you said, it's really the strict-specification- and use-case-focused people who will still benefit from cgi-bin still being really cool in its own way.
I'd guess that it's a good idea to have at least some plan to move along, or keep one's finger to the cgi-bin wind, so to speak, if the project will be used by an audience that's taking it seriously. But this perspective can also suck a lot of fun out of things... :-)
The utility of "serverless" is it rolls up all the deployment and execution in automation. All of the infrastructure is managed externally and automatically for you. You also get auto scaling for free.
With a VPS you've got some minimal cost to leave it running. With "serverless" you're only paying for invocations. If you've got a handful of hits a day it costs so little you might not be charged for months. If you get a spike of traffic with thousands of hits you don't need to scramble to scale up your "simple" CGI server to handle the load.
So this fantastic language was already there and there was already an Elastic module in CPAN. I'm biased, but you can't call this a dead language.
As a young impressionable programmer I drank that Kool Aid.
Honestly the whole post doesn't really make sense to me and it looks like someone is just paying homage to a thing of the past. You can clearly see the decline of Perl here: https://redmonk.com/rstephens/2021/08/05/top-20-june-2021/
Not true. "anything" is too strong of a word. There's plenty of simple code that works fine in both 2 and 3. For basic scripts, it's not hard to make code that is compatible with both, with the only odd thing to do is using parentheses in your print calls. You can even use "from __future__ import print_function" in Python 2 code to get Python 3's print() behavior.
> anything using async will need 3.4(?) anything using type hints of f strings needs 3.7( or 8, I get hazy)
What's the alternative? Should a language never receive new features?
technically correct is the best kind of correct.
You can write clean, maintainable code in Perl, but the language simply isn't designed for that, it has other priorities. The whole "there is more than one way to do it" thing is obviously not how you get consistent code, first class regexes which are one of the biggest strengths of Perl are notoriously hard to read, and the "ugly" options tend to be the easiest to use. It is all great for getting stuff done quickly and efficiently, not so much for maintainable code.
Languages that favor readability will typically try to go towards the "one true way" of doing things, use more descriptive words in standard libraries, have an annoying "bondage and discipline" compiler, etc... Perl has little discipline built-in, so it has to come from the programmer, don't expect it to guide you to the cleanest way, but you can expect it to help you write everything in one line.
The I found Kotlin to be an acceptable "typed Ruby". :) It's a bit steeper in the learning curve, but apart from that it fits the bill pretty well. Though Ktor is not nearly as rich in ecosystem as Rails is.
Nothing is eternal. Some dependencies, like CPAN modules, need to build stuff in C (during installation). It is impossible to know if these dependencies will install and build 'unaltered 10 years from now'.
1. I definitely want to use third-party libraries, so I don't have to re-invent the wheel
2. I hate having to install and manage third-party libraries on all systems where I might want to run something.
After using golang and rust, it's really painful to go back.
I feel the same way. Rust is pretty bad in this sense because you have to install an entire third party compiler and toolchain from outside of your repositories. Usually recommend in the form of,
>curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
And if you don't install the third party rustc from out of repos your rustc is only able to compile code written $now till about $now + 3 months. After using perl it was really painful to try to compile random rust code I found. It's not that it's impossible to write forwards compatible rust, it's just that rust devs are mostly hostile towards it. Reactions to this comment will be, "3 months is too old to expect things to compile. You're holding back progress." And that's a legit POV. But one I'm glad Perl doesn't share.
Likewise I've found CPAN to usually get out of my way… but at least in FreeBSD land I've not had to fight perl packages too much. And I've definitely been missing having Perl in the FreeBSD base system recently.
And if you don't install the third party rustc from out of repos your rustc
is only able to compile code written $now till about $now + 3 months.
I find any Perl application of reasonable size collects a few dependencies and they can cause pain when installing on different systems.
And god have mercy on you when you find a transient dependency with an unfixed bug reported a decade ago whose author went AWOL.
> I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators.
ChatGPT says "modulo" means "except for, not accounting for" in this context.
I always thought modulo was explicitly a math term to mean the remainder after dividing one number by another.
Where did this other "not accounting for" definition / usage come from...?
From Wikipedia, the free encyclopedia This article is about the programming language. -- snip -- Perl is a family of two high-level, general-purpose, interpreted, dynamic programming languages.
Or maybe you possess some hidden knowledge about Perl ? Some NASA backdoors ? RCE's ? Tell us if you know !
If it did, C authors shouldn't have ignored systems languages 10 years older than C.
If you can make readable code in it, then you are a proper programmer.
If you can't then you'll need to look at the other code you write, because that's probably unreadable as well.
"Scales up": I don't know of any widely used projects written in Perl with tens or hundreds thousands lines of code. I know a lot of big projects written in Python, JS, Java and C#.
"Compatibility": Author means stability. Last breaking changes in Python were in Python3, which came out 15 years ago, and no breaking changes are anticipated in the foreseeable future. So I would say it's fairly certain that Python programs written now would work 10 years from now.
Incidentally, Perl also attempted to make breaking changes with the transition to Perl 6. The only difference was that it didn't come through.
"Extensible": I don't understand this metric at all. Suppose I want to implement a module in C++ or Rust. Is it significantly easier to do in Perl than in other languages? I don't think so.
* DuckDuckGo
* cPanel
* booking.com
* craigslist
only ruby is comparable, but ruby breaks compat way too often.
Python (or at least the standard library) breaks quite often compared to some other more conservative languages. For example they recently 'broke' dataclasses somewhere between 3.8 and 3.11 by changing how initialisation of default values works and I had to fix some code.
Last breaking changes in Python were in Python3
If you only stick to the core language, then yes. If you make use of a lot of the standard library that comes with python by default, then all bets are off.