Not Your Grandfather’s Perl(stackoverflow.blog) |
Not Your Grandfather’s Perl(stackoverflow.blog) |
Also a modern OO seems nice, though not sure what is in it. Would also like to see a default async library (maybe POE, but I never used it and find the name a bit strange for a default...but then I like Tokio...) Not my area at all, but an opinionated way of async seems nice.
``As shipped, the only command-line history supplied is a simplistic one that checks for leading exclamation points. However, if you install the Term::ReadKey and Term::ReadLine modules from CPAN (such as Term::ReadLine::Gnu, Term::ReadLine::Perl, ...) you will have full editing capabilities much like those GNU readline(3) provides. Look for these in the modules/by-module/Term directory on CPAN. These do not support normal vi command-line editing, however.''
https://metacpan.org/pod/Devel::REPL https://metacpan.org/pod/Reply
Not to mention the Jupyter kernel: https://metacpan.org/dist/Devel-IPerl
https://github.com/viviparous/preplish
Perl's concise syntax makes working in a REPL a pleasure. Python has a REPL but the design of the language makes it expand both in length (for loops) and in width (tabs).
I am a recent convert to working in a REPL first to test programming ideas.
rlwrap perl -dee
my ($grandchildren) = @_Almost all Perl code will
Really?
What were the repercussions of this terrible deed?
Python's origin was as a teaching language (originally ABC I think?), and thus the simplicity of the syntax. It was kinda cool that Python was around for so long before it took off... I had the O'Reilly Python book way back in the 90s.
Perl's influences were awk, sed, bash, C, Fortran, and Lisp.
It was the best job ever. The systems monitoring tool used ancient Perl4 (this was circa 2001 when Perl4 was like a decade old) and Prolog to handle event management.
> $time->month # Jan - Dec
> $time->wday # Sun = 1, Sat = 6
> $time->day # Sun - Sat
Seriously?
For everything else, there's anything.
I wouldn’t call this as “Perl moving forward”, I’d call this “Perl is still about 20 years behind everyone else”.
Wait until they find out that other languages print statements let you customise the line ending!
`say` removes the need for anyone to write their own "I'm tired of the manual newline ritual" function and provides a standard for where the newline is added. That's a marginal convenience, but given the frequency with which people either do write their own or newline inconsistency gets encountered (or both), it's a reasonable one.
And it's in pieces like this one not because it's a huge thing to crow about, but to illustrate the opt-in nature of incremental changes or sets of changes to perl.
`say` is also about 15 years old, like Time::Piece. The author is not announcing features that are new to the whole world, just new to a certain audience, possibly including the author.
This is also true of the filehandle scoping feature (which is 22 years old). If you find the old bare filehandle scope behavior only notable enough to hurl a drive-by "bonkers" at it then I suppose that's one way of advertising that you haven't spent much time thinking about unix shell utilities and associated features/issues.
Function signatures are slightly younger than typescript, or at least, the most familiar syntax for them; both the old and more recent means are essentially naming a list of arguments.
In general: perl is an opportunity to think about programming languages differently. There's a lot of contexts in which I never use it anymore, but it's rare to find people with substantial insights who casually disparage it.
Perl 5: I'm not dead!
TIOBE: 'Ere! 'E says 'e's not dead!
Internet: Yes he is.
Perl 5: I'm not!
TIOBE: 'E isn't?
Internet: Well... he will be soon-- he's very ill...
Perl 5: I'm getting better!
Internet: No you're not, you'll be stone dead in a moment.
TIOBE: I can't take 'im off like that! It's against regulations!
Perl 5: I don't want to go off the chart....
Internet: Oh, don't be such a baby.
TIOBE: I can't take 'im off....
Perl 5: I feel fine!
Internet: Well, do us a favor...
TIOBE: I can't!
Internet: Can you hang around a couple of minutes? He won't be long...
TIOBE: No, gotta get to Reddit, they lost nine today.
Internet: Well, when's your next round?
TIOBE: Next year.
Perl 5: I think I'll go for a walk....
Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?
Perl 5: I feel happy! I feel happy!
=====================
You can write Perl in Latin: https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/L...
or Klingon: https://metacpan.org/pod/Lingua::tlhInganHol::yIghun
or whitespace: https://metacpan.org/pod/Acme::Bleach
The number two feature they listed was released more than 22 years ago.
Perl is fine for certain tasks, I have no problem with people who choose to use it, but at a certain point I'd argue it's better to learn a new language than try to use Perl for a new type of task.
I didn’t know about the function signatures. It’s nice, I guess.
But I don’t want to write perl again anyway.
The version of Perl on your favorite Linux distro might be. I think that's the point the article was trying to make...that distros ship VERY old versions of Perl.
What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
Solo project with ~23K LOC of Perl and counting here. Bless you, Larry Wall and Perl maintainers. Keep it up!
I see what you did there.
Edit: for those downvoting me because they don't understand my comment, it refers to the fact that bless is function of the standard library to associate an object with a class.
If you're downvoting me because you think it's a stupid and off topic comment, that is perfectly valid and acceptable to me.
It was a simple blessing, and perhaps a reference to this interview with Larry.
To me, the language creator's faith is one more reason to use it.
Anyway I manage a 250kline code base written over 20 years which is in surprisingly good shape consider it's age and how many people have touched it. Last time we upgraded the perl for the first time in a decade - going through the addition of many features and major internal changes (e.g. unicode, optimisation) the total number of lines of code we needed to change was at most 50. And very little having to fiddle with underlying cpan libraries.
Back to the point. Throwaway script - perfect candidate. Code capable of running the money pump for a billion dollar company. Also just as fine as any other similarly capable environment, better than some, trickier to manage the team than others.
I don't write much Perl these days and haven't for some time, but it's still what I might reach for if I were tasked with writing something suitable for a scripting language that had to run with ~0 operational or upgrade/maintenance budget for a decade or more in environments I wouldn't necessarily be able to control or influence, or else [bad thing will happen].
Imagine trying to upgrade this to some new syntax...
http://modernperlbooks.com/ is where you can read it for free.
Plenty of examples and exercises.
I think Raku deserves way more attention. Its implementation is suboptimal in many ways and it's improving slowly due to very small core team. With more exposure, more people would come, and hopefully some of them would consider contributing, accelerating the pace of development.
I'll let myself out now.
No, 5.36 stabilised them.
https://perldoc.perl.org/perldelta#Core-Enhancements
> The 5.36 bundle enables the signatures feature. Introduced in Perl version 5.20.0, and modified several times since, the subroutine signatures feature is now no longer considered experimental. It is now considered a stable language feature and no longer prints a warning.
Is that even something they're doing on purpose? Didn't they completely botch their attempt at a new major version?
When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain.
With Perl it's inertia. So even if the language designers and package maintainers wanted to make breaking changes, they couldn't, because people would just stop updating. All that's left to do is to drag out the process of this ecosystem rotting away.
All I know is that I can depend on my Perl scripts running a year from now, and I cannot do that with Python.
It feels alive and well to me in that sense, while the stability and dependability of Python does seem to rot pretty quickly.
Paint me unconvinced. Python2 is still a thing, 14 years later.
Picked up the O'Reilly Javascript book from around 2000. Had no idea what javascript was, just wanted to learn how to program and trying to pick the most popular language.
$40 later, I got home and started reading! Very confusing, the first half of the book covered the language runtime (I think?) and the second half covered the browser sandbox, and it took me 200 pages to realize that I can't easily read or write to files on my machine with this language. Not what I was hoping for!
Back to Barnes and Noble, another $40 and I came home with the O'Reilly camel book, Beginning Perl I think? Cover to cover read, probably the last time I did that with a programming manual.
Decades have passed, I'm in the same camp as those that prefer Ruby now, but man what a breath of fresh air Perl was back in 2000.
Randall Schwarz used to run a podcast that was a total goldmine. Fond memories of listening to that on the train on the way to work.
I think $_ belongs to a different era, before levelling everything to the lowest common denominator became seen as a good thing. I found the limitations of its rivals less than compelling, and besides JavaScript is arguably more complex than Perl these days.
But back to Perl. I always thought one of the best things about Perl was CPAN. I could nearly always find a module that would accomplish a specific task I needed and then I was just left to write the glue to implement that function (or functions) for my particular needs. I'm surprised CPAN is not mentioned. I wonder if it is still active. I also wonder about security of CPAN in todays environment. I find stuff like pypi and npm to be pretty scary.
I haven't started anything in Perl in quite some time. All the cool kids are using Python so I've been sharpening my skills with that. (But it's all hobby projects these days.)
I can't wait for the day that programming languages as a concept are obsolete. It feels exactly like hand-tool woodworking. I would love to stop building tables and chairs over and over, instead just buy them from Code IKEA.
Perl is still my go-to language when I need to write something quickly.
I have so many purpose driven utilities that I have written in Perl, that it saves me several man-hours of work every month.
I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.
It's a shame too because as you say the Win32 API stuff works great up until the antivirus kicks you in the nads.
I love Win32 because it's the closest we have to a universal GUI format for software.
I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
But man, just being able to write
use v5.10
In vast majority of cases the code changes were just "well, the new version of lib gives some warnings about deprecation, might as well clean it up a bit". The minority of cases has been Mojolicious breaking stuff again.
--
Some of the improvements were needed because in places Perl’s Unix/C heritage shows through a little more than we’d like it to in the 21st century. One good example of this is bareword filehandles. You’re probably used Perl code to open a file looking like this:
open FH, 'filename.dat' or die;
Which then inspired the bad idea of expanding on that?
eg, open FH, "<filename"
vs FILE *fh = fopen("filename","r")
For scripting anything longer than a command line, I'll take Python.
I slowly switched from Perl to Ruby for writing my own text processing scripts. A loop with <> is very convenient but I was using Ruby for work (still do among other languages) and Perl for nothing. I was forgetting how to do stuff in Perl.
I wonder if this is how you end up being a Perl user in 2022.
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
You're only noticing half of the picture.
If you want to write code that'll still run in 20 years, do the same.
use Modern::Perl;
use common::sense
Which is also quite nice, giving slightly more opinionated defaults.
I had an idea years back to build crosswords on the surface of a truncated icosahedron (https://i.imgur.com/qlLl434.jpg) but I had no idea how to find sets of 5-letter words that would mesh like that. A very clever programmer friend of mine whipped something up in Perl over a weekend using hashes. Basically it pre-emptively runs through the dictionary and hashes all wildcard forms of a word back to the original word (l...s->leaks, etc), then at each stage of filling out the puzzle it just grabs the list of words that hash to the current pattern. Say you're looking for something that fits s..p. it would return [stops, swept, soupy] etc, then tries each recursively. If the list is empty, there is no solution at that level so it backs up and tries the next word at the previous level.
I learned enough Perl to be able to make the code able to accept different polyhedra. The program takes quite a while to run on larger models, like say the rhombicosidodecahedron, so I've been looking for ways to speed it up. My background is with assembly and embedded C so I'm sure my implementation of these hash lookups would be slower than Perl's. Are there any other, maybe compiled, languages that have fast hash lookups like this?
Nowadays I have my own startup and my code is a mixture of JavaScript, TypeScript, and Rust.
Rust is good for anything sufficiently complex that you want to run quickly, have a small footprint, and want to be sure it works, while allowing for easy refactoring due to the strong type safety.
JavaScript is good for anything you want to write quickly and the code quality doesn't matter as much (e.g. test scripts). It's also much easier to write than Perl syntax-wise and has great async support (unlike Perl). Also it has a much larger ecosystem of libraries and easy to use in IDEs like VSCode. Obviously JS/TS can also be used in both the frontend and backend which is another big advantage.
TypeScript is sort of in between - if the JS codebase gets too large it should be written in TS instead. This makes the code less "write-only".
Perl and PHP were pretty good solutions as scripting languages until JS added good async/await support, map/filter/reduce, and destructuring syntax in my opinion. JS probably requires the least lines of code to get a program working.
CGI scripts are basically FaaS on your own machines.
And I read the article.
The title makes no sense. The article show anything meaningful as to why Perl has improved and is "not your Grandfather's Perl". Most of what the article talks about has been around for over a decade. If anything, it shows that Perl really still has under it the same old decrepit beast it always been hiding away.
I'm a younger developer, so I wasn't around when Perl was super popular. I listened to the Corecursive episode about CPAN [0] and was really impressed. It's a good listen even if you're not that interested in Perl anymore.
Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll probably find modules in a state of disrepair, abandoned in 2010.
I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where that was awkward, it was easy enough to write in C and use the PAHO libraries directly.
CPAN is indeed alive and kicking; https://metacpan.org/
Compare:
# Perl
use feature 'say'
# Python
from __future__ import print_function
IOW py2 code doesn't run on py3, barking at you in obscure ways if you try, and py3 code doesn't run on py2, barking at you in obscure ways if you try. (or worse, partially runs and either explodes in mid flight or silently corrupts data).
Whereas Perl code written targeting vX runs on Perl vY as long as Y >= X, and if Y < X then Perl tells you "unsupported feature foo" or "your perl is too old, update to at least X".
$ perl5.18 sig.pl
Feature "signatures" is not supported by Perl 5.18.4 at sig.pl line 1.
BEGIN failed--compilation aborted at sig.pl line 1.
And not just that, Perl alters its parser behaviour live (and scoped to the module!) so remove `'signatures'` from `use` and you get:
$ perl5.30 sig.pl
Malformed prototype for main::my_subroutine: $foo, $bar, $baz = 'fury' at sig.pl line 7.
To invoke strict mode for an entire script, put the exact statement `"use strict";` (or `'use strict';`) before any other statements.
(They had to make it a string in void context instead of a comment because comments are removed by JS obfuscators, but it's essentially a magic comment/preprocessor directive)
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
At the $dayjob, writing some python assuming late model 3.10.x, and discovering that the API has changed when I have to make sure it works on 3.6.x and 3.7.x.
Nevermind important libraries like pandas changing the API so some functions you 've used for years just disappear.
I've got 30+ year old perl 5, that just works. And is readable. I wish 2 year old python could just work.
Perl (Strawberry Perl for Windows) is much faster than native Powershell (or CMD) scripts. A few Perl one-liners and I have 2 GB processed in a couple of minutes.
Big fan of Perl here.
This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
> I'm working in Windows (employer's choice)
Work prefers MacOS, Windows is my personal choice :)
Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Using Windows (and Perl, and other weird things I like) may not be fashionable, but it's hard to beat.
What I miss it's a "strings(1)" replacement for Perl.
Other languages could do the same, but often they have a few more layers before they start running that C code.
I'd be curious to know if the perl grammar also somehow lends itself to being fairly optimizable for it's interpreter.
IDK. I didn't waste time checking why.
My guess is that due to the much smaller code size, it reaches a sweetpoint where it fits nicely in the L1 or L2 cache.
But it's just a hunch, I couldn't prove it.
while(<STDIN>) {
print $_;
}
Compared to every other scripted languages I've tried, it's always faster - so much that it often rivals compiled code (even with extra optimizations as explained before)
> Is it just all-around faster
Yes - also faster to deploy, and harder to break in deployment due to dependencies rarely evolving. No need to pip install whatever.
Consequently, tracking modules' versions (say in python) and their break in compatibility is a thing of the past. Some may say it's because it's dead. I guess I'm a necrophiliac then, because it makes my life so much easier that I'm loving it :)
2. Are you hiring?
Using the stock install as much as possible.
Since a perl interpreter is available about everywhere, this makes the scripts cross platform very easily too.
> 2. Are you hiring?
Maybe? You have no email in your profile. Can you please send your CV to my nickname at outlook dot com?
I agree. We might deny it, because we are geeks, not fashionistas, but there's such a thing as "cool for geeks" like running Rust code on MacOS with some PostgreSQL sprinkled on, and such a thing as "uncool" like running Perl code over Windows and exchanging CSV files.
Personally, IDGAF: I care about what works the best, not what's cool. I care about performance. I care about the code not breaking due to weird compatibility issues. I care about keeping the stack as simple as possible, because what's simple often works better.
If, god forbid, I need something more complicated than CSV, I reach for sqlite --- which, unfortunately, is starting to become the "cool" option, and therefore might get turned into the proverbial hammer that makes all your problems look like nails!
If your system isn't performant, it's shit. Performant is relative to what you're trying to do and how picky your users are, but at some point you're going to be optimizing for milliseconds without question.
Regular expressions are way better in Perl. I increasingly find myself going back to Perl for RE heavy projects because it's so cumbersome in Python by comparison.
I'm still undecided on if Perl needing semicolons everywhere is only 'as bad' or 'worse' than Python forcing you to worry about the exact number of tabs/spaces indenting lines, but I'm leaning toward python being easier in that respect.
Still, when I have to get something done quickly, especially if it's an immediate need I don't see having to worry about later, Perl is what I turn to. Everything in Python becomes a "Project".
That's a matter of opinion. C style languages are a lot easier for me than whitespace significant languages; my editor will go to the matching bracket with ^G, but I can't do that with whitespace to get to the end of a block. The type sigils are a bit tricky to figure out, but if you spend the time to understand it, it makes sense (but that's also a mater of opinion, too).
I use Python and Perl. Some people who like Python want everything to be Python and "hate" anything that isn't Python. It approaches zealotry in some cases.
Perl syntax is expressive and is similar to C, C++, Java, and yes Bash. These are successful languages too despite not being pythonic.
Actually using the language itself is far less painful in Perl than it is in Python.
Every new Dev says the previous code is shite. Odd that the plumber and electrician do it too.
It's as if nobody can produce good work except for $ME at $NOW
It's the fault of the non-programmers who read "Learn Perl in 2 hours and become a millionaire" books, had a massive s*t on a keyboard and started a business with it
For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact that it feels like a nice and natural step up from awk or bash when I want to process text files or work with the filesystem, and also the fact that I just find python so boring.
Oh, also Perl is a very powerful command line tool that can be easily piped into on linux. I don't think python or ruby are as powerful in that regard but I could be wrong.
It's wrong when stated as a blanket statement like that. It depends on the particulars of the case.
I've worked in a company that's taken this dictum as gospel and took it to its absurd extreme where refactoring of any kind was forbidden.
I would explain some dark corner of the codebase and everybody would basically agree that it was in bad shape. I would then explain what I wanted to do about it and people would say "Is that a refactor you're suggesting?" in a tone of voice that would be more appropriate when saying "Is it killing babies that you're suggesting?"
As coincidence would have it, that was a Perl shop. So I speak from experience. And that experience has left me somewhat scarred.
Imagine working on a codebase where any mistake you ever make you're just stuck with. And it's not just your mistakes, but other people's as well. And the mistakes just pile up and pile up and start interacting with each other in nasty ways and there's just no way out. I love being a programmer, but there is little in the world that I hate more than having to be a programmer under such circumstances.
What's more is that the financial benefit of not refactoring is a benefit that usually accrues to those who are in power in a company and who don't have to touch the codebase, whereas the psychological cost of not refactoring accrues to those who have no power who are forced by the others to wallow in the muck. -- That's the thing that Spolsky consistently just doesn't get. He consistently represents the one-sided view of someone "in power".
As a programmer under such circumstances, it really makes no sense to throw away your psychological wellbeing so that your company's owners can make more money, just like it doesn't make sense for a miner to give himself lung cancer so that the owners of the mine can make more money.
Conversely: If you're the owner of a software company (or mine, or whatever) you should partially think of refactoring as an employee benefit that will pay for itself through increased productivity. It's a point that's very convincingly made by Tom DeMarco in his book "Peopleware" [1]. Asking your employees to dial down the quality of their output so you can realize cost savings almost never makes sense when you take into account the human side of the economic equation. You'll demotivate them and the losses in productivity will outweigh the cost savings.
[1] https://www.audible.com/pd/Peopleware-Audiobook/B09WDR3P3V?a...
Supports, for example:
$fh = IO::File->new("filename", "r");
Or, as with C, things like O_WRONLY|O_APPEND in place of "r".
I suspect writing it in Ruby with async would also prove problematic, but there are the ruby-mqtt and async-io gems and one would use the MQTT::Packet for formatting messages and Async::IO for the networking code. Still a lot less painful than what I did with POE and Net::MQTT::Message.
MQTT.js is async already, you just import and use it in the browser, Node.js, probably Deno as well. Easy. It took literally five minutes to get the client enpoint working in the browser over WebSockets. One could even do it from the browser console.
While the core devs of perl concentrate on optimisation of the language and slowly add new features, the strong backwards compatibility approach constrains what can be done with it. The backwards compatibility is so important that development builds of the core will run against the entirety of CPAN's distributions' test suites to see if changes break anything there. This is know as "BBC" - blead breaks CPAN. If a change breaks something on CPAN then it needs to be reevaluated. I don't know if any other languages have an equivalent - running not just the internal test suite but also an enormous external one?
The nature of Perl means external modules can bend the language in some pretty interesting ways and build atop a strong foundation. The new features added to the language are slowly being used by more module authors to create features and libraries that are what you want to focus on.
See https://metacpan.org/pod/Task::Kensho for some of these.
The contrast to Learning Python is noteworthy. The latter book is useful, too, but it's about ten times bigger and much less focused on introducing a language.
sub myFunction {
my ($self, $arg1, $arg2) = @_;
...
}
sub myFunction {
my $self = shift; # implicitly get the first value from @_
my $arg1 = shift;
my $arg2 = shift;
...
}
Function signatures turn this into something that'll look much more familiar to users of other languages:
sub myFunction ($self, $arg1, $arg2) {
...
}
This part probably won't shock anyone given the prevalence of JS today. Which is kinda sad, given that it's 35 years since Perl was first a thing.
* Would miss too many amazingly useful utilities like arsclip.
* Easier to patch into my home network, which is NTFS-based.
* Employer is now wedded to Microsoft and Azure, so having Powershell and native access to NTFS AD on my native desktop is proving more useful.
* I actually like the Windows interface, even with the Control Panel and other system utilities caught in a weird split between Windows XP and WIndows 10 UIs.
* Some things, like certificate management and hosting a personal database, I do in Ubuntu or Debian as a VirtualBox guest under Windows.
* Wife uses Windows on her laptop. She doesn't know it, but it's actually running as a VM on Debian, very stable, and can easily take her Windows to a new machine.
* [I keep coming back to add items to this list] Remote Desktop Services have improved vastly, and I can manage remote servers or 12 year old client machines at a remote site with equal ease. (XP/7-era machines got a second life when I converted Windows OS disk to SSD). Also find screen sharing via 3rd party VNC (TightVNC) useful.
* The keystrokes have become second-nature. Try as I might, I can never get fully comfortable on a Mac OS desktop. Now get off my lawn.
Same, that's one of the biggest reasons - but I also agree with the rest of your list: what I like the most in Windows is the UI! I run most of my programs fullscreen, with shortcuts. I rarely use the mouse, and Windows plays along, while I have to fight other systems.
Even when run baremetal, Windows has improved so much over the board that once you add RDP/VNC, it's a no brainer.
Huh. Windows is usually anywhere between bad to horrible at IO compared to alternatives. 2GB processing (usually mixtures of regex, summarizing data, summing fields extracted) shouldn't take more than a few seconds. Even on a slow disk, say 100MB/s, we are talking 20s. On faster SSDs, and NVMe, its very snappy.
If you are waiting minutes ...
> Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Huh. I'm happy that $dayjob gave me the option of getting off my horrible Dell workstation laptop (8 core, 64 GB ram, nvidia graphics) and onto a mac pro m1. While the keyboard diff is annoying, karabiner elements fixes most of that. I still ask for a linux laptop at ever opportunity though, as this is what I'm most functional with. Easily the best/fastest experience I've had for dev/admin, and the most stable. Mac is a close second.
Those learn to program and make fast money books were a product of the 1990s, and they appealed to people who cared more about making money than about producing any kind of product.
For example, I once had to fix some code that was supposed to delete files that were sitting in a directory for more than a week.
Rather than do something sane and simple, like look for files where the mtime was less than a cutoff and delete them, it looked for files where the absolute difference between the age and 7 days ago was 0. So it had the side effect of deleting things that were 7 days old, or were less than a day old. It also missed things that happened to be older than 7 days old.
(And nevermind that it was written because people couldn't bother to figure out why files were stuck in the directory.)
The company's codebase was filled with nonsense like that.
The person who wrote that would not have written anything better in Python or anything else.
But from the outside it worked well enough and they made a lot of money.
But Python, Ruby etc all compile to bytecode, and have always done so as far as I can remember.
I do look forward to the new class system coming to Perl based on Corrina, but I also can't comment on how performant it's going to be, either. My guess is that going ahead on this large project was based on answers to questions like, "is it going to be more useful than Moose?" "More performant?" Because if not, why not just use Moose?
(Higher Order Perl and such not withstanding.)
You can write bad code in any language. Bad variable names(sometimes single alphabet names), functions running pages long, duplicate code, algorithmically inefficient code, no error handling, master try/catch statements, OO abuse, functions with unpredictable side effects etc etc.
Early internet saw a flood of newbie programmers, and therefore a flood of badly written code too.
For that matter you also see badly written C/C++ code from those days. How do you think C++ got its reputation for being too bloated beyond practical use?
Here's the main module: https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...
#!/usr/bin/perl
use strict;
use warnings;
use Encode qw( decode FB_QUIET );
binmode STDIN, ':bytes';
binmode STDOUT, ':encoding(UTF-8)';
my $out;
while ( <> ) {
$out = '';
while ( length ) {
$out .= decode( "utf-8", $_, FB_QUIET );
$out .= decode( "iso-8859-1", substr( $_, 0, 1 ), FB_QUIET ) if length;
}
print $out;
}The problem is that Perl internally encodes strings as sequences of numbers. Not even sequences of bytes, but sequences of numbers that could either be codepoints or bytes resulting from the encoding of such a sequence of codepoints. ...as a developer you are perfectly free to make this assumption any way you please at any given point in your codebase. It's not even clear that any one of those two is particularly "preferred" at large or a best practice or anything like that.
To make things worse, there is no way to know which is which, i.e. a string itself is happily ignorant about the assumptions that people will/should make about it. And Perl will happily concatenate strings making different kinds of assumptions, or double- or triple-encode them as you please, or decode something that hasn't been encoded in the first place.
This leads to jumbles of numbers that aren't anything in particular. They simply work well enough for sloppy programmers to not realize when they are making mistakes, but badly enough to almost guarantee that encoding errors will crop up on users' screens regularly.
Now, given that this is how the language works, be my guest jumping into a 100k loc Perl codebase that dozens of programmers have touched over a decade, passing around and munging together strings not just within their own codebase, but also using strings stored to and retrieved from elsewhere, in some case places where no one knows anymore where they initially came from or where they will ultimately go to.
I don’t care about hard problems, and easy problems.
But it's a very different niche. Perl and Ruby scale to mid sized applications quite well, but above that fault tolerance and QoS become hard.
But of course, the study does not account for if increased development time cancel out revenue gained from lower bug count. (And this will be a difficult problem in general, due to first-to-market effects etc.)
unidiomatic js trickery
type Foo = undefined | false | Unit | Foo[] | FooObject
While types make intents formal (which is a pro), they require to specify irrelevant edge cases. Dynamic typing serves as “code is law”, and when you meet an edge case in the wild, it’s much easier to explain it than to formalize.
I also remember many cases of prototyping in other typed languages and it never felt “focused on the job” to me there either, even when (or despite?) a type system wasn’t turing-complete.
Also, my best hope for typescript was that it would allow me to create type-only “header files”, which would serve as a source of truth and a sort of auto-validated documentation. It turned out that forwards are not first class citizens in ts, and it was sunday evening already, so I gave up.
However the world has moved on to Python. So I curse every time I again have to look up how subprocess works for what I'd do in Perl with backticks.
My use case was for scripting git operations. And the list of target environments included Windows.
So no, that wouldn't have worked for me.
It supports mac, Linux and windows.
I think that's the main thing preventing one from using ruby like this. It is otherwise preferable in pretty much every way.
Perl is kind of pre-installed on virtually every Unix-like system for what are at this point historical/legacy reasons. It is unlikely any other language can ever achieve this at this point.
Sure, I could probably install Ruby on any machine I want it, but it's not just technical availability. Socially, Perl serves as a quite obvious Schelling point. I don't have to convince four other people to learn Ruby, because Perl is what everyone would gravitate to even in isolation, again because it's just... there.
(That said in recent years I've had to switch to Python for some things aimed at a younger audience. Oh well.)
[0] https://developer.apple.com/documentation/macos-release-note...
Disclosure: I'm the author.
Still, Perl might have influenced Rust via Ruby. Otherwise, do you have a reference for Perl's direct influence on Rust?
However you have no idea how many bugs got caught because the test run uncovered platform specific bugs. This is exactly what gave Perl a good name for being portable. Doubly so given that Perl always did this, starting back in the 1980s.
Thank you from being so civil. IMO displaying a badly encoded string beats crashing on a runtime error most of the time. I'd rather see "hôpital" than "Error 500", if you will. Maybe don't think your personal assumptions carry any validity out of your own choices, preferences, or uses.
I imagine the difficulty working with a huge codebase lacking refactoring and maybe even predating utf-8, but where would you be if it was written in Python 2.5 originally?
Any python programmer would tell you: Starting a new project in 2022 in Python 2.5 is professional malpractice.
But that's what the original post seems to be saying: That Perl 5 has somehow managed to fix any of what was fundamentally wrong with it. ...and that couldn't be further from the truth. And people in this thread are saying that maybe they should have another look into Perl 5 as a serious option for starting out a new codebase in 2022. ...and that's a very bad idea.
Sure: If you started out a new codebase in Perl 5 in 2022, there are coding standards you could adopt to avoid getting yourself into a pickle where string encodings are concerned. But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team. It's solving a problem that Python solves for you so much more easily and effectively. You could go with Perl 6 / Raku, but why would you? What does it have to recommend it over Python or Ruby, other than a Perl programmer's nostalgia for being a little Perl-like?
You could say the transition from Perl 5 to Perl 6 is just like the transition from Python 2 to Python 3. The difference is: Perl is simply late by at least a decade.
The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.
It's still not done for many, many projects. "python2" is still installed on 99% of systems I touch. Off the top of my head, the only machine missing it is my laptop, actually.
So your last perl codebase had the choice of not going through this painful transition process. Maybe it's what makes the best sense from a business point-of-view? "Worse is Better", remember, that's why we're running this sloppy Linux everywhere and not the almost-perfect OpenVMS or Genera.
>But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team.
"Ugly code" is in the eye of the beholder. For many a python project I'll have to add long series of elif or try/catch to check for the type of some incoming data returned from some API, where it could have been easily managed through duck typing in python 2.7 or Perl. Most programmers won't catch it until the error occurs in production, if the value returned switches types infrequently enough.
> The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.
Try C someday :)
With humans, my response to abuse is distancing myself from the source of the abuse, and with technologies it is no different.
Python is very popular, and I'm actually learning it right now, but I would not write anything important in it for another 20 years, since they just did ANOTHER breaking change in a minor version release.
They renamed "string" to "bytes" and "unicode" to "string".
(And still managed to make file and path encoding broken, and added a few bugs in the process.)
No, nothing about Python 3 is "in order". That was just your Stockholm Syndrome speaking.
The debate between weak typing and strong typing is as old as the hills. But in much of the modern era, strong typing, of which Python is an example, seems to have decidedly prevailed.
If you used Python 2 in a way where encoding errors wouldn't be an issue, and if you used the Python 2 to 3 conversion tool that they made when they released Python 3, then in most cases you didn't have to do any work beyond that. ...if however you used the tool and suddenly your code threw exceptions then, more often than not, the errors were errors you needed to fix anyway, even if converting to Python 3 wasn't something you wanted to do. And they gave you 11 years for making the transition between the release of Python 3.0 and the last release of Python 2.7.
I don't agree with that analogy about an abusive relationship. It's more like a five-star restaurant asking you to please put on a shirt if you show up there in a bathing suit. It's just a norm, in this case cultural, that comes with five-star restaurants. If you don't want to follow it, you're free to go find a beach cafe somewhere.
But in this case, the restaurant had previously told me that a bathing suit is OK, and I've been showing up in a bathing suit for years.
They don't owe it to me to accommodate me, but they have just proved themselves unreliable, and I won't be going to that restaurant again, since they ruined my plans for the night.
Either this is hyperbole, or you're quite mistaken on the particulars there.
P.S. Programming Python since Python 1.3
As I recall, "bytes" didn't exist in Python 2.5 but were brought in in later versions of Python 2.6 and Python 2.7 when Python 3 already existed to provide a more continuous upgrade path for those still on version 2. You could get in the habit of using "unicode" and "bytes" and then the switch to Python 3 would be this "just renaming" thing. ...but that was the end point of the process, not the starting point.
I'm not an unreflected Python fanboy. I don't like many of the new developments since version 3.5. But I've spent 2003-2018 with Python as my main language, and 2018-2022 being forced to use Perl 5. And that has left me with the impression that Python fixed pretty much all of what was wrong with Perl 5 in a way that the Perl-community itself never managed and doing Perl 5 instead of Python 3 in 2022 is basically all downside, no upside.
I also admire how well the switch from Python 2 to Python 3 was executed, compared to how poorly Perl is doing in the switch to Perl 6.
I predict that the Python community is going to fall apart over the next 10 years over feature creep and losing its identity, trying to be all things to all people, with people subsetting it in different ways to get to a sane subset of the language, similar to how people are doing with C++.