We were wizards – a foreword to Learning Perl (1993)

https://jwgoerlich.com/we-were-wizards-learning-perl/

by todsacerdoti • 2 years ago

195 126 2 years ago

Bashing Perl is now a meme, but I can never get over what could have been… Python 3000 and Perl 6 had the community all abuzz. CPAN was the amazing Wild West where people were sharing amazing libraries in such a simple way compared to how every other language was still using the likes of Source Forge and possibly even Fresh Meat (GitHub didn’t exist yet).

Don’t fall into the meme trap of hating on Perl. Although it’s only now used in a handful of companies run by OGs and possibly by devops, I urge you to take a look and spend a month using it - really using it. .. because it really is a beautiful language and it really makes Stream-of-Conscious programming the norm

getcrunk• 2 years ago

Stream of consciousness programming?

bane• 2 years ago

Perl has a weird way of letting you go from thought to code, and disappearing in between, unlike any other language I've ever used. You really can go from idea to functioning system as fast as you type without a lot of pre-planning. It's hard to describe, and the style has fallen out of fashion for more formal, easier to share between humans languages like Java or python, which feel like they introduce an inherent friction in that transition layer as a tradeoff for scalable teams and readability.

I miss it, but understand why it fell out of favor. It's the closest I've ever gotten to singing whalesong with a machine.

singingfish5• 2 years ago

As a medium long time perl guy who's been dragged kicking and screaming to do a bit of python recently I'm going to repeat this here:

Python and perl are actually pretty much exactly the same - analogous to the Judean People's Liberation front versus the People's Liberation front of Judea. However the languages are optimised for a slightly different purpose. Python helps you to think more like the computer does, whereas perl helps the computer to think more like you do.

gonzus• 2 years ago

I associate this with what we used to call "one-liner programming": I would write a single line of Perl code (in bash, prefixed with `perl -Mwarnings -MDebug -E'<code here>'`, convince myself the code did what we needed, and then share it around as a paste in irc / chat / whatever. It was amazing what you could achieve with the right modules, and Perl's flexibility allowed your mind to roam freely.

Incidentally, the fact that you cannot write this type of one-liner in any meaningful way with Python is one reason I do dislike that language.

kstenerud• 2 years ago

Bashing Perl is a meme precisely because of the mentality of the creators of Perl (who set the culture). This "Forward to Learning Perl" epitomizes the mentality: Imagery of wizards, alchemy, breaking all the stuffy rules that quashed creative thought, etc. He even says "bowing down at the Temple of Orthogonality" like orthogonality a bad thing!

It hearkens back to the days when motor cars were curiosities that required frequent tinkering and had no safety requirements. The sky was the limit, but your car could blow up.

Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety. This allows you to use a product with confidence. I had the misfortune of inheriting some cowboy code, and to this day I call a pox upon the writer. His lack of discipline caused YEARS of misery and maintenance costs; far outweighing any temporary benefit he provided.

Newer programmers might not have lived during the bad old days of cowboy coding, but I did. Nothing was documented. Nothing really worked because there was no edge case support. The mentality was "If it was hard to write, it should be hard to understand" and "If you're not happy with it, feel free to modify the code" (their impenetrable code). Basically, pass-the-buck for your own lack of discipline, and then blame the user.

Personally, I'm glad we've moved on towards becoming a serious engineering discipline, complete with UX being a thing.

alfiedotwtf7• 2 years ago

Cowboy Coding is not a language thing, it’s a mentality thing. I’ve seen many beautifully crafted Perl projects. “Perl Best Practice” was a thing

mdavidn• 2 years ago

I'm glad you found a corner of this industry with "serious engineering." It's still the wild west in web development. Today the creators of frameworks chase engagement metrics rather than wizardry, but the end result is the same.

hnlmorg• 2 years ago

Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety.

That’s the meme, but it’s simply not true.

I’m going to use Python as a basis of comparison because that’s the language which, from my perspective at least, seemed to replace Perl.

understandability

A lot has been said about sigils but ultimately a language is only as familiar as a developers exposure to it. Python appeared easier to understand for the newbie because it favoured words over expressions but now that Python has matured it’s become just as incomprehensible too.

predictability

I’ll be the first to admin that there are a couple of really massive footguns in Perl which are remnants of its evolution as a shell tool. But there’s other aspects to the language which are really clever. For example the way Perl does type comparison is much more predictable then Python.

On the whole, I think those languages are about equal.

reproducibility

CPAN was also light years ahead anything also available at the time. And still is in many regards. For example, Python environments is a mess. Perl is one of the most portable languages out there. Want to change the state of the runtime? Just add a line to the top of your source. Simple.

Python and JavaScript are a completely pain in the arse in comparison.

PHP is another example of a language that gets this right. Few people on here (myself included) will have much love for 2010’s PHP but it just goes to show that a lot of the languages “real programmers” praise do actually suck at a lot of the basic principles.

measurability

Not really sure what this is intended to refer to. Maybe APMs? Either way, a lot of diagnostics like that came into vogue after Perl’s decline so this isn’t really the fault of the language but more just 3rd party tool writers putting their focus elsewhere.

That all said, don’t be fooled into thinking such tooling doesn’t exist for Perl.

safety

Perl basically invented unit tests amongst the scripting languages. It also has stricter run modes to differentiate between one time scripts and important business code.

Saying Perl lacks safety demonstrates a lack of experience with the language.

——-

I’ve written production Perl, PHP, JavaScript, TypeScript, Python, C++, Go, Bash, Visual Basic and even Pascal. De-mangled other people’s spaghetti code in all of those languages too. Probably a few languages I’ve forgotten about too. Perl is one of those languages people love to hate but is, in my opinion, one of the most misunderstood.

[edit] I should have added a comment about Perl’s backwards compatibility. Few other languages even come close to the longevity of Perl 5. And that commitment extends down throughout Perl’s ecosystem. With JavaScript I’m constantly scared the next npm update will break the project.

alexey-salmin• 2 years ago

People often forget how bad things were in 2000s. A "serious engineering discipline" usually meant Java and "writing a unit test and five lines of docstring for every get/set method". I'd go for wizards and alchemy any day.

Even today many of the "serious engineers" of the time still roam the industry and show up for interviews every now and then, completely unable to write code. Some even capture younger souls into this trap, a sad picture.

llm_trw• 2 years ago

I'm glad we've moved on towards becoming a serious engineering discipline

To quote the immortal Bender:

> Oh wait, you're serious, let me laugh even harder.

WesolyKubeczek5• 2 years ago

I'm bashing Perl because I'm using it daily today. I have the moral right.

People waxing poetic about their time using Perl back in the late 1990s/early 2000s don't have a vote because they clung onto good bits and have long forgotten the ugly.

it really makes Stream-of-Conscious programming the norm

Are you sure it's a Good Thing? Really sure? What if you have teammates? What if you have a life? What if you need to revise your stream of consciousness after a year? Still sure?

alfiedotwtf7• 2 years ago

I still use Perl, maybe not daily but yes to weekly, so I have still have skin in the game.

Yes I'm sure.

ukuina• 2 years ago

I have written Perl solo, and then migrated that Perl into a team setting, and the mindset shift needed is HUGE. I agree with you.

The happy medium is to write your program twice: Write it solo in Perl for rapid thought-to-code, figuring out architectural issues along the way. Then, write it again in Python for scalable collaboration using the revised architecture. This gives you a working solution for the problem FAST and adheres to "Do it, then do it right".

Unfortunately, this doesn't scale to systems. I do hope LLM-driven transmogrification becomes a real thing.

rabbiveesh• 2 years ago

I'm currently writing perl with a team, and I find that so long as you write in a way that looks good, there's no issue with other people reading the code either.

And that still happens at stream-of-conciousness.

forinti2• 2 years ago

Interesting this stream of consciousness analogy.

I use Perl a lot because it doesn't get in the way. The functional aspect of it lets you map from problem to solution easily.

thisislife2• 2 years ago

The worry with any language dying is the loss of knowledge that accompanies its demise. CPAN has a lot of great libraries that once used to power the early internet. Decades ago, it was in a Perl group / forum that I first heard the term "do not re-invent the wheel" when someone enquired about making some kind of their own CGI framework along with a great write-up about all the unique edge cases that the existing library already handled due to the experiential knowledge it had gained during its development. These were also the times when Oracle DBAs used to love Perl.

a-dub• 2 years ago

CPAN was pretty great, all the good practices around documentation and unit testing as well as quite possibly the first real internet native shared library community complete with beautiful tooling for one step download/install/test and strict curation.

on my first day of my first software internship in the mid 90s, my boss handed me the ora programming perl 5 book and said "read this." it served me well as a swiss army knife for many years.

WesolyKubeczek5• 2 years ago

Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project.

There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it doesn't count. JSON? You're guaranteed to have both JSON::XS and CPanel::JSON::XS. The list just goes on and on. HTTP clients? You have Furl, LWP::UserAgent, something built atop IO::Socket. TLS with HTTP? LWP::UserAgent::SSL, IO::Socket::SSL, and someone will use Net::SSLeay raw just to watch the world burn. You pull in all of the latter ones courtesy of modules doing API integrations because their authors just have their favorites.

Web? Oh, you want to do web. Mojolicious, Dancer, CGI::Application, just CGI.pm... Granted, at least you won't have libraries pull those in willy-nilly, thank goodness.

doublerabbit• 2 years ago

No difference to Python dependencies nowadays.

okwhateverdude2• 2 years ago

There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime.

I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.

There was a progression to things, mostly because of performance reasons why there is a bit of a proliferation. Moose (and the underlying Class::MOP) were about providing a meta-object protocol for Perl which didn't exist before it. As such, it was focused on being correct over fast. A whole community sprang up from stevan's art. Then sartak's Mouse came along and made some performance improvements with some compatibility caveats. Finally, mst's Moo stripped away the "reflection" aspects of Moose to really squeak out even more performance.

MooseX::Declare was always a (beautiful) research project. I spent some time in that space welding POE and MooseX::Declare together. But these weren't suitable for any kind of production code. If you see this live somewhere, you should definitely rip it out lol.

As for TIMTOWTDI, this is sorta why project Andy Lester's Phalanx came about (it was trying to bless a chunk of modules as a sort of smoke test for Ponie (perl5 implementation on the Parrot VM (which was the first step toward a Perl 6, now Raku)). It was trying to provide an opinionated set of high quality libs for SWE.

Unfortunately, working in Perl really requires a bunch of skill and discipline if you want a long-term maintainable project. This means really looking at your dependency tree and making difficult decisions on which libs to use specifically to avoid installing all of CPAN. npm's installing the world behavior was foretold by Perl.

andrewl-hn3• 2 years ago

About 5-6 years ago I found a new niche for Perl in my day-to-day work. I did a lot of shell scripting at the time and was constantly getting annoyed by subtle differences between macOS and Linux. Sed is especially difficult, because the flags in BSD version and GNU version for in-place search and replace do not match. Plus, sed regexes are more primitive compared to most other languages.

I decided to switch from sed to Perl for all my string replacements and at the time it made my life so much easier! Eventually I started expanding my Perl use to a few lines of code at the time, and now I write a few larger (100+ LOC) scripts in it a year.

Funny how my personal journey matches the story of Perl back in the 80s: it was born to replace more primitive tools.

silisili• 2 years ago

For anyone who cares, sed -i'' should be compatible on both mac and linux.

naniwaduni• 2 years ago

It is not. -i'' is exactly the same thing as "-i", and while GNU sed interprets this as an empty suffix, BSD sed expects -i to take an argument normally, and will treat the next argument as the extension. If you instead use sed -i "", as is appropriate with a BSD sed, GNU sed will interpret that as the empty program and try to read from a file named your actual script.

fouc• 2 years ago

I install gnutils in mac, gsed on mac is compatible with sed on linux.

BrandoElFollito• 2 years ago

Eventually I started expanding my Perl use to a few lines of code at the time, and now I write a few larger (100+ LOC) scripts in it a year.

This was the same road I took in the late 90's - started with simple scripts and ended up with more and more complex scripts when I was learning all the shortcuts. Until the day I could not understand anymore my own code from a few days back :)

diarrhea• 2 years ago

I wonder, is Perl more ubiquitous than Python for these cases?

cpach• 2 years ago

Possibly more terse.

webstrand• 2 years ago

Perl gets installed wherever `git` CLI is available, generally. I'd say it's more ubiquitous. And it doesn't suffer from the python2/3 split.

fullspectrumdev• 2 years ago

I switched from Python to Perl for a lot of these use cases as the Perl across many target devices is gonna be much the same/largely compatible, and virtually always present, while Python could be some random fucking version or broken or not present.

andrewl-hn3• 2 years ago

It is! Modern macOS, fresh install: no Python, no Ruby, but Perl is there. Git for Windows adds Bash with Perl in it. Every linux server has it. You probably can come up with some Docker image that doesn't have it installed, but it comes in as a dependency to a lot of linux software.

The cool thing is that Perl is compatible, and maintaining compatibility is the top priority for Perl developers. so, many distros keep updating it because it's very safe to do so. When many projects switched from GPL2 to GPL3 macOS famously decided to either freeze some bundled tools, switch to alternatives or removed them entirely. It took them years and years, but all this time Perl has been a notable exception.

As a result nowadays you can be very certain that every machine you run your code on has a very recent Perl installed, so you can use many new stuff, too. It's an old language, but the code you can write can be pretty modern, which is nice.

It's still Perl: lots of symbols, some variables get set up implicitly for you, some keywords look silly to modern eyes (`my` to declare a variable, `sub` declares a function). Some newish stuff is handy. Like, these days you can specify types of parameters in function signatures, and it does a rudimentary type-checking for you. And Perl regexes are still better than in ANY language out there, for 35 years and counting!

rasz• 2 years ago

Not to mention Write-Only nature of Perl is a nice added job security.

wdr1• 2 years ago

This is grossly exaggerated. Yes, sometimes Perl looks like line noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line noise.

galdosdi• 2 years ago

I picked up the same habit years ago in my first job because we worked with a mix of all the UNIXes (AIX, HPUX, Solaris, etc). Always "perl -pe" instead of "sed" and man oh man you're right perl is amazing for that, its original task

The trend then was towards standardization towards linux, but then that got compromised as that's when macbooks got popular with developers.

ydant• 2 years ago

Perl was my first programming language love. While we've largely gone our separate ways, we still keep in touch and occasionally we still spend some time together.

One such case is adhoc small scripts mid pipeline. There's just certain Perl syntax that's so deeply embedded in me that no matter how much I try to learn sed/awk/tr, I can't help but reach out to my old love in times of weakness and need. I just know how to talk to Perl in the most intimate of ways that's been hard to reproduce in other languages.

I still feel a little like I've betrayed Perl a bit every time I use Python.

Perl, Larry Wall, Randal Schwartz, Tom Christiansen, brian d foy, O'Reilly, and the many other participants of comp.lang.perl.* had such a lasting influence on my programming career. I wouldn't be who I am today as a programmer without having experienced all the Perl community put out into the world.

noisy_boy• 2 years ago

Like everything else, Perl has its warts - tacked on object orientation, crude way of handling errors, lack of a decent REPL, way too much expressiveness (I have seen what happens to a few hundred thousand lines of Perl code written by developers who, instead of writing in a maintainable consistent style, tried to show their cleverness and the language was a willing ally to that) etc. Many words have been spent on those shortcomings so I want to focus on the other side.

Many eons ago, I remember me (and my team) being so tired of writing bash wrapper scripts - we just didn't know any better. To my surprise/delight, I discovered that the Solaris boxes we were using came with Perl pre-installed (which in hindsight is totally expected). So I decided to learn about it the proper way and the Llama book was exactly what I needed.

People have called Perl code line noise. But when I read the book for the first time, everything make sense to me because my mind likes mnemonics. $ is for ($)calar, @ is @(rray), % has a pair of circles like key/value pair and so on. I didn't find it odd that you'll get the array in list context and count in scalar context - it made complete sense. Till date, Perl is the language which I reach out for short-term tasks which need to be done immediately, because it helps me get the job done at the speed of thought.

I picked up some bash scripts as candidates to be re-written in Perl and I will never forget my mind being blown by the sheer lightening speed of Perl scripts; stuff that took many seconds or even minutes in bash were done in a second or less, even with my unrefined code. It was like a new world opened up and indeed, I felt like a wizard.

7thaccount3• 2 years ago

I love the glyphs in APL, but not so much with Perl as they don't seem consistent. Like there is an "of that's an array, but you're accessing it with scalar context" or some catch.

With Python, you have lists, tuples, and dictionaries. Those are data structure objects that are useful for different things. Tuples use (), lists use [], and dictionaries use {}. After you learn that, you just learn the few methods and manners to populate them and you're done.

There's nothing wrong with either way of course. Both appeal to different kinds of folks.

larodi• 2 years ago

We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. And we had too many sigyls and weird symbols and we didn’t see farther than our nose, so we weren’t that good with foretelling things, but only with practical magic.

Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS.

But we were not brave enough to transpire to JS neither .Net, nor JRE so others figured out how to do it better before us… even though we tried.

Finally like all proud wizards we eventually split the magic school in two faculties and went in ever deeper obscurity and magic.

gorgoiler• 2 years ago

POE (2001!) was another async-ahead-of-its-time:

https://www.perl.com/pub/2001/01/poe.html/

https://en.m.wikipedia.org/wiki/Perl_Object_Environment

agumonkey2• 2 years ago

the perl community has a way to create cute abstraction that still makes sense ..

heresie-dabord• 2 years ago

We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world.

The submitted post exemplifies the worst characteristics of what we can call coding culture. Larry Wall was a polarising character. He could be witty but also tiresome.

The C and C++ coding cultures have had their problems too.

Python has been successful as a language and as a coding culture. I don't like the bigotry of the Python community towards other languages, but the openness and focus on coding ergonomics has been different from most (all?) other prominent languages.

It can't hurt to have a couple of MAANA (was FAANG) giants providing material support.

And we had too many sigyls and weird symbols

This I think is an unfair criticism frequently aimed at Perl by people who haven't reached fluentness. The language is expressive. To attain higher complexity, languages will adopt new symbols and forms. Anyone who knows Python and uses DSLs such as pandas and numpy knows that "sigils and weird symbols" make their appearances in the mutant notation.

Python has its own TIMTOWDI at this point.

marcus0x62• 2 years ago

Larry Wall was a polarising character. He could be witty but also tiresome.

To whom? Unless you were working on the Perl language itself, there was no need to interact with him.

thesuperbigfrog• 2 years ago

> Python has its own TIMTOWDI at this point.

It's Python's dependency management, and there is more than one way to do it:

pip, pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, egg, ActiveState platform, homebrew, or your operating system's package manager.

Relevant xkcd: https://xkcd.com/1987/

danesparza• 2 years ago

"Larry Wall was a polarising character. He could be witty but also tiresome."

Yes. This. Thank you for calling this out.

abecedarius2• 2 years ago

But I feel like Python is too complex and big to really like now. It was my go-to language in the 2000s as a kind of sweet spot: featureful/library-rich enough for getting things done, but not overgrown with decades of individually-worthwhile complications.

(Not saying it was ever my paradigm for elegant language design or that it's their job to conform to my taste.)

trabant00• 2 years ago

Learning Perl is imho the best book for beginning to code. It is clear, as short as it can be, fun, explains why not just how, encourages efficiency, has exercises, etc.

To this day I still recommend it even if opportunities to use Perl are gone.

7thaccount3• 2 years ago

There's a lot of really good Python books too (and I have a 5 foot stack of Perl books). I read one for Python in 2012 that finally got me into coding a lot. People overlook how the basic building blocks of Python are very simple. I learned Perl after Python and it's fine, but I often found Python to be a bit clearer and more obvious than Perl.

If I had to use a language just for Unix scripting, it would probably be Perl though.

briandfoy• 2 years ago

And, the latest edition of Learning Perl covers up to v5.34. I also provide additional exercises in Learning Perl Exercises (<https://leanpub.com/learning_perl_exercises>), and cover new features in Perl New Features (<https://leanpub.com/perl_new_features>) so I can update it faster than the paper books.

But yet, Randal had beat into me the idea of explaining "why" on everything. You'll notice the basic pattern in Learning Perl and my other writing is that we show the expedient thing, tell you how that fails, improve that a little, show how that fails, and end up at a better final solution. That path shows quite a bit that's ancillary to the task at hand, but also shows how the pieces work together and how different parts affect the solution. I'm usually frustrated by other language tutorials where they say "just do this" without saying anything about why the various parts are there.

Learning Perl was originally written with a C programmer audience, so it assumes that the reader is comfortable with ideas such as variables and looping. I have another book I might recommend for beginning to code: Squeak: Learn Programming with Robots. Sure, it's Smalltalk and literally written for teenagers, but I think it works. It reminds me of the fun days of Logo.

retrobox• 2 years ago

Perl was one of the first languages I learned and also the first language I used commercially. I have a huge soft spot for it as a language. Still love Perl regular expressions like no other. I loved the camel book and its various footnotes with both humour and deeper knowledge on a topic.

cushychicken4• 2 years ago

Right there with you.

No language even comes close to Perl’s regex support. First class support for regexes as programming tools, and unparalleled speed.

macintux2• 2 years ago

I attended Sun’s road show announcing Java to the world in 1996 (IIRC) and when I asked about regular expression support, I was shocked that it not only didn’t have it built into the language syntax, it wasn’t even available in the library.

As a die-hard Perl fan, that seemed a ridiculous oversight for a language being promoted for Internet programming.

abecedarius2• 2 years ago

The Perl Journal had that flavor too. I hardly ever read it because I had no interest in actually coding Perl, but it was great to see this kind of culture on the magazine rack at Borders or wherever.

pjmlp• 2 years ago

Yeah, while everyone still discussing on how to do FP in mainstream languages, Higher-Order Perl was published in 2005, placing many of such ideas how we were already doing that stuff in Perl into paper.

Perl allows to come at peace with UNIX being done in C, by exposing similar programing language capabilities, mixed with Lisp like wizardy, without having to deal with C security faults unless required for performance reasons, that could not be improved in any other way.

tmtvl• 2 years ago

Higher Order Perl is such a gem, one of the best programming books in general.

barrenko2• 2 years ago

Forgot most of the Perl I've learned, but I really should go through this book, thanks for bringing it up.

isomorphic-• 2 years ago

While Higher Order Perl had a lot of neat tricks, they were quite useless in production because they would slow things down significantly with all the subcalls.

noufalibrahim4• 2 years ago

I liked Perl for text parsing and that kind of work.. Used it professionally for about 3 years.

Two things i didn't like about it which i still don't

1. It's a conceptually huge language. There are several things to learn to be effective or you fall into the problem when the 10% that you use is different from the 10% that your teammates use. I found python attractive because of this.

2. I disliked Walls book. It was long winded and very hard to sit down with when I wanted to find something. I expected something like K&R but found it tedious and boring.

emmelaich• 2 years ago

regarding 2., are you sure you're referring to the Camel book and not the Llama book? To me, Programming Perl (Wall, Camel) is closer in spirit to K&R than Learning Perl (Schwartz, Llama)

noufalibrahim4• 2 years ago

Ah.. I'm not sure now.. It was a long time ago and i can't really remember which it was. The name Schwarz is familiar. Maybe it was that.

zephyrfalcon• 2 years ago

IMHO, Python is also huge nowadays. :( (The language itself, that is, not counting the 500K+ third-party libraries that it has nowadays.)

As for the Camel book, what I liked about it is that it explains why Perl is the way it is... the underlying philosophy. Once you know that, it starts making a lot more sense. You usually didn't get that with books like "Learn Perl in 21 days" or something.

SuaveSteve• 2 years ago

You will look up how to interpret `match` whenever you see it and you will like it.

One way to do things? Pfffft.

noufalibrahim4• 2 years ago

I get that. My gold standard for technical writing was (and mostly still is), the C programming language by K&R. Brief, to the point and not missing anything. It's what I expected from the Perl book but didn't get.

forinti2• 2 years ago

There's always Perl Cookbook if you need somewhere to look up solutions.

martyvis• 2 years ago

I was interested to learn on a recent episode of FLOSS Weekly [1] that Randal Schwartz had moved on from Perl somewhat and is now effectively an MVP and trainer of Dart and Flutter.

[1] https://hackaday.com/2024/01/09/floss-weekly-episode-765-tha...

okwhateverdude2• 2 years ago

Schwartz basically rode his early fame into the ground. While the world was moving on from Perl (especially after the community completely fractured and started disintegrating during the early days of Perl6, now Raku), he doubled down, but also didn't really produce much or engage with community. The Perl work around the world was drying up. He ended up begging online instead of pivoting. Glad to know he finally did pivot.

RandalSchwartz2• 2 years ago

This is a fair observation. At most, my FLOSS Weekly fame was still propelling my career, but I also gave that up after 13 years. It took a while to find my Dart/Flutter groove, but here I am.

cushychicken4• 2 years ago

Perl was the first programming language I worked with at a real, paying job. I don’t miss that job, but it did teach me a lot about how to deliver value quickly (Perl is still better at smashing 400 million lines of text than most other languages), and some of the impediments to that (Perl’s “write only” syntactic approach).

For all of Perl’s shortcomings, I’ve always felt that no other language came with Larry and Randall’s sense that programming was fun. The Perl folks always understood that our skills were rare, and the powers they conferred were inherently magic - even if a bit dorky.

bitwize2• 2 years ago

Now thanks to Devin, anyone can have that skill!

dleink• 2 years ago

But AI can never replace the human dorkiness I bring to a project.

RandalSchwartz2• 2 years ago

Indeed, I started programming early (age 9 or so) and have always seemed to have a talent for programming, but also just a sense that it's fun to work out how to express steps in terms of smaller reusable steps.

Scubabear68• 2 years ago

So I was doing Perl at this time on Wall Street, basically using it to replace shell-based abominations with something faster and easier to maintain. Perl 4.

Being in-process certainly sped things up. And it was easier to understand than the shell based solution.

But it would have been easier to write and read in just about any other language.

Perl 4 at the time only had very primitive data structures. Most of the time you were concatenating and splitting strings together to mimic real data types. The baroque way file handles were a first class data structure made abstracting over them painful and hacky.

That $foo and @foo and %foo were different variables caused innumerable bugs.

The exposure of function arguments as a stack directly in the language made for weirdness all its own.

The mimicry of shell expressions brought its own pain.

And finally, Perl’s greatest strength and horrific weakness: the regular expressions. One liners that would bring tears to your eyes the next time you had to debug it.

I get where Wall was going with Perl, but the emphasis on beautiful natural language for various idioms really crippled the language horrifically from the start. Going into Perl was forgetting nearly everything you knew from other languages and entering this unreal fantasy forest of code, with monsters lurking behind every rock and twist in the road.

rgrieselhuber• 2 years ago

Every time I see a Polish domain name I am reminded at how obsessed that country is with Perl.

kubanczyk• 2 years ago

Speaking of that:

   .sh  Saint Helena
   .py  Paraguay
   .rs  Serbia
   .md  Moldova
   .tf  French Southern and Antarctic Lands
   .cc  Cocos Islands
   .so  Somalia
   .bz  Belize
   .ps  Palestine

barrenko2• 2 years ago

If some old soul is up for it, Exercism Perl track could use improvements in concepts.

macintux2• 2 years ago

Worth noting that Exercism is (or at least was at the beginning of the year) experiencing a bit of a funding problem. It would be a remarkable shame if it were to go away, or be less accessible. Such a great resource.

joemaller1• 2 years ago

I miss my O'Reilly bookshelf.

mayd• 2 years ago

I still have mine and it has even grown a little.

We were wizards – a foreword to Learning Perl (1993)

Related Stories