It's certainly less stable and ubiquitous than Perl. These days I'd rather be on Python (better libs, doesn't spook colleagues, very common on Linux boxes), but it's not an unreasonable position.
Very much so, insofar as code written a few years ago probably doesn’t work anymore. 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.
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.
How about a fortune 300 company I consulted for that uses python pretty much exclusively for the deployment processes of their 200+ web/cloud apps? Some of those apps have 1 VM plus a DB and a dozen users. Some have environments that cost £30k a month and 5k users. Python is the only language used for CI/CD. Plus power shell for stuff that needs windows server.
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.
Nope, not for python 2, but there was tracking of published vulnerabilities. None that were discovered during my time there affected existing python 2 code.
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.
The criticism is that the Python team will deprecate and remove functionality as it's not needed? Boy, you're gonna hate PEP-594.
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.
My feeling is that if you're the sort of org who will update the Python version you use, you're going to be switched-on enough to handle this somehow. From the sounds of things it it's a bit of an inconvenience for you that you'd understandably rather not have, but you have it under control. I don't personally use any of these "dead" batteries though, so I can't speak with any authority on the matter
Well yeah given that some people are still talking about issues from a software release that happened 15 years ago, it would be incredibly unlikely that they'd want to repeat that.
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.
Saying that the Raku Programming Language is a flub, indicates to me that you do not know it at all. Getting Unicode support right by itself should be an indication that it is better than Python 3 in that respect. And let's not start about the fact that the Raku Programming Language does not have a GIL, allowing true multi-processing features and event handling.
In terms of execution the development and release of Perl 6 was undeniably a flub. What eventually got released was ultimately a fine language, but it was years late, largely incompatible with existing Perl code (hence the rename) and a sizeable portion of what was left of the Perl community didn't adopt it and stayed on Perl 5.x. Sizeable enough that there are now some rumblings around tidying 5.x up a bit and releasing it as Perl 7.
> 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.
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.
You just read what you want to read, friend. I don’t particularly dislike Python, in fact I wrote about 50k lines of it a few years ago.
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.
If that's what best practices are for these languages, I now better understand my collegues who will not move away from C/C++. Having to identify a specific compiler version for each bit of code sounds like a nightmare.
C and C++ projects of any notably complexity & size often suffer from those exact same kind of "library or build tool or compiler updated—now the project won't build" problems. Absent some pretty heroic & unusual levels of discipline from all involved, anyway (which is also a way to avoid those issues in most other languages that have them).
[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!
> Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?
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").
Not my experience, though I think it was more due to libraries (but need to update a library -> needs newer compiler version -> needs to update another library, etc)
> but a lot of it is the language itself making seemingly random changes in direction every few years.
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.
This goes against my own experience. I moved from Perl 4 to 5 and from Python 2.x to 3.x and have dozens of projects written in Python that have been constantly updated over the past 10 years, none of which broke due to those things - and they are not all in the ML space.
> Very much so, insofar as code written a few years ago probably doesn’t work anymore.
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.
Can confirm, recently written scripts require modification pretty much every minor version. Take the limit on the default size of BigInts now. Why? Just... why? I had to look into every script add the override line at the top (or check the entire script it ever assumes unlimited BigInt anywhere). No wonder there are still Python 2 scripts in use.
I wanted to like Python.
Every time I tried to use/learn it, the "program" I wanted to use had some issue.
The very first one (some 15 years ago) depended on mutually incompatible libraries so I had to spend time not only learning Python but fixing the libraries to work together.
Next one was a dlna server that managed to use up all 4GB RAM available on my NAS and make the whole system unusable.
Then there was a "compiler" that worked on all OS-es except that on Windows it would 100% not work due to some path string handling when starting a process. How do you even get to that point...that could have never worked on Windows and it's not like Windows is some marginal never used system so no testing was required.
Then I tried to write a simple script to transfer some emails via IMAP...and Python idea of supporting IMAP is for me to read the RFC and build the correct string to sent to IMAP server...WTF???? That is the assembler lever of "support" of something.
I did try to do that and then I ended up with multiple pages of something that looked like level of arcade game with climbing hills and cliffs of code where it was hard to tell if code was meant to end or if someone got bored of writing and just gave up.
I hate Python.
Deprecation doesn't really mean that your script is broken or going to break anytime soon. unittest.UnitTest.assertEquals() has been deprecated since 2011-02 (Python 3.2) and is set to be actually removed 2023-10 (Python 3.12).
Not always, but for the sake of your sanity you need to fix those deprecations, if only so you can see the new ones, one of which will break your script at some point.
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.
Having used Python and Perl professionally, I'd have to agree with really all of this. I just want to emphasize Python's niche in ML (since that's what I do with it mostly lately) - it was also helped by a large, early set of libraries specifically for ML that other languages either still don't have or are playing catch-up (Elixir), and its ease of use among academics, a lot of whom went straight from academia to industry.
Really? Was Perl 5 deprecated with prejudice across ecosystems, forcing projects to work with a janky, still-evolving replacement well ahead of production-grade stability? Because the boot marks in my ass from the forced march to Py3 are still bleeding.
What ? First Perl6 wasn't meant as replacement for Perl 5, v5 was meant to stay forever, maybe to be improved when possible. And that we have.
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 :)
> Perl6 wasn't meant as replacement for Perl 5, v5 was meant to stay forever, maybe to be improved when possible. And that we have.
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.
Indeed. The original plan envisioned Perl being a slang in the Raku Programming Language. That plan failed because Perl is largely dependent on C-code plugins that are used whenever Perl is considered to be too slow (which is often). So being able to support Perl syntax in Raku, would only allow use of Perl-only modules from CPAN (of which there are way too few).
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.
Which feature? Deprecation warnings tend to be in place for several years before removal. There's a formal policy for it: https://peps.python.org/pep-0387/
> 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.
So, skip over presented facts, use some sentence template which only insults and think you do something wise and rational ? I don't think HN was meant that way...
Or maybe you possess some hidden knowledge about Perl ? Some NASA backdoors ? RCE's ? Tell us if you know !
Perl can be seen as a middle ground between AWK (and bash and sed) and a more general-purpose language like Python. It prioritises brevity of expression over readability. Using regular expressions in Perl feels more like a "first-class experience", where most other languages treat it as just another library.
Perl's usefulness has a narrow peak like the Balmer curve, because Python is better for system administration related tasks that are more than four or five pages of Perl.
And everyone knows how system administration scripts always grow to more than five pages, so it's better to just start in Python.
That might be true if you already don't like writing Perl, but I have many years of experience writing system administration scripts in Perl, and I'd pick it for that task over Python any day.
I can understand why someone who prefers Python would go that route, but it is definitely not more capable than Perl in that domain.
Perl is the undisputed god of text processing and manipulation. Most of the "IT related tasks" are essentially "Get the output, understand what it means, and act upon it", which makes Perl a perfect fit for the situation.
You can convert an IP to its hex representation and change a symlink in one line. That's a superpower.
Sounds more like something that is difficult to read/understand. Code readability, being able to understand code 6 months from now is much more important to me.
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.
I don't know... I used to use perl as my "default scripting language" over a decade ago. Once I was required to learn python for a new job I had no need to look back.
Personally, I find it very readable. My only criticism is that its syntax looks "weird" nowadays. I mean, a newborn language would never go with `my` as local variables declaration prefix, or `->` for object method call, or `sub` for function declaration. I think Perl would benefit of a transpiling approach, like what Elixir is to Erlang.
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".
The mistake was to think Perl was suitable for those types of applications in the first place. Perl was designed for writing small scripts to glue C programs together in a more convenient way than using shell scripts and AWK. A lot of its idiosyncratic design decisions make sense in that context. But when Perl advocates starting pushing it for writing large applications with OOP (with, of course, multiple competing object systems) it was the beginning of the end. Add in the vapourware that was Perl 6 and it was game over.
> 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
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.
> I think it's the culture in which those large projects were developed.
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.
I'll never understand this Perl readability sentiment.
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.
You can write unreadable code in any language, and I also find complaints about about perl being unreadable unfair, but I have to admit that it does give you so much freedom that it's easier to end up with poorly written code than it is in some other languages. When I need to throw something quick and dirty together I love that freedom, but you do have to apply some self-discipline when you move to something more complex since it isn't imposed on you all the time.
It may happen when one directly translates into code an algorithm, a concept, or a formula from mathematics, physics, or computer science theory, where all the symbols are terse, you're supposed to have read a hefty book or stack of papers where those are introduced, and the author laments the demise of APL with all the nifty symbols it had.
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.
This is I think in large part that Larry Wall[0] is a linguist and I think this influenced both Perl and its descendant Raku[1]. Thats why it has this almost natural-ish looking syntax in alot of ways, and relies on symbolism. I also think this is why Perl is legendary for regular expressions
Ironically these features make Perl feel very far from natural language, much moreso than other programming languages, even some symbol-heavy ones like Java. It feels more like IPA pronunciation notation than anything naturally derived. Raku I can't speak for because I haven't used it beyond "hello world", but it has a huge pile of symbolic infix operators in the standard library and that makes me squirm, because it's probably my most-disliked Haskell feature and IMO a substantial design mistake.
Bit of nitpicking: This is, because `my` doesn't declare a local variable (you do this with `local`), but a lexically private variable, which is something different. Expressing that something "belongs" to a private scope by `my` isn't much weirder than, say, referring to an object in its own context as `me`, as seen in HyperTalk.
It's not a joke, it's true. Your code is nice, but the problem is, that Perl doesn't enforce any kind of readability; some other languages also don't but Perl is worst in this aspect, and that makes it unusable for anything bigger. New programmer will not understand the code or his colleague at the first glance, and at least in corporate environment, there are always new and junior programmers.
the issue is Perl made TMTOWTDI a core value. So there's a hundred ways to express something differently. Compactly, verbosely, etc. Until you're familiar with your peers code, it can be a pain. Once you understand the style adopted internally it's not so bad.
Compare that to PHP where theres generally one way to do something right.
It’s even worse because not only is there more than one way, each way gets added and then deprecated, or worse there’s some big caveat like not being compatible with references or with values. This leads to all kinds of insane syntax that won’t make sense without a very careful reading. And because everything changes meaning depending on where it is, what functions were last called, and what it is being applied to there is no way to be sure of the effect of a function or a piece of syntax without having a deep amount of context from careful reading of the code before the call site. Context sensitivity sounds great in principle but leads to a lot of unpredictability in practice.
All this means is that teams have to enforce readability. It's not good or bad, just a different shifting of responsibilities - and this is something that you still need to do for other languages, there's just more tooling (like flake8 and black for Python).
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.
This readability requirement is a bit overrated. It's best to rely on comments and documentation so that you can rewrite something if you have to.
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.
Couldn't disagree more. Comments should only ever be present to explain why a choice was made. Never what code is doing. If it needs to explain what the code does, the code needs to be rewritten.
Comments don't compile, so the only documentation of what code is doing guaranteed to be correct is the code itself.
With Perl there’s always the temptation to completely eschew any readability by using its incredibly powerful and loose syntax to create programs that are indistinguishable from line noise.
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.
Golang is quite good in this regard:
- language itself is quite simple
- default coding style was defined at the very beginning
- usually there is one standard way to do something
- the language do not have so-called "syntactic sugar"
So Brainfuck would be an acceptable choice for a language to use?
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.
Looks readable to me. Though you had the advantage of not being forced into using Perl for really complex data structures.
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.
I would argue if you "have to parse a very deeply nested" data format you should have subroutines or objects with methods for that specific task, and not rely on generic language container types.
What you're running into is insufficient modeling of the problem, not a deficiency unique to any language.
But a Perl object underneath is a hash, or list, or whatever. That abstraction doesn't save you from Perl's "sigil per type" and other oddities. It maybe encapsulates it, but...
I wrote a _lot_ of Perl 4. Really a lot, mostly for Radiator (a RADIUS server), and then upgraded it to Perl 5, and then moved to Python.
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.
Many, perhaps most ISPs in the 90s were built out of Perl, including my own. Like any language, there is a world of difference between a codebase written by an experienced, thoughtful, veteran, and something just cranked out by a 1st year student (as we all were once, myself included!). I frequently see Perl described as “hard to read” yet have seen many beautifully written codebases that are a delight to maintain.
As someone who maintained Radiator (a RADIUS server) at a few places, I agree. That piece of software alone was enough justification for Perl to be used in critical scenarios, and as far as I know some of those instances are still running, decades after I left (obviously not the same machines or versions).
Python and Perl areas of strength do not overlap, IMHO.
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`.
Python is excellent for "medium scale". A little too verbose for very simple ad-hoc scripts, a little too unstructured for very large applications with a large number of developers (but this has improved substantially in recent years).
This. Medium scale is what Python excels at - the sweet spot is IMHO between 3K-10K lines. Above that and you start running into sore points (performance, no parallelism, too much dynamic typing, ...) and you maybe start looking into writing some parts of your code in C/C++/Rust (or yet another custom runtime, like Dropbox or Google attempted to do once). Under that it's still very effective but probably not the sharpest tool around - IMHO Python excels at being a jack of all trades, but there are often more specialised languages that tend to be more effective in a specific niche (like, for instance, Perl when writing scripts that glue tools together).
With Python the scope of “simple tasks” moves from a bunch of shell scripts to eg parsing a webpage, getting images from it and running face detection on them. And if it happens so that your ad hoc script has to become a full-fledged program, you can refactor it, add API endpoints, monitoring and so on.
If by "technical debt" you mean something that requires updates and maintenance, then yes, because it's a living language. Perl has the advantage of being frozen in time, but it has the disadvantages of not being a living language: younger programmers not being prepared or willing to touch it, likely less library support for newer technologies. That constitutes technical debt as well, albeit of a different kind.
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.
If you want to go beyond those 10 pages, the (also very short!) "official" book by Aho, Weinberger, and Kernighan ("The AWK Programming Language") is an absolute gem of technical writing. It is a joy to read.
While the book is awesome. And I guess there is a story some where that a programmer working with Aho even build CAD software with awk. Its often not an effort for the faint hearted, even to maintain. Without unit tests, exceptions, and myriad other features, you are doing too much of 'building universe to make apple pie' sort of work to get anywhere.
Same with shell. You begin to give on it for non trivial work.
I gave up on awk and always do perl one-liners. For basic stuff, they are about the same (perl _does_ have autosplit etc..) but every once in a while there is a slightly more complex task, like detect first unique field, work with json, shell quote, etc.. This is still trivial in perl, but turns out super ugly (or impossible) in awk.
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.
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.
People keep beating the 2.x dead horse. Moving to 3.x was a non-issue in 90% of the stuff I've seen "upgraded" written as far back as 2010 (at a telco, with a lot of legacy). I stopped writing 2.x code in 2013, and 3.5 (the version that became the new baseline there since I left, which was updated to 3.5.10 in 2020) dates from 2015.
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.
> 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.
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.
> I deliberately chose 3.3 because that's the earliest 3.x version I'm aware of that started to see serious adoption.
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.
I personally have run into breaking changes in Python's regex module, which is pretty fundamental to such uses as mentioned above.
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.
I stopped using Perl 15 years ago, except for this exact use case. I still type “perl -pi -e” to wrangle source code or data files, at least monthly. The regex syntax is more consistent too.
> Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms.
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.
It doesn't mean anything in Perl. The comment is a demonstration of why some criticisms of Perl are unjustified, as people love to make up little things like that, then other people such as yourself end up with the impression that sort of nonsense is ordinary Perl.
(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.
> I used to think heavy criticism of Perl's use of punctuation characters were valid, until I looked at PHP, Ruby and Rust
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?
Python insists on the difference between 2 spaces, 3 spaces, 1 tab, and 2 tabs; which is just wild. How is it that Perl works fine without all that noise, for chrissake? Or Javascript?
Does Python work fine without all that? If it did, validation and type-checking tools like mypy and pydantic (or the recently introduced Typing in the standard library) wouldn't exist. Or having to write lines and lines of checking code because someone else (also me) forgot to annotate the expected types of some parameters.
I don’t think Python “just works” in this regard. It blows up in your face if you mistake a scalar for a dictionary. In Perl, the sigils are there to help you the programmer distinguish your $scalars from your @arrays and your %hashes. It still blows up in your face if you get it wrong but there’s a visual indicator to help you get it right.
I've seen those three character prefixes in real code. It's not unjustified criticism at all. Luckily I've not needed to work with perl for ~15 years, but it was something like \$@, maybe.
> 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.
The first time I loaded data onto an Elastic index, I used Perl. Then I used logstash so that I could do it the proper way. It turned out to be about twice as much text.
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.
I don't understand the rating in the table. After the Python 2/3 migration I wouldn't expect compatibility problems for the forseable future. And why should Python not work as well for shell scripts as Perl? Why should Java not work for shell scripts? You can even run Java files without an explicit compilation step these days. Why should Python, JavaScript, Java, and C# not be extensible?
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/
because anything written in 2 wont run as is on 3, anything using async will need 3.4(?) anything using type hints of f strings needs 3.7( or 8, I get hazy)
I already mentioned the Python 2/3 problem, but the other things you listed sound like usual new features, which won't work on older versions, obviously. However, I'd expect Python 3.4 code to run perfectly fine on a Python 3.8 interpreter.
> because anything written in 2 wont run as is on 3
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?
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.
"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.
> "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#.
* DuckDuckGo
* cPanel
* booking.com
* craigslist
These projects use millions of lines of Perl code and trust me, there are lots of other companies, banking infrastructures included (!), that use Perl as their backend or in-house services.
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.
I have a couple of decades of Perl, and used it for everything from automating warehouses to building the original BBC iPlayer to big data ETL. I’ve also spent the last five weeks writing Python exclusively for a job, and the two years before _that_ doing TypeScript on the backend.
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
> CPAN is better than its equivalents. The consistent documentation style and location, focus on tests, and so on is excellent. Miss CPAN.
> 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.
I discovered Perl basically by accident. For scripting/systems administration its simply unmatched. It's been clearly designed for speed and utility which is what I always wanted and I'm a bit disappointed nobody ever mentioned it to me. I'm 20-something btw, so it's not just ravings of an old man.
I think the catastrophe happened when people mistook this it for a backend development language... and it somehow worked. Not well, but it did, which is it's own quality.
I slowly started learning it half a year ago and it's been really useful for scripts. It's indeed more robust than POSIX shell which tends to have baked in assumptions about the system which may not transfer well onto different platforms. No regrets - the grey beards were right!
I suppose I’m a grey beard (in industry is 96ish) and I mean, it’s fine as a backend language in so far as dynamically (or even loosely) typed languages go. It’s just as easy (or hard) to write modular well tested code as in any number of other languages in wide use for backend services, in my XP.
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.
Can you recommend any free resources that amount to an "effective minimal core" or crash course for Perl? I'M a Python dev, but I use sed/cat a great deal, and maybe Perl is a better solution. (Take me to the Dark Side.)
edit: you said "free", but this isn't technically free
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.
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.
Thank you everyone in this thread for suggestions.
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.
Lots of bad code was written in Perl by people who didn't know how to program. This is a feature, though. Tons of valuable software was created with the assistance of a language that attempts to get things done more than it tries to hold people to the implementor's dogma.
Not at all, I'm an average programmer at best. But writing well structured code is about being conscientious of your team mates, it's about not being a show off, it's about not being arrogant even if you are the smartest person in the room, it's about reading some books on clean code, knowing what KISS is.
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.
It's not so difficult to do, it's difficult to get people to do it.
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.
I think this sort of argument misses the point of my comment. I really don't want to write serious software with Perl, I want something more powerfull than AWK, but not as cumbersome as a more "structured" language. I literally use AWK daily for random stuff I'm most likely gonna throw away or put it in a script which I'm gonna throw away happily the moment it breaks. Sometimes, AWK is not enough, and for these usecases, in my short expirience, Perl is unmached.
Actually a lot of Ruby's features were like: Perl, but with REPL and objects and easy metaprogramming.
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..
Ruby has taken over Perl as my preferred language for small fun projects that I don't intend to update very often. The syntax is more flexible, the libraries are more convenient, and the language just feels more fun overall. It used to be that Perl came pre-installed while Ruby is not, but these days Ruby is fairly available across the systems that I use.
Much of the fun was due to influence from Yusuke Endoh:
Indeed, Ruby is often called "the bad parts of Perl." Ruby made metaprogramming and monkeypatching first class, and somehow made the language even harder to statically analyze.
But there is sorbet, claiming to be very fast and effective.
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 ;)]
There are Perl scripts I wrote in 2000 that are still in commercial use today. This is what annoys me about languages that don't care about backwards compatibility (cough cough)
I have the same with C code. Yet I'm not going to recommend anyone starts a new project in C, outside of very specific use cases like some embedded thing. And even then I'd say a C++ subset.
>It is installed by default everywhere. I don’t need administrative privileges to deploy Perl code almost anywhere. That is extremely empowering.
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.
> >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 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 sweet spot for Perl is any problem combining text processing with Unix system calls. It's a system administrator's idea of what a programming language should be. I feel the reason why Perl got a reputation as a "write only" language is because it's easy to write a simple Perl script, so people with no programming background wrote a lot of ugly code. It's simple to write clean, maintainable code in Perl with a little discipline.
I have more than a little background in programming, and I love Perl. But I definitely consider it 90% write-only. The remaining 10% are mostly libraries.
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.
274 comments
[ 0.29 ms ] story [ 283 ms ] thread10 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.
https://raku.org
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.
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.
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.
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.
I think, in this case, perl being hard to understand is the joke itself.
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.
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.
[0]: https://en.wikipedia.org/wiki/Larry_Wall
[1]: https://www.raku.org/
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.
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.
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
http://man.openbsd.org/awk
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:
You can otherwise use `open` to spawn shells as if they were files, piping either on their left or right: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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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..
Much of the fun was due to influence from Yusuke Endoh:
https://github.com/mame
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 ;)]
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.
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.