[HN Gopher] We were wizards - a foreword to Learning Perl (1993)
___________________________________________________________________
We were wizards - a foreword to Learning Perl (1993)
Author : todsacerdoti
Score : 164 points
Date : 2024-03-17 04:34 UTC (18 hours ago)
(HTM) web link (jwgoerlich.com)
(TXT) w3m dump (jwgoerlich.com)
| alfiedotwtf wrote:
| 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 wrote:
| Stream of consciousness programming?
| bane wrote:
| 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.
| alfiedotwtf wrote:
| Exactly this.
|
| As fast as you type you're coding. Even though I've now
| spent years in other languages compared to Perl, it's still
| stop-start in every other language.
|
| I've said it many times, but Perl really moulds to your
| brain rather than the other way around. You bend Perl how
| YOU want it.
| eperoumal wrote:
| I so much feel the same. At the time I was writing Perl,
| each line made so much sense, as if I was speaking my
| mother tongue. It was clearly an extension of my brain.
| Never had that feeling with any other programming language,
| and it took me years to eventually let Perl go and try to
| wrap my head around Python.
| arp242 wrote:
| I wonder how much Larry Wall's background as a linguist
| has to do with that, which perhaps also explain some of
| Perl's "messier" features, just like natural language is
| kind of messy.
|
| I once had a long conversation about this with a linguist
| and Perl programmer that I randomly met in a pub.
| However, I was quite drunk and don't really recall too
| much, and we never saw each other again.
| singingfish wrote:
| This is quite an interesting phenomenon, and kind of
| explains why perl is disliked so much.
|
| Computer programming theory has large swathes of
| inspiration from theoretical linguistics - think lisp.
| That's nice for theoreticians because it makes things
| like parsing easier to think about rigorously. Perl on
| the other hand, to my knowledge is the only significant
| programming language to be inspired by practical
| linguistics, and therefore appeals to concepts like
| context and ambiguity way more than other languages. This
| means that a lot of computer scientists academics
| absolutely hate it, and so it was very much neglected in
| the education space.
|
| The other side effect of this is you still get a good
| number of talented programmers with backgrounds in the
| humanities and social sciences who do very well on perl.
| masto wrote:
| I love this subthread; I've tried to explain this for years
| and I've concluded it's simply impossible to convey to
| someone who never experienced it. It's sad, and really
| frustrating, to just hear the same clueless comments and
| memes repeated. So I'm glad to see there are still people
| around who know what it was like to work with a truly
| expressive language.
|
| About 15 years ago I was put on a Java project that ran for
| a year with half a dozen developers toiling away (along
| with an outsourced team that management eventually added to
| write unit tests). I spent half that time fighting with
| Eclipse and the other half divided between tearing my hair
| out trying to wade through the AbstractSpringFactoryInterfa
| ceAbstractFrameworkInjectorAbstractionBuilder nightmare,
| being lectured at by people who learned everything they
| know about computers from in-flight magazines that this is
| the way professional software development is done, waiting
| for the one person who could actually build the application
| (which he did partly by unzipping the jar files and
| manually tweaking their contents), and actually coding.
|
| To my complete lack of surprise, the project never achieved
| a working milestone and was cancelled. What did surprise me
| was that a coworker who was sympathetic to my grumbling
| persuaded the CTO who was trying to rescue the project to
| let me try it my way. On my own (using Perl and
| PostgreSQL), in a couple of weeks, I had a fully working
| prototype. We got the green light to proceed and built the
| company's flagship product on that stack. It was not my
| brilliant engineering as much as Perl's extraordinary
| ability to connect mind and machine (coupled of course with
| my brilliant engineering) that made it possible. I owe
| Larry Wall for a huge career boost.
| runlaszlorun wrote:
| Large teams themselves become boat anchors towards
| progress. But you've inspired me to spend a little time
| with Perl.
| alfiedotwtf wrote:
| LOL are you me? This is exactly what happened to me! Same
| situation, Java with an external team, project over
| budget and over time, gets canned and then a few weeks
| with Perl and it's done
| bitwize wrote:
| > 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.
|
| Funny, a lot of people say that about Lisp...
| singingfish wrote:
| 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.
| __s wrote:
| This can be nice in Python. The `dis` module makes
| execution pretty transparent, & it's easy enough to know
| what bytecode a given line will compile to (granted,
| comprehensions creating closures does make that a bit
| harder)
|
| CPython's implementation is also straightforward enough
| that you can look up ceval.c to get a gist of what an
| opcode is doing
| gonzus wrote:
| 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.
| fulafel wrote:
| About Python, are there practical situations outside IRC
| where you can't include a newline in there? This ..
| python -c ' import re, sys for line in
| sys.stdin: print(line.lower().count("foo")) '
|
| works in shell interactively (both bash and zsh support
| multiline history entries well), or in shell scripts, and
| also in slack/mattermost/matrix/email.
| teddyh wrote:
| You can do that as a one-liner (I have kept the unused
| "re" module import, to keep it as close to your code as
| possible): python -c 'import re, sys;
| print("\n".join(str(line.lower().count("foo")) for line
| in sys.stdin))'
|
| or if you want to avoid building one large output string:
| python -c 'import re, sys;
| print(*(line.lower().count("foo") for line in sys.stdin),
| sep="\n")'
|
| if memory consumption is still an issue:
| python -c 'import re, sys;
| set(print(line.lower().count("foo")) for line in
| sys.stdin)'
|
| (This creates a useless Set object and throws it away as
| a side effect.)
| hnfong wrote:
| It's sad that Perl is dying a slow death. Between Python
| and Perl, both styles of coding are possible.
|
| While Python is my preferred language for most tasks, I
| still use perl as an ad hoc stream processor with `perl
| -pe` and nothing really beats it at the task. Anything more
| than 10 lines and I find python easier to deal with (or at
| least it's my comfort zone).
| kstenerud wrote:
| 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.
| alfiedotwtf wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| alfiedotwtf wrote:
| >> 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.
|
| Don't forget Tainted Mode! It's 2024 and I still have never
| seen it adopted in any other language. It's essentially
| SELinux-lite for variables :)
|
| IMHO Perl lost to Python because of 3 reasons: 1) Google at
| the time chose Python and it was the new cool startup
| everyone wanted to work at, 2) Pandas and Numpy weren't
| matched in the market (I'd even argue this is still true in
| 2024), and 3) Perl 6 was way too ambitious and scared
| people off (even though Perl 5 was never going to go away
| overnight (and still hasn't))
| lloeki wrote:
| > safety
|
| You forgot safe mode and tainting, which while imperfect
| and has some sharp edges, is a first class construct that
| when correctly wielded outright prevents classes of attacks
| like shell or SQL injections or XSS.
|
| Some have been reinventing it in a piggybacked way, and so,
| partially/poorly (comparatively), e.g Rails's safe/unsafe
| strings in ActionView.
| singingfish wrote:
| Back compat is an important thing. A few years ago we took
| a 250kline from perl 5.8.9 to perl 5.16 in one hit. Out of
| the entire application under 50 lines of application code
| needed to be changed (excepting the big bump in cpan module
| versions). Currently I'm slowly finalising the move from
| 5.16 to whatever debian stable is currently shipping 5.34
| maybe? The biggest pain point is some type safety in the
| elastic search cpan module. Other than that I've had to
| slightly refactor some hacky but effective cache
| invalidation startup code due to a weird `perl -e` bug I
| found but can't characterise sufficiently precisely to
| report. The only reason that the perl latest upgrade wasn't
| done incrementally was because of a super weird unicode bug
| between perl and the oracle client library which is now out
| of scope for us.
|
| But I agree perl can have bad management problems because
| of different people's capabilities, and different people's
| approach to showing their individuality.
| HybridCurve wrote:
| Some of the arguments about Perl and bad engineering
| practice are not entirely without merit. Neglecting 'use
| strict;' or 'use warnings;' in your script typically makes
| this more apparent. The language itself however does not
| attempt to constrain developers in the same way modern
| languages do, instead the burden of responsible engineering
| is placed on the developer. The result is people that deal
| with badly engineered Perl typically become sour to the
| language itself.
|
| I reserved my criticisms of Perl for things like signal
| handling and it's implementation OOP(to name a few), but
| overall it's a good language.
| alexey-salmin wrote:
| 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 wrote:
| >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.
| WesolyKubeczek wrote:
| 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?
| alfiedotwtf wrote:
| I still use Perl, maybe not daily but yes to weekly, so I
| have still have skin in the game.
|
| Yes I'm sure.
| WesolyKubeczek wrote:
| Do you develop with Perl collaboratively with teammates?
| alfiedotwtf wrote:
| Not anymore, but I've probably worked on the largest Perl
| code bases in the world, so again... I'm not a Perl noob
| merlynkline wrote:
| Last year I finished over a decade on very large Perl
| project, collaborating within a team. When I joined that
| project it was already over a decade old a most of the
| code was much like what you are probably imagining. When
| I left the project, all the parts we had touched were
| much like any other high quality modern codebase, and we
| could almost as readily maintain the decade-old parts
| (that we had worked on) as the week-old parts.
|
| Having worked in many languages over many decades, I've
| learned that a high quality codebase is built by high
| quality developers, largely independent of the languages
| they use. You can build an unmaintainable mess in any
| language as easily as you can build a high quality
| codebase in Perl. I would concede that you can more
| easily build an unmaintainable mess in Perl than in many
| languages but that's up to you; you can do most things
| more easily in Perl than in many languages ;)
| singingfish wrote:
| The advantage of bad perl is that it pretty much is
| immediately obvious on first sight that it's bad perl.
| Compare with python, it takes thought and time to
| identify bad python because it's so syntacticly bland.
| ukuina wrote:
| 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.
| runlaszlorun wrote:
| I've never done Perl but would writing solo in Perl and
| then rewriting it again in Perl with a team be an option?
|
| I have an affection for both Forth and Lisp, two languages
| that have also been called highly productive but write
| only.
|
| I think a working early version- even if its a spreadsheet-
| is 10x of a supposedly 80% done version of something else.
| The latter of which I must now return to unfortunately...
| rabbiveesh wrote:
| 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.
| forinti wrote:
| 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 wrote:
| 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 wrote:
| 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.
| WesolyKubeczek wrote:
| 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 wrote:
| No difference to Python dependencies nowadays.
| 7thaccount wrote:
| Not really. There is typically just one import for CSV,
| JSON...etc. It can be hell to get the various libraries to
| work though.
| okwhateverdude wrote:
| >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.
| WesolyKubeczek wrote:
| > I think this is hyperbole.
|
| (Looks at the dependency graph) No, it's a fact.
|
| > Generally, you won't be mixing Class::Accessor and Mo*
| based dependencies unless you are dealing with a shitty,
| barely maintained legacy codebase.
|
| I don't. But the modules my project depends on
| (transitively) do, because those modules were developed and
| last touched during different fad eras. So when the app
| starts, I have, like, four OO systems, three ways to do
| JSON, two to do YAML, and four ways to do HTTP in the
| memory.
|
| Also, the authors of said modules tend to have Egos and
| Opinions (capitalization intended) that prevent them from
| converging on common things.
| singingfish wrote:
| ... and now you have Mojo::Base which is kind of like Moo
| lite with batteries included. Last week I was concurrently
| programming some Mojo::Base stuff and some python stuff
| with cached properties, and I way more enjoyed the salience
| of my intention in the perl code.
| andrewl-hn wrote:
| 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 wrote:
| For anyone who cares, sed -i'' should be compatible on both mac
| and linux.
| naniwaduni wrote:
| 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.
| LegibleCrimson wrote:
| I hate that behavior of GNU sed (and also of mktemp).
| Having a flag optionally take an argument is just so weird
| and surprising, and the syntax is always unexpected and
| inconsistent.
| jppittma wrote:
| I don't see it as a flag that optionally takes an
| argument, but rather a flag that makes an optional
| argument mandatory.
| LegibleCrimson wrote:
| No, that's how optional flags should work. I mean how
| specifically -i works. With GNU sed:
|
| -lN, --line-length=N, -l N, --line-length N
|
| All work the same, set line length to N.
|
| -iSUFFIX --in-place=SUFFIX, -i NEXTARG --in-place NEXTARG
|
| Don't all work the same. The argument is only actually
| taken if it's attached to the flag directly. In the
| latter two forms, no backup is made.
|
| GNU mktemp is similarly annoying, but different, with the
| --tmpdir flag.
|
| -pDIR, --tmpdir=DIR, -p DIR, --tmpdir NEXTARG
|
| Only the last one is different. If you use --tmpdir
| literally without attaching an argument to it, it
| defaults to $TMPDIR, otherwise it takes in DIR.
|
| This is inconsistent and unpredictable. A flag should
| either take an argument or not.
|
| I also dislike Python's argparse variable-length nargs
| behavior for similar reasons. Even with an integer nargs,
| it makes for an ugly command line, but with variable-
| length ones it just gets hideous, and can make it
| impossible to pass an argument beginning with a hyphen to
| a flag.
| fouc wrote:
| I install gnutils in mac, gsed on mac is compatible with sed
| on linux.
| Twirrim wrote:
| If you ever use "grep" on mac, it's also worth installing
| gnutils and switching to ggrep instead as it is
| significantly faster.
| BrandoElFollito wrote:
| > 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 wrote:
| I wonder, is Perl more ubiquitous than Python for these cases?
| cpach wrote:
| Possibly more terse.
| webstrand wrote:
| 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.
| kstrauser wrote:
| Neither does Python, for years now.
| doubled112 wrote:
| I'm pretty sure people are going to be haunted by it for
| years. I just updated some internal scripts for Python 3
| this year.
|
| I believe they should have been Py3 when they wrote them.
| It was not my decision, but it did become my problem.
| bla3 wrote:
| That split was terrible and it took over a decade to fully
| resolve, but it's behind us now.
| toast0 wrote:
| Perl did have a 5.6/5.8 split over unicode, but it wasn't
| nearly so bad. By the time 5.10 came out, I think
| everything had been sorted. Or my work changed and I
| stopped running into code that I needed to patch 'use
| bytes' into.
| fullspectrumdev wrote:
| 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-hn wrote:
| 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!
| darrenf wrote:
| > _It took them years and years, but all this time Perl has
| been a notable exception._
|
| If we take Apple at their word then it's an exception only
| in that they haven't got round to it _yet_ , not that it
| isn't also going to be culled -- the Catalina release notes
| mentioned Perl explicitly alongside the other two:
| Scripting language runtimes such as Python, Ruby, and Perl
| are included in macOS for compatibility with legacy
| software. Future versions of macOS won't include scripting
| language runtimes by default, ...
|
| -- https://developer.apple.com/documentation/macos-release-
| note...
| andrewl-hn wrote:
| Yep, Ruby and Python got removed very quickly from the
| system following this announcement. Perl, however, stays.
| It seems like some components of macOS depend on it and
| the dependency is hard to remove. It will likely happen
| but huge kudos to Apple for keeping it up to date
| meanwhile.
| rasz wrote:
| Not to mention Write-Only nature of Perl is a nice added job
| security.
| wdr1 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 7thaccount wrote:
| 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 wrote:
| 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 wrote:
| 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
| agumonkey wrote:
| the perl community has a way to create cute abstraction that
| still makes sense ..
| heresie-dabord wrote:
| > 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 wrote:
| > 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.
| justinator wrote:
| I offered to help out with the Perl 6 logo, as I had both
| experience writing Perl as a career and having gone to art
| and design school - while also running a printing studio of
| my own.
|
| I joined the Perl6 dev mailing lists, listened in on them,
| offered my support, gave a broad stroke on design ideas,
| backed them up with reasonable arguments and asked for
| comments. Larry chimed in basically saying, "no, because
| this sucks" and not too long later the Camelia butterfly[0]
| thing was born.
|
| So yeah, I bounced.
|
| Larry may be brilliant, but maybe he also has a history of
| not knowing when to delegate tasks (and trust). And now
| Perl WAS something, rather than IS something.
|
| [0] https://raku.org/camelia-logo.png
| pvaldes wrote:
| That cheap logo did serious brand damage...
| justinator wrote:
| "Perl 6" in a monotype typeface would have been worlds
| better.
| pvaldes wrote:
| An elegant logo having "Camellia" is straightforward to
| design. They could even have some fun, use the fact that
| Camellia is the Tea plant and lampoon Java (with a flower
| floating on a cup for example, Japanese style). That
| would had sent the correct message of "we are back,
| unafraid to comparisons, and want our throne returned".
| And would be perfectly inclusive for both men and women.
|
| We all ask the children to name the pets. Is cute, but
| often we live to regret it. With logos is the same.
| justinator wrote:
| I love it - these are really good, fun ideas.
| counterpartyrsk wrote:
| Can you provide a link to this conversation? I'd love to
| hear your input or see what you proposed.
| justinator wrote:
| To clarify, I am OK if Larry shot down a design idea on
| Perl 6 itself, but there WAS a RFC of design ideas, which
| I did not contribute because honestly, I am not qualified
| to design a language.
|
| I am qualified to help design a logo. And if the feedback
| was, "great ideas, but not the direction I want to go.
| What about..." or anything similar, that would be a fine
| way to show that my offer for doing free work is still
| happily welcome, with reasonable direction from the owner
| of the project. You know like a discussion.
|
| There's some great OS logos. The Linux Penguin was great.
| BSD Daemon, etc, etc, etc. I love the camel, but that's
| not owned by Perl. It's not an impossible task.
| thesuperbigfrog wrote:
| >> 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/
| agumonkey wrote:
| python packaging is nearing "there's no way to do it right"
| danesparza wrote:
| "Larry Wall was a polarising character. He could be witty but
| also tiresome."
|
| Yes. This. Thank you for calling this out.
| abecedarius wrote:
| 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 wrote:
| 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.
| 7thaccount wrote:
| 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.
| retrobox wrote:
| 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.
| cushychicken wrote:
| 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.
| macintux wrote:
| 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.
| cushychicken wrote:
| _not only didn't have it built into the language syntax, it
| wasn't even available in the library._
|
| Did not know that about the first Java release. That shit
| is bananas.
| abecedarius wrote:
| 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 wrote:
| 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 wrote:
| Higher Order Perl is such a gem, one of the best programming
| books in general.
| barrenko wrote:
| Forgot most of the Perl I've learned, but I really should go
| through this book, thanks for bringing it up.
| isomorphic- wrote:
| 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.
| noufalibrahim wrote:
| 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 wrote:
| 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)
| zephyrfalcon wrote:
| 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 wrote:
| You will look up how to interpret `match` whenever you see it
| and you will like it.
|
| One way to do things? Pfffft.
| forinti wrote:
| There's always Perl Cookbook if you need somewhere to look up
| solutions.
| martyvis wrote:
| 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...
| okwhateverdude wrote:
| 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.
| cushychicken wrote:
| 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.
| bitwize wrote:
| Now thanks to Devin, _anyone_ can have that skill!
| dleink wrote:
| But AI can never replace the human dorkiness I bring to a
| project.
| Scubabear68 wrote:
| 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 wrote:
| Every time I see a Polish domain name I am reminded at how
| obsessed that country is with Perl.
| barrenko wrote:
| If some old soul is up for it, Exercism Perl track could use
| improvements in concepts.
| macintux wrote:
| 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 wrote:
| I miss my O'Reilly bookshelf.
___________________________________________________________________
(page generated 2024-03-17 23:02 UTC)