[HN Gopher] On the Decline of Perl - external factors
___________________________________________________________________
On the Decline of Perl - external factors
Author : pabs3
Score : 119 points
Date : 2021-04-01 10:08 UTC (12 hours ago)
(HTM) web link (www.nntp.perl.org)
(TXT) w3m dump (www.nntp.perl.org)
| xaduha wrote:
| That whole mug throwing incident did Perl no favors. They needed
| to continue competing with PHP and Python at the time with full
| focus, not start gazing into the future of computing.
| mcherm wrote:
| Yes, the color of the spoon DOES matter.
|
| In fact, the color of the spoon (the syntax and expressiveness of
| the language) is probably why Python won out over Perl; it is
| certainly why I switched somewhere in the late 90s.
|
| Also... If your niche language isn't well supported by those who
| build language bindings for libraries and systems, fix that by
| making it extremely easy to create language bindings. If building
| a Python-to-Your-Language bridge is the only way to achieve this
| (it isn't) then build that.
| gillesjacobs wrote:
| Perl was my first programming language, however ill-advised, it
| was what my computational linguistics professors used in 2012.
|
| It was a trial-by-fire implementing new modules in a codebase
| written by a seasoned Perl programmer who didn't shy away from
| its esoteric features. Having mostly moved to Python, I can't say
| I miss the whackiness of the language.
| newobj wrote:
| I've been doing everything in my power to avoid perl since the
| early 90's. It's a garbage language. It thrived in spite of
| itself. Its obtuseness is fetishized. Its users have Stockholm
| Syndrome. I don't know what else to say. Bracing for downvotes.
| cutler wrote:
| "Programming Perl" by Larry Wall sits on a bookshelf across
| from my bed. When I wake up it's usually the first book my eyes
| alight on though I don't use Perl much these days. It still
| brings back fond memories and is an inspired work to this day.
| Larry Wall was a linguist and Perl will always look like
| sigilitis if you don't take half an hour to grok context. Perl
| particularly appeals to those who see beauty in regular
| expressions. Those that hate/avoid regular expressions usually
| hate Perl. Perl was my first real programming language after I
| found a reference to regular expressions in the Find & Replace
| section of a Dreamweaver manual. There was a reference to
| Jeffrey Friedl's brilliant work "Mastering Regular Expressions"
| which was part of the O'Reilly Perl library and that led me to
| Perl. Happy days. Much better than fighting my way through the
| thicket of front-end Javascript.
| azangru wrote:
| Having started with more modern scripting languages, such as
| ruby, javascript, or python, every time I touched perl I felt it
| was actively fighting me. Those sigils! God, those sigils! It's
| bad enough that we have to prefix variable names with a dollar
| sign in php, as if a language parser can't be smart enough to
| figure out whether you mean a variable or not; but having to use
| three different sigils for scalar variable, array variable and
| hash variable, and needing to know when to refer to the same
| variable with the array sigil or the scalar sigil -- this is just
| vile. Things like $_ or @_ didn't help either.
|
| Probably people who took up perl after something even more
| adversarial can learn to love it. I doubt I ever can.
|
| What I did love about perl though -- something I don't find in
| modern languages -- is its carefree playfulness, which must have
| stemmed from the hacker culture associated with it. I still
| chuckle every time I use Carp for debugging. Carp::croak,
| Carp::confess, or Carp::cluck are genius!
| throwaddzuzxd wrote:
| >What I did love about perl though -- something I don't find in
| modern languages -- is its carefree playfulness, which must
| have stemmed from the hacker culture associated with it. I
| still chuckle every time I use Carp for debugging. Carp::croak,
| Carp::confess, or Carp::cluck are genius!
|
| As someone who works with a legacy system written in Perl
| (we're slowly moving to Go), I absolutely hate this. It's
| completely obscure for no reason, and that's just not fun. I'm
| glad no language does this anymore.
|
| Same goes for Perl critic levels: --brutal | --cruel | --harsh
| | --stern | --gentle, they're all compleyely useless at
| conveying any meaning! why is brutal > cruel??
| WesolyKubeczek wrote:
| I concur. My English is pretty good, but to fully master
| these naming conventions, one needs to major in English.
|
| For Christ's sake, I keep forgetting what "croak" and "cluck"
| even are in, you know, normal language usage.
| pvaldes wrote:
| I suppose that because you can be cruel with somebody without
| touching it physically. Being brutal involves cruelty +
| physical violence, thus is more than cruel.
| nikau wrote:
| erg that's one thing I hate about modern tools, they love to
| use stupid terminology like helm with charts and salt with
| pillars and all this other childish shit.
| goatinaboat wrote:
| _they love to use stupid terminology like helm with charts
| and salt with pillars and all this other childish shit_
|
| Chef is the worst for this
| bashinator wrote:
| Yeah, Helm and K8s are not great in that regard, but the
| overwrought metaphors do end pretty quickly in favor of
| naming things for what the actually are.
| blacktriangle wrote:
| That same feeling of carefree playfulness is also the reason
| I keep meaning to give Raku a visit. They're pretty explicit
| about it even with pages like https://raku.org/fun/ and
| https://raku.org/whatever/. It looks like they've done some
| interesting stuff around making text-based command line tools
| really easy to work with, which makes sense since that was a
| huge part of perl5's wheelhouse, so I think that may be a
| good place to start digging into Raku.
| daotoad wrote:
| I have played with Raku a bit over the years, but haven't
| taken it up for any major projects.
|
| But I have found the experience incredibly useful. Using
| Raku is like working with advanced alien technology. My
| experience with it changed the way I write other code.
|
| I recommend playing with Raku for mind expansion.
| dmingod666 wrote:
| I worked on and off on perl for about a year... Could never
| remember $_ and @_ which one was which..
| kbd wrote:
| $calar, @rray is a mnemonic for the sigils.
| singingfish wrote:
| The sigils are a feature that underpin perl's roots from
| practical linguistics (unlike other languages which have roots
| in theoretical linguistics).
|
| $ - > the value of
|
| @ - > the values of
|
| % -> the collection of key value pairs
|
| $_ is pronounced "it". @_ is pronounced "them". Don't use
| either of them except if it would make sense in english - e.g.
| you wouldn't refer to "it" in anything more than a sentence, so
| don't use $_ in anything longer than a couple of lines of code
| azangru wrote:
| > The sigils are a feature that underpin perl's roots from
| practical linguistics
|
| I am not sure this metaphor makes sense to me.
|
| Imagine that I have a pack of dogs. When I use a language to
| say: "Remember that pack of dogs that I mentioned previously?
| Go ahead and give it to me" -- I do not expect to also need
| to specify whether I want the pack with all the dogs in it,
| or whether I just want some value associated with that pack,
| which, if I remember perl's behaviour here, would be its
| length. I could understand if a language wanted me to specify
| whether I want the thing itself as opposed to a reference to
| the thing (I suppose it would make total sense as a
| Saussurian opposition of a signifier vs the signified); but
| the ternary opposition that perl enforces is neither here nor
| there linguistically -- it's just bizarre.
| singingfish wrote:
| It's not a metaphor - it's the actual design.
|
| The fact that you use two sentences don't make sense
| together in order to try to illustrate your point seems to
| me to demonstrate that.
| singingfish wrote:
| here's a different one for you. This one is definitely a
| metaphor:
|
| Python helps you to think more like the computer does. Perl
| helps the computer think more like you do.
| daotoad wrote:
| The the distinction in Perl is context. If I want to
| flatten that pack of dogs into a collection of individual
| dogs, I'd use the `@` sigil. If I want to operate on the
| pack as a whole, I'd use the `$`.
|
| Context and list flattening are probably the most foreign
| parts of Perl to someone who doesn't know it. Everyone
| fixates on the sigils, but the weirdness in the way sigils
| operate stems from context.
|
| When you call a function, the arguments are flattened into
| a single list. So `foo(1,2)` is the same as `my @args =
| (1,2,3); foo(@args, 3)`. Every expression can be evaluated
| in one or more contexts. So taking the value of an array in
| scalar context gives you the length, which is handy but
| also means that, since 0 is falsy, you can just do logical
| tests on arrays to check if they are empty. Because the
| behaviors are relatively intuitive, it's possible to quite
| a bit of work in Perl before you even understand what
| context is or how it operates. `if (@foo) { do_stuff(@foo)
| }` does what you'd think it does, even if you don't know
| about context.
|
| But it also means that the distinction between `my $match =
| $foo=~/(foo)/g;` and `my ($match) = $foo=~/(foo)/g;` is not
| at all obvious if you don't understand context. (The first
| example gives you the count of matches, the second example
| gives you the first match because the parens put you in a
| list context which means you are effectively assigning into
| a slice.)
| zby wrote:
| Sigils are for simpler visual parsing - they stand out and mark
| the 'nouns'. It is not about the compiler - but about people
| reading the code. I know you can get similar advantages with
| IDEs colouring the code - here it is in the language itself. I
| find it useful. I think people just don't like the typography
| of dollar sign. It is ergonomic because it stands out but it is
| uglier than other glyphs and that impresses people badly. Later
| they only look for confirmation of that first bad impression.
|
| But I agree about the use of '$' for array elements.
| '$array[$index]' - this is kind of unintuitive - because the
| array is @array - and here you need to change the sigil. That
| is why in Perl6 (and Raku now) they got rid of that.
| azangru wrote:
| > Sigils are for simpler visual parsing - they stand out and
| mark the 'nouns'. It is not about the compiler - but about
| people reading the code.
|
| I would argue that python, ruby, javascript and similar
| languages have demonstrated that it's just as easy to read
| code without sigils as with them, probably even easier -- let
| alone to write one. Uncle Bob and other evangelists of
| software craftsmanship suggest clear, descriptive names for
| variables that would convey their meaning to the reader. As
| far as I understand, perl programmers also don't dispute the
| value of meaningful names. At which point using additional
| twiddles for conveying intent to the reader becomes
| redundant.
| daotoad wrote:
| The advantage with sigils, that little bit of standardized
| extra information means that I don't have to do any work to
| distinguish a verb from a noun. It makes it possible to use
| names that are just a bit shorter, on average, without
| sacrificing readability.
|
| It's funny to me to see the same people who complain about
| sigils in perl whole heartedly adopt the Rx convention of
| naming streams with a tailing $.
|
| It's literally just a sigil. Yeah, you put it at the end,
| but it serves the same exact purpose.
| fatbird wrote:
| In my experience those sigils fell into the same trap that
| Hungarian notation discovered. A few sigils work well because
| they provide immediate comprehension, but there's a tipping
| point where they become noise and a barrier because there's
| too many, in too many combinations, to be readily understood.
| In every perl script you end up reading them out loud to
| parse them.
|
| I remember the moment that Hungarian notation died for me
| (when previously I was all about it in C++): when I looked in
| the back of a Microsoft book on Visual Basic and found a six
| page table of four letter prefixes for all the different
| types you might encounter in VB6 with COM. The idea that I
| would either memorize those or continually look them up so
| that I knew what I was dealing with in code was the _reductio
| ad absurdum_ of Hungarian notation.
| jes wrote:
| I used Perl on and off for decades. It was fine.
|
| It seemed that Perl allowed me to leverage my existing knowledge
| of UNIX utilities, regular expressions, etc. So using it wasn't
| completely like learning a new programming language and a set of
| libraries at the same time. In other words, the startup cost
| wasn't all that high.
|
| I agree with comments about doing anything too complex with data
| structures in Perl. I am sure there are people that easily
| remember the syntax for returning a reference to a hash of
| hashes, or whatever. I'm not one of them. Every time I have to
| work on applications I wrote previously that did this, it's a
| couple of hours of googling and trying things out in the
| interpreter.
|
| If I had to write or rewrite a large application today, I'd
| probably use Python. I learned it fairly well about ten years ago
| and enjoyed working in the environment.
|
| In my secret inner fantasy world, I'd use Common Lisp
| exclusively, my colleagues would just agree that it is the best
| programming language ever, and we'd spend our days sitting in an
| outside cafe in San Jose, drinking espressos, hacking our .emacs
| files "for efficiency," and telling stories about how we used to
| boot computers by first toggling in the boot loader from the
| front panel.
| blacktriangle wrote:
| I wonder if you've hit on a major factor of Perl's decline.
| Like you say much of Perl's power was leveraging existing unix
| utilities, the whole duck tape development thing. As more
| developers started growing up on windows and then macs, fewer
| developers had knowledge of the tools to tie together. Without
| the unix tools to tie together, perl's value proposition drops.
| daotoad wrote:
| I believe this is a major reason. Demographic shift.
|
| Perl grew to prominence when being a creole of C, shell, sed,
| awk, and lisp was an advantage. Anyone who might reasonably
| use it would be familiar with at least a few of these tools.
|
| Now, we live in a very different world. JavaScript is the new
| BASIC. Everyone has JsBASIC installed on their (virtual)
| machines. So that's what people learn on their own. Python
| and Java are closer to JS so, the transition is easier (at
| least superficially--I could argue that JS and Perl a lot in
| common, designwise).
| sea6ear wrote:
| I think a related factor is the shift from raw text to
| databases. Perl's text oriented tools shine (obviously)
| when there is a lot of text to deal with. There was a lot
| of that at the dawn of the web.
|
| However, the rise of database backed web apps gradually
| removed a lot of the need for the special magic that Perl
| brought to the table.
| jes wrote:
| I think that may be part of it. For example, if grep (1)
| doesn't already mean something to a person, they probably
| won't have an immediate idea about what the grep function in
| Perl is all about.
| fennecfoxen wrote:
| > I am sure there are people that easily remember the syntax
| for returning a reference to a hash of hashes, or whatever.
|
| Ehhhhh. I appreciate the opaqueness of Perl, but you've
| described something like the easiest data structure in Perl to
| write and access: return {"foo" => {"bar" => "baz"}}; return
| {foo => {bar => "baz"}}; $data->{foo}{bar} = "quux"; etc etc.
|
| It's when you drop away from the land of hashrefs and listrefs,
| and have to use plain old hashes and lists, that things
| actually get super weird - because most programming languages
| you're used to simply give you "refs" for everything, and they
| _definitely_ don 't have concepts like "list context" that let
| you merge lists by saying @a = @b, @c;
| bsder wrote:
| > KiCad has a scripting engine for automating boring repetitive
| tasks - it's Python.
|
| This is actually a _giant_ sore point for me as a programmer. Let
| me ask the HN collective for advice:
|
| How do you set up an interface for a scripting language in a
| larger application?
|
| Most applications like KiCad or Blender have their own Python
| baked very deeply into the software architecture. It works ...
| mostly ... but it seems to me like its suboptimal
|
| 1) you have to jump through an enormous amount of hoops to try to
| connect your "normal" development environment to the "captive"
| scripting engine.
|
| 2) controlling UI elements from the scripting language is a real
| PITA
|
| 3) you don't have a choice of scripting language
|
| It seems like there ought to be a better way to do this, but I
| always wind up sort of landing on "open a socket and talk RPC"
| which has it's own failure modes (for example: how do you expose
| _everything_ (including the UI) and how do you handle concurrent
| access).
|
| What is the solution to this?
| skywhopper wrote:
| I learned Perl in the mid 90s and it was a revelation. You could
| do so much with it so easily. But by the mid 00s I was working to
| phase it out whenever I saw it, because of several factors, some
| identified here already:
|
| * poor language support for building complex programs or data
| structures... it was possible but never easy. * the stdlib:
| compared to PHP, Python, and Ruby, Perl offered very little
| built-in, which means that the next item was even more critical:
| * CPAN: was extremely difficult to automate and extremely flaky
| compared to the alternatives, RubyGems in particular.
|
| And yes, Perl6, which for a long time prevented Perl5 updates
| entirely. They got past that, but it was too late. I think the
| uncertainty guaranteed no one was going to invest in pushing for
| the needed improvements to CPAN either (tho maybe they've
| happened, I haven't even tried in a decade).
| marcod wrote:
| Mirror
| https://web.archive.org/web/20210401101221/https://www.nntp....
|
| (getting a 503 from the original)
| cryptos wrote:
| For me Python is a more ergonomic language. It is easier to read
| and write. And that led to a sustained growth of Python. Python's
| popularity exploded in recent years due to data analytics tools
| using that language, but there was a reason why these tools did
| choose Python in the first place ...
| perlperson wrote:
| Lots of interesting comments about Perl's shortcomings here. I
| think it's safe to say both Ruby and Python became popular
| because they addressed this sentiment -- for instance, type "man
| ruby" and notice references to Perl twice in the description.
| Python's "one way to do it" was a direct reaction to Perl's motto
| "there's more than one way to do it".
|
| Perl 6/Raku was also a response to Perl's shortcomings. The
| rewrite has allowed the language to leapfrog several other
| languages in various ways. Without going into details, I'm
| thinking about just concurrency, gradual typing, parsing, method
| dispatch, unicode handling -- digging into any one of these
| topics reveals a lot of richness to be explored.
| danjac wrote:
| Odd that there's no mention of PHP: many developers who used
| Perl/CGI back in the early days of server side development moved
| to PHP and PHP was much easier for beginners, especially if you
| wanted to incrementally move from a static to dynamic site. Perl
| was, in its day, as much the king of web development as it was
| admin scripting.
| endemic wrote:
| I tried really hard to learn Perl/CGI as a young'un, but it
| wasn't until I tried PHP that web programming "clicked" for me.
| luckylion wrote:
| It's not just that it was easier, it also ran everywhere, was
| fast (with mod_php), did not require chmod'ing files on the
| server, did work even if you uploaded the file with windows
| line breaks, had parameter parsing and sessions built in. It
| was pretty quickly superior to Perl for web-stuff in my
| opinion.
| jrwr wrote:
| I still like it for CRUD apps and below. you really can't
| beat just being able to take a plain HTML file and throw a
| few <?php foreach($array as $row){ ?> in the middle of it
|
| as a quick and dirty web app it feels much more useful then
| anything else.
| oaiey wrote:
| I moved from ASP to PHP and then soonish 20 years of C#.
|
| When I see or code PHP nowadays, I still feel welcome and
| understand all of it. Kudos to the PHP team for that.
| reducesuffering wrote:
| > "In practice, Python has snowballed simply because of network
| effect. Everyone knows Python so everyone uses it so everyone new
| has to learn it."
|
| Sigh. You would think that reflecting on a thread the author
| knows is public would have better introspection than this, but
| there's that Upton Sinclair quote again:
|
| "It is difficult to get a man to understand something, when his
| salary depends on his not understanding it."
|
| Python didn't win simply by randomly being selected as the choice
| to snowball effect on. Ask any language-agnostic or new
| programmer to take take a gander at each one. 90% will find
| Python easier to use. That's where Python's strength is, and that
| is a huge market, as the general population just isn't that great
| at advanced lower-level programming like C++. So you have college
| intro courses and programming-adjacent fields in academics
| (stats, bio, etc) able to dabble into Python. Perl kept plodding
| on with it's diehard unix fanbase. You can't expect mass appeal
| when that's your focus. Still failing to acknowledge this is what
| contributed to Perl's downfall (random snowball effect,
| seriously?) at the expense of Python is why Perl continues its
| decline.
| UncleOxidant wrote:
| Not only that, but the "everyone knows Python so everyone uses
| it..." argument seems tautological (Python won because it won).
| You could argue that more people knew Perl in the mid-to-late
| 90s than Python - so why didn't "everyone knows Perl so
| everyone uses it so everyone new has to learn it" sustain
| Perl's adoption then?
| dkarl wrote:
| It seems like people barely have to glance at Python to know
| it. Perl is harder, and for many people (or at least me) it
| didn't stick without constant practice. I put in the effort
| to learn Perl several times, but any time I left it alone for
| a month or two, my brain purged it. I finally embraced Python
| after realizing that I could still remember how to code in it
| after casually messing around with it a few months prior.
| UncleOxidant wrote:
| I'll add that perl code is much harder to read and
| understand even if you're the author of said code. I wrote
| a lot of Perl code in the 90s and I'd often come back to a
| piece of code I'd written a few months before and be
| puzzled.
| SubjectToChange wrote:
| For handling text, there is no better language than Perl.
| It's a great language for scripting on Unices and unix-like
| systems. But OOP and API oriented programming really got
| going in the late 90s and Python is by far a better fit for
| those concepts. It's probably a better language for general
| purpose programming altogether.
|
| However, I think languages like Perl, PHP, and Tcl get far
| too much grief. To quote Hemingway "Critics are men who watch
| a battle from a high place then come down and shoot the
| survivors."
| NelsonMinar wrote:
| There was definitely an era where Perl had way more mindshare
| than Python. It was the winner of the snowball effect.
| syntheticnature wrote:
| The old chestnut that Python is executable pseudocode and Perl
| is executable line noise is relevant, though they each have
| their pain points.
| dkarl wrote:
| Something that just happened, and I immediately realized it
| would be relevant to share here:
|
| A friend of mine texted me a question about an issue he was
| having, and I texted back an answer with some Python code for
| illustration. I don't know if he has ever used Python for
| anything. I just assume it's an acceptable least common
| denominator for technical communication. Even if it turned out
| he was a copy of my friend from an alternative timeline where
| Python never existed, he would have no trouble reading it as
| pseudocode.
|
| Try that with Perl!
| hatsuseno wrote:
| Extrapolating your take on Python's snowball here means that
| Python will fast decline given it's just bloating with every
| passing year with whatever the PEP reviewing folk think is a
| good addition to the language. The TIMTOWTDI perspective that I
| personally very much appreciate and value is slowly taking the
| field from Zen Python's one obvious way to do it.
| AzzieElbab wrote:
| Don't be fooled by the 503 this site is returning, it is actually
| valid Perl code
| chrisseaton wrote:
| I think what changed was that when Perl was popular people were
| generally a bit more into lots of wacky way to do the same thing,
| deliberately whimsical terminology, puns in their programs, the
| program equivalent of creative writing, and being a bit different
| for the sake of it. I think I had a Perl book at the time that
| tried to make a serious case for Perl programs being poetry.
|
| I think the culture has just changed since then and most people
| aren't into that any more. People now seem to value one clearer
| way to do everything, and more straightforward terminology. Look
| at the popularity of much more no-nonsense languages these days.
|
| I think unfortunately Perl just now looks deeply unfashionable,
| and I think even the context of why it is the way it is and how
| people saw things back then has sort of been lost so it's
| somewhat hard to explain to younger people in the community.
| dmingod666 wrote:
| Oh, the 'woo' thing was really big in the Ruby on Rails
| community as well.. it was very culty back in the 2000s.
| jiofih wrote:
| I've heard this a few times but never really saw any of that
| creative culture working close to a few Perl folks, besides a
| few funny package names. More a culture of roughness, "hacker
| cred" and a defensive, short-sighted, we-know-better attitude
| that left people stranded and is totally not welcoming to
| creative types. I learned very little during this time.
|
| What you describe is what the Ruby community was in the early
| 2000s.
| chrisseaton wrote:
| My favourite example is the 'bless' function. It attaches a
| class to an object, if people didn't know. I can't imagine
| such a name getting approved in any other language. I think
| any other community would say 'hang on shall we give it a
| descriptive name that anyone can understand without context,
| rather than doing this whole faux-religion schtick that will
| need to be explained to everyone?'
| kqr wrote:
| Programming is filled with weird terminology that only
| means something because we've gotten used to it. String?
| Method? Abstract method? Stack? Sure, there's a weak link
| between pre-existing meanings and the programming one, but
| so is there with bless.
| chrisseaton wrote:
| > String? Method? Abstract method? Stack?
|
| These aren't per-language terms that people have to learn
| just to use Perl, though are they? 'bless' is. A new term
| for something that could have been described so simply as
| 'set-class' or 'give-class' or anything else using plain
| language.
| kqr wrote:
| Well, they do mean slightly different things in different
| languages.
|
| But I suspect "set-class" or "give-class" would be a bit
| cumbersome to trip over every time it happens. A
| relatively core concept should have a relatively short
| name (in the Perl philosophy of working like a natural
| language) so we'd still probably have to find something
| around 5 characters or fewer.
| pansa2 wrote:
| > _deliberately whimsical terminology, puns in their programs_
|
| Python was like this as well, the language is even named after
| a comedy group. Perhaps as the culture has changed, Python has
| done a better job of adapting (e.g. changing the name of the
| "Cheese Shop" to PyPI)?
| marcosdumay wrote:
| As a late coming to Python, was PyPi actually named Cheese
| Shop?! That's great.
|
| But well, I guess once libraries start to actually appear
| there, the name change was unavoidable.
| kstrauser wrote:
| Yep! And a lot of third party stuff was in the Vaults of
| Parnassus.
| emodendroket wrote:
| Not really a mystery why though, is it? Cute and novel ways to
| do things are less charming when you're trying to figure out
| what earth they do well after the fact to solve some problem.
| JulianMorrison wrote:
| I was a Perl coder, it was my first commercial job. I remember
| being excited for Perl 6. But looking back at it in retrospect
| after years, I'd now put it in the category of "languages that
| have a gimmick", something they follow too faithfully because it
| initially seems clever.
|
| Perl's gimmick was "we had this text processing language based on
| linguistics theory, and we hung stuff off the side until it
| became a proper language". What the result was, really, was
| something that went through text like a swiss army chainsaw, but
| was a damn clunky mess doing real language stuff. Even if it was,
| for the time, pretty damn neat in its overall list of features.
| This neatness gradually paled as everything else caught up and
| surpassed it.
|
| Nothing since has changed this. Raku still has the gimmicky feel
| - because that is what defines it as (a) Perl.
|
| There are simply better syntaxes - better, even, nowadays, for
| text processing and sysadmin, where I'd reach for Ruby. And if
| I'm not too fond of Python, at least it's mostly uncomplicated.
|
| I think at this point you can stick a fork in it, the gimmick has
| run its course, it's done.
| dkarl wrote:
| I think it was more than a gimmick. It scaled down brilliantly.
| For people who mastered it, it was an incredibly powerful
| command-line tool, and it worked well enough for small scripts.
|
| It scaled up horribly. It showed its weaknesses in larger
| scripts, and it was gratuitously bad at any scale above that.
| And of course, as a bundle of idioms with no surface coherence
| and no unifying logical principles, it was grotesquely hostile
| to anyone who had not spent a lot of time immersed in it.
|
| But as a tool for command-line wizardry and small-scale
| scripting, for tasks that didn't need to be shared or
| maintained outside the priesthood of sysadmins, it was
| brilliant, and it hasn't been bested or even equaled as far as
| I know. I think the only reason it fell out of favor is that
| you can never be sure that a task won't grow beyond this little
| realm where Perl shines.
| JulianMorrison wrote:
| Ruby is about on a par for one-liners, since it copied a lot
| of Perl's convenience features like auto loops over lines of
| stdin.
| mybrid wrote:
| I think the author is way to generous to the PERL community and
| the drama of PERL 6. I think the toxicity that eventually led to
| Larry Wall bowing out is being replicated in Python and Guido
| leaving. I left PERL for Python in the mid-2000s because it was
| clear with the Parrot engine and other misguided notions by the
| PERL bullies that the PERL leadership was bent. Now that Guido is
| out it will be interesting to see how long Python retains its
| perch. I think the demise of PERL would have been vastly
| different if Larry Wall hadn't been forced out.
| lelanthran wrote:
| That may have played a part, but I feel that a larger problem
| was the line-noise-like syntax.
|
| Right now C++ and Rust appear to be competing to be the next
| Perl WRT hieroglyphics in code. The smug and pointless answer
| to the complaint that the code looks like line-noise is usually
| "whichever language you use, you have to learn the symbols
| anyway".
| avar wrote:
| Larry Wall wasn't forced out of Perl development. He decided on
| his own to stop actively contributing to Perl 5 sometime before
| 2000 and to hand it off to others.
|
| The whole Perl 6 v.s. Perl 5 branding was a source of friction,
| but as far as I know the rebranding of Perl 6 to Raku wasn't in
| any way because Larry was forced to do something. The two
| communities eventually decided that sharing the same name for
| two completely different languages didn't make any sense.
| alexhutcheson wrote:
| Any analysis of Perl's decline that doesn't mention PHP is
| incomplete. Between the height of Perl's popularity in the 90s
| and today, web development was the single biggest growth area,
| and PHP ate Perl's lunch in that domain.
|
| Why did that happen? In my opinion, PHP had two major advantages
| over Perl:
|
| 1. mod_php for Apache could safely be run in a shared hosting
| environment, so hosting for PHP was cheap and ubiquitous.
| mod_perl couldn't be run in shared hosting, so anyone doing web
| development in Perl was stuck with either using CGI, or paying
| for more expensive dedicated hosting.
|
| 2. PHP's approach made it easier to get started for people who
| were new to web development, or new to programming entirely. This
| was important in the late 90s and early 2000s as a huge number of
| people started doing web development for the first time.
|
| By 2000, PHP was already the dominant "scripting language for the
| web". If the Perl community had focused on improving web
| development, then _maybe_ Perl could have caught up, but they
| focused on Perl 6 instead, and PHP continued its growth without
| much serious competition from Perl for web development mindshare.
| MediaWiki was written in PHP in 2002, and both Facebook and
| Wordpress were written in PHP in 2003.
|
| The article focuses on Python, but during the relevant time
| period (roughly 1995-2005) Python was a niche and unorthodox
| choice for web development. Python finally started to gain
| traction for web dev in 2005 (Django, Pylons, TurboGears, and
| web.py were all released that year), but by that point Python was
| mostly competing with PHP, and Perl was already much less
| relevant.
|
| In summary - the article focuses on how Perl lost the market for
| _scripting_ , but scripting was always a smaller and less
| important market than _web development_ , and PHP killed Perl in
| the web development market. If Perl had stayed relevant for web
| development, it likely would have stayed relevant in scripting as
| well, because programmers like to use languages they already know
| (see: JavaScript). Perl 6 was the nail in the coffin that ensured
| Perl wouldn't catch up in the web dev race that it was already
| losing.
| acomjean wrote:
| On PHP 25year birthday Rasmus Lerdorf talked about how php came
| to be. He literally thought something better would replace it
| at all times.
|
| https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les...
|
| I think he thought it would be Perl:
|
| "And Lerdorf tells an only-in-the-1990s story about the day
| when Perl finally also released its own optional embeddable
| module for Apache web servers -- mod_perl. "They'd made it way
| too powerful... If you were on the virtual host on an Apache
| server, and you had mod_perl access, you could steal the
| requests from every other virtual host if you wanted to..."
| Because of this vulnerability, ISPs wouldn't offer mod_perl
| alongside other clients in a single Apache instance.
|
| "So if you came to an ISP and said 'I would like mod_perl',
| they would say, 'Okay, that'll be $600 a month,' because back
| then, we also didn't have VMs, containers, anything like that.
| So you had to have a separate, physical bare metal box for
| mod_perl. Whereas on PHP, you could put 3,000 customers on one
| machine, versus one mod_perl customer."
|
| the 25 year php talk:
| https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s
| pengaru wrote:
| I was a sysadmin through this era, and we refused access to
| both mod_php or mod_perl on shared hosting accounts.
| Customers always received php-cgi.
|
| Even if one could convince themself mod_php was safe, it was
| so unstable version-wise syntactically and every webapp
| wanted its own snowflake combination of version and
| configuration and versions of dependencies like
| imagemagick/gd, it was simply impossible to satisfy all
| customers on a given host sharing a single apache+mod_php
| instance.
|
| By the time I left that role we had what must have been
| nearly 100 different php cgi builds in a global repository
| maintained on behalf of customers. Whenever a vulnerability
| came out we'd have to go revisit all these snowflakes and
| push fixes out. At least the pushing out was mostly automated
| since we had all the hashes, but the maintaining of the
| variously configured source trees and backporting of fixes
| was always a largely manual nuisance. In retrospect we
| spoiled our customers, and I learned PHP was a damn disaster
| area.
|
| At one point we forced all customers to migrate IIRC from
| php3 to php4 and in that transition we learned the previous
| version was ignoring such glaring syntactic problems as
| mismatched curly braces ambiguously delimiting blocks of
| code. What a nightmare that week was, before that we could
| largely ignore the contents of customers' scripts. But with
| so much broken we had to start looking at what they were
| doing and automating counting of open vs. close curly braces
| in php scripts across the fleet. What a horror show.
|
| Edit: forgot to mention shared hosting providers generally
| relied on suexec which only works w/cgi processes anyways.
| Nobody in the shared webhosting space cared about the subtle
| differences of mod_php vs. mod_perl, they were both
| irrelevant to anyone trying to isolate web customers sharing
| a single host.
| agumonkey wrote:
| These two points should be in books because no matter how good
| you are, new market dynamics will eat you alive faster than you
| can blink if you don't address the actual needs.
|
| Think how brittle limited and fuzzy php was for so long, yet
| it's a major thing in IT now.
| cutler wrote:
| Perl 6 wasn't the main factor. In the early/mid-2000s Perl lost
| mindshare because it's PHP equivalent - HTML::Mason - relied on
| mod_perl which cheap hosts were reluctant to offer for many
| reasons. Perl's main web framework, Catalyst, was a beast and
| only a few big companies took it seriously. There was also
| Mojolicious and Dancer but they never hit the big-time either.
|
| Internally the Perl community fought with each other over how
| to implement OO. A Meta Object Protocal (MOP) was hotly
| debtated but the main implementation remained just a library.
| Likewise with Perl's main OO library Moose which spawned
| lightweight offspring such as Moo. TIMTOWTDI became a liability
| as competing scripting languages with built-in OOP (Ruby,
| Python & PHP5) ate Perl's lunch.
|
| Perl also lost a lot of mindshare to Python in the an area it
| had dominated for many years - system administration.
| alexhutcheson wrote:
| Agreed mod_perl was a bigger problem in the critical time
| period than Perl 6. Perl 6 just made it so it was less likely
| anyone would fix the situation.
|
| Catalyst (released 2005), Mojolicious (2008), and Dancer
| (2009) were all released too late to matter.
| kazinator wrote:
| For any X, "PHP ate X's lunch" is going to be very bitter pill
| to swallow for proponents of X. :)
| karmakaze wrote:
| I know both Python and PHP had numerous successful and
| moderately successful web frameworks. I don't know what it was
| like with Perl, was it still much more roll your own custom set
| for each app from libraries?
| tyingq wrote:
| Excellent point. For the same reason, Ruby/Rails is worth
| mentioning too. The article does mention Ruby, but not Rails.
| alexhutcheson wrote:
| Rails didn't really pick up until 2005 either, by which point
| Perl had already faded considerably.
|
| The most interesting counterfactual is "What if someone had
| written something like Rails for Perl before 2005?" It was
| definitely technically possible, and it might have made Perl
| take back off (Ruby usage grew from basically nothing due to
| Rails), but the community's focus on Perl 6 at the time made
| it much less likely.
| cutler wrote:
| Perl had Mojolicious which was almost as good as Rails and
| a lumbering beast called Catalyst which was used at the
| BBC.
| alexhutcheson wrote:
| Mojolicious wasn't released until 2008, by which point
| Rails and Django had both been available for >3 years.
|
| Catalyst was released in 2005 (so still after Rails), and
| definitely didn't provide Rails-like productivity.
|
| If Mojolicious had been available in ~2003 or earlier,
| it's entirely possible Ruby never takes off, because
| developers could get similar productivity in a more
| "known"/"mainstream" language.
| spookthesunset wrote:
| I agree with this. Deployment of Perl was a pain in the ass.
| With PHP you literally just FTP'd the files to your normal web
| directory and you were off to the races.
|
| Even today PHP still has that advantage over many other
| languages. To my knowledge even now you can't just upload a
| bundle of .py, .rb or .jar files into a directory hosted by
| Apache and go.
|
| That being said these days the other languages become their own
| http server and are usually fronted by a reverse proxy or two.
| But still that is like an order of magnitude harder to stand up
| than PHP.
| tyingq wrote:
| You can set up such that newly uploaded Perl, Python, etc,
| scripts are runnable as soon as you put them there. But,
| typically, you're using a template framework or other
| dependencies and don't want those things exposed to the web
| server. PHP initially worked well that way because you lumped
| your templates and code into one file.
| Evidlo wrote:
| > To my knowledge even now you can't just upload a bundle of
| .py, .rb or .jar files into a directory hosted by Apache and
| go.
|
| Doesn't that just depend on Apache settings? You can set up
| Apache to serve all requests ending in .py as CGI. As long as
| these scripts emit HTML the situation is the same as PHP.
| luckylion wrote:
| Kind of. The files need to be executable and need to have a
| valid Shebang. That was a common issue with Perl when
| developers uploaded from Windows, because the Shebang was
| now "/usr/bin/perl\r". ASCII mode FTP mitigated that, but
| was itself a terrible idea. Passing flags to Perl
| ("/usr/bin/perl -w") or putting env into it ("/usr/bin/env
| perl") usually helped.
|
| Chmod'ing over FTP isn't straight forward in most clients,
| so it was much more complicated for beginners to get things
| to run than "upload those files, go to your browser".
| darrenf wrote:
| Small nitpick: it doesn't, and never had to be, HTML that
| was emitted. Executables were/are responsible for headers
| (including `Content-type`) as well as the body.
| shagie wrote:
| An example of this was the old, classic, counter.cgi
| which, when accessed would:
|
| * Read a file containing an integer
|
| * Increment the integer in memory
|
| * Emit a .gif with the new value
|
| * Write the new value back to the file
| anyfoo wrote:
| That's a bad order to do things, is that how it worked?
|
| There is a huge window while emitting the .gif during
| which other visitors may appear. At best a new visitor
| appearing during another visitor's "emit gif" phase does
| not increment the counter, at worst a visitor on a very
| slow line causes the cgi instance for this visitor to run
| for a long time and then write back a very old value to
| the file, making the counter run _backwards_.
|
| For things that matter, the counter reading+increasing
| should be an atomic read-modify-write. But since this is
| just a web counter, I guess it's sufficient if you at
| least keep the hazardous window very small (by not doing
| the write-back at the end).
| spookthesunset wrote:
| I mean, these were slapped onto peoples personal pages
| right below an animated "under construction" gif and
| fractal looking background images. Accuracy was not a
| huge concern.
| yjftsjthsd-h wrote:
| For this case, eventually consistent is good enough
| dredmorbius wrote:
| If you're not locking the counter whilst reading,
| incrementing, applying, and updating it, what you're
| eventually getting ... isn't really consistency.
|
| "A widely shared myth" would be more accurate.
| anyfoo wrote:
| Yeah, the "it's just a web counter, so maybe just keep
| the window small" suggestion I made in the end was not
| meant to say that this provides _any_ consistency, just
| that it keeps the underestimation of actual visitors
| smaller.
|
| By the way, I'm totally aware that those counters didn't
| matter, but I thought it's worth discussing anyway.
| Someone might read this and apply it to things that
| matter.
| guidoism wrote:
| Heh yeah. It didn't matter because there weren't that
| many people hitting the pages. It was more of a thing to
| do that was cool because when it hit like a thousand you
| would be like "OMG a THOUSAND people all over the world
| have visited my page, what a world we live in"
| c0achmcguirk wrote:
| And dynamic--anything dynamic--was completely insanely
| cool.
| shagie wrote:
| Back in days of old, I would upload a bunch of perl files
| into the cgi-bin directory for the server... or files that
| ended in .cgi into wherever in the htdocs directory.
|
| With some juggling of what the script that was the .cgi, it
| would have been trivial to make it launch Java and consume
| the data... but Java wasn't set up for that (and the startup
| times for a Java cgi would have been nightmarish).
| tres wrote:
| Totally agree on point 2.
|
| PHP's documentation was always excellent, available and was
| always a quick Google search away from finding the relevant
| materials. It was tangibly superior at the time.
|
| Coding with other languages at the time always involved some
| kind of physical reference book (or some closed off "compiled"
| walled "context sensitive" help system whose search capability
| and discoverability was little-to-none).
|
| Although I had sooo many O'Reilly reference books, I don't
| think I ever had an O'Reilly PHP reference book... (Not sure
| there ever even was one because it would be totally
| unnecessary)
| rav wrote:
| PHP's documentation is still excellent and is still available
| at the same place it was 20 years ago: Typing
| php.net/FUNCNAME in the address bar gives the documentation
| for FUNCNAME(). I'm glad my current work is only about 1% PHP
| and not the 100% it used to be, but whenever I need to edit
| one of those PHP scripts we still have around, I know how to
| get by, even though I'm seriously rusty.
| cutler wrote:
| Sklar's "PHP Cookbook" was an O'Reilly favourite, now in it's
| 3rd edition.
| xnx wrote:
| This is exactly right and a story we see over and over again. A
| mature high-quality incumbent is defeated by an upstart that's
| inferior in all dimensions except the one that ends up
| mattering the most.
|
| At launch Google Sheets was worse than Excel in so many ways,
| but the online collaboration made it 10x better for all but the
| most specialized users.
|
| Imagine how different things would be in the alternate reality
| where the server-side JavaScript support of Netscape Server
| morphed into a mod_javascript module for Apache.
| ff317 wrote:
| There are many valid perspectives and issues on the decline of
| Perl, many of which are valid, but I'll add my own about the
| perceptions (as an ancient Perl coder who has mostly moved on) of
| Perl code being pretty messy and unmaintainable on average:
|
| I think Perl has always been an artist's tool, rather than an
| industrial tool, and this is why so much Perl code in the world
| is a relatively-unreadable mess. It grants great artistic license
| (which was also the name of its software license!) to the coder,
| as evinced by the Perl community motto TIMTOWTDI (
| https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...
| ). In the hands of an expert working on a labor of love, flexible
| artistic tooling allow maximal freedom and craftsmanship to
| create truly great things. But in the hands of novices, or even
| experienced professionals who are tasked with just getting
| something functional done on a deadline, there's little in the
| way of guardrails pushing the solution towards elegance,
| simplicity, and readability.
|
| Most coding work that is ever done is more industrial and task-
| focused in nature, and artistic tools aren't always really the
| right tools for that job. By way of analogy: Let's say in an
| industrial setting a manager decides that a new, large, safety
| warning placard needs to be created to warn employees about
| slipping on the wet floor of the factory. The manager could task
| an employee to go pick a standard "Wet Floor" sign from a catalog
| and order it, or she could decide we need a custom message and
| ask someone to contract with a signage company, or even in a
| pinch she could decide to hand someone a big square of plastic,
| some white paint, and a set of letter stencils to go make a sign
| with. She might even cite some ANSI standards the sign has to
| comply with about font sizes and colors for warning signs of this
| nature.
|
| What she'd never rationally do in this scenario, is just hand
| them a gift card to an art supply house and a tab of acid and
| tell them to go be creative, which is probably the closest thing
| to the Perl way to go about the problem. Nonetheless, Perl has
| value and merit, and is a beautiful thing.
| nige123 wrote:
| Sigils can induce fear in some programmers. The double-edged
| sword of Perl and Raku's expressivity is something that the
| community is addressing:
|
| https://raku-advent.blog/2020/12/02/day-1-perl-is-dead-long-...
| codesnik wrote:
| I started to make money writing in perl when it was long on
| decline already, in 2005-2007. I've switched to ruby after that.
| It's not widely known, but perl had a lot of influence on ruby,
| in much cleaner syntax and without baggage of text-only-
| processing scripts of early 1980-es
| brightball wrote:
| I'm glad I learned Perl before the big decline started. Just
| having the Perl experience with Regex altered my perspective on
| the language as a whole.
|
| Even though I miss it, it's hard to justify using Perl for much
| these days other than the "it's everywhere by default" reason in
| enterprise Sys admin environments.
| tzmudzin wrote:
| IMHO the biggest issue that blocked Perl's broader adoption was
| the really obfuscated handling of nested data structures
| including objects. Anything beyond array of arrays or hash of
| hashes was a pain. It was and it still is way superior to Python
| for hacking of flat files, but once you needed to go beyond a
| hash the pain was real.
|
| That was 20+ years ago, and Python filled this space with its
| easy definition of classes and candy syntax. Where Perl overdid
| on hackery, Python may have overdone on sugar -- but it clearly
| won the love of the masses.
|
| Now, 25 years later, the ship has probably sailed for Perl, and
| -- while I still prefer it to sed/grep/awk and Python for simpler
| tasks, I don't see it conquering Python space for more
| complicated processing.
| cafard wrote:
| The last real job I did with Perl was just over nine years ago.
| HTML::TreeBuilder saved just hours, probably weeks, of
| frustrating work during a web platform transition.
|
| I think that you are right about the nested data structures. I
| was favorably impressed by the little I saw of Moose, but by
| the time that came along, all the young seemed to know Python
| and not Perl.
|
| It is not just flat files Perl handles nicely, either. One can
| do fixed-format munging in Python via the struct module, but
| I've never found it as handy as Perl's pack/unpack, something I
| used as far back as the Perl 4 days.
| p0nce wrote:
| Exactly. Perl is hardly readable, difficult to understand, and
| simple things (like parsing a XML) becomes difficult in Perl.
| daotoad wrote:
| How were you parsing XML? I've never found it to be a
| difficult task.
|
| XML::LibXML is a nice wrapper around libXML.
|
| XML::Twig is great if you need to process huge files.
|
| XML::Rabbit will seamlessly map your XML into objects.
|
| There are things to criticise Perl for, like idiosyncratic
| argument handling in subroutines or the use of weird
| punctuation variables, but to call out XML parsing as
| particularly hard is questionable.
|
| Take a look at this example from
| https://grantm.github.io/perl-libxml-by-example/basics.html
| use XML::LibXML; my $filename = 'playlist.xml';
| my $dom = XML::LibXML->load_xml(location => $filename);
| foreach my $title ($dom->findnodes('/playlist/movie/title'))
| { say $title->to_literal(); }
|
| How is that particularly difficult?
| arunix wrote:
| What does "really obfuscated handling of nested data
| structures" mean? Can you give an example?
| luckylion wrote:
| Probably dereferencing, since Perl never had multidimensional
| datastructures. You'd put a reference to an array into an
| array value, and then access it with $array[0]->[0] (iirc) to
| get the first value of the first array. That was the easy way
| to write it, the much more annoying way was like
| ${$array[0]}[0] (or $$array[0][0] if you really wanted to? my
| memory is fortunately fading), I believe, which got really
| out of hand when you went three or more levels deep.
| kqr wrote:
| The syntax for accessing nested indices actually
| automatically resolves references the way you'd expect. So
| for the specific case of accessing a single deeply nested
| value, no special incantation is needed.
| tyingq wrote:
| Perl has sigils for different data types.
| $foo="bar"; #scalar/string %hash = { "key" => "value",
| "key2" => "val2" }; #hashmap @arr = ( 1, 2, "three",
| 4); #array
|
| But, it also has references, like pointers.
| $array_ref=\@somearray; # array ref
| $hash_ref=\%somehash; # hash ref
| $scalar_ref=\$some_scalar; # scalar ref
|
| So, you can put scalars into arrays and hashes, refs into
| hashes and arrays, etc, etc. At whatever nested depth you
| want. But you have to extract pieces later. And Perl, as
| usual, allows a zillion ways to do it. These are all exactly
| the same thing: $$arrayref[0] = "data";
| ${$arrayref}[0] = "data"; $arrayref->[0] = "data";
|
| So imagine you need to extract a string that's at the bottom
| of some data structure. Here's an example:
| @IP = ('192.168.1.10','192.168.1.15'); @PORT =
| ("5000","5002"); @TCP = ("Q931","H225","H245");
| @LAYER = ("ETHERNET","IP",\@TCP); @PKT = (
| \@IP, \@PORT, \@LAYER
| ); $array_ref = \@PKT;
|
| I can extract something using different approaches, like:
| ${${${$array_ref}[2]}[2]}[1];# oof! # same
| result, looks better, but imagine # we put a hash in
| the data structure, or # had deeper structures
| $array_ref->[2]->[2]->[1];
| tripa wrote:
| Or just the simple $array_ref->[2][2][1];
| tyingq wrote:
| Yes, perhaps I shouldn't have gone with just nested
| arrays/arrayrefs :)
|
| Here's a modified example where it's not as clear how to
| deref.
|
| Like: @IP =
| ('192.168.1.10','192.168.1.15'); @PORT =
| ("5000","5002"); @TCP = ("Q931","H225","H245");
| %TAGS = (L2 =>"ETHERNET",L3=>"IP",L4=>\@TCP); @PKT
| = ( \@IP, \@PORT, \%TAGS); $array_ref=\@PKT;
| print $array_ref->[2]{L4}[0];# this works print
| $$array_ref[2]{L4}[0]; # this works print
| $array_ref[2]{L4}[0]; # this doesn't
| u801e wrote:
| > IMHO the biggest issue that blocked Perl's broader adoption
| was the really obfuscated handling of nested data structures
| including objects. Anything beyond array of arrays or hash of
| hashes was a pain.
|
| How was it a pain specifically? If you used references, then
| defining an arbitrary data structure shouldn't be an issue and
| accessing individual elements would be a matter of prefixing
| the reference with the appropriate sigil.
|
| In python, you need to be aware of when you're making a copy of
| an element in a data structure rather than getting a reference
| of that element. In perl, you would know based on syntax
| whether you're dealing with a reference as opposed to a copy of
| an instance.
| HeckFeck wrote:
| > In perl, you would know based on syntax whether you're
| dealing with a reference as opposed to a copy of an instance.
|
| Once you 'get' the sigils in Perl, you miss them everywhere
| else.
| gh-throw wrote:
| They're kinda just a barely-there static-typing system, but
| damned if that's not way better than none. And if one
| recalls that monochrome screens used to be a thing, and
| that syntax highlighting was wonky (because shortcutted to
| be usable on weak hardware) and/or too computationally
| expensive for computers for a while after that, one
| _really_ understands the appeal of the sigils. Perl is one
| of the most notepad-friendly languages around.
|
| PHP's weird half-assed copy of the sigil system ($ only,
| for everything) is one of my least-favorite things about it
| (but I don't really hate PHP the way some people do, so
| that may not be saying much).
|
| $, %, and @ are why using complex multi-dimensional arrays
| & associative arrays in Perl is non-crazymaking. You can at
| least state the kind of thing you're _intending_ to use at
| each layer of the array, and have that intention readable
| even when syntax highlighting isn 't available, which is a
| lot better than nothing.
| hnfong wrote:
| Isn't that just a half-assed mandatory Hungarian-notation
| system? :-/
|
| I mean, sure, in Perl the language "casts" the value into
| an appropriate type for you, but only in a few select
| cases..
| emodendroket wrote:
| Well, making it enforced by the runtime answers at least
| one obvious objection to Hungarian notation.
| daotoad wrote:
| It is pretty similar to Hungarian notation, but it also
| denotes context. But is it half-assed? I'm not sure. It
| expresses the type of the variable over a very narrow set
| of types. If anything you could say that the type system
| is half-assed. I've thought a lot about this over the
| years and I have come to believe that it is really a
| minimal type set that offers an incredibly useful set of
| abstractions.
|
| For me, the main advantages of sigils are that I can
| immediately see if I am looking at a variable or a
| function name and that the sigil effectively separates
| the name spaces between functions and variables. This has
| the side effect of making it easy to distinguish
| functions that have been passed in as variables from
| functions declared or imported into the particular scope.
|
| Even with a nice IDE I miss the distinction that the
| sigils provide.
| BGZq7 wrote:
| Yes, I definitely miss this in Ruby since it also has
| optional parens for method calls but lacks sigils. Even
| the most basic-looking expressions can have arbitrarily
| complicated meanings: foo.bar = 1
|
| Is that just an attribute set on an object, is it calling
| a method foo that returns an object containing a bar
| attribute with a normal getter/setter, or is bar= a
| method that has arbitrary functionality?
|
| I also like the more explicit operators in Perl that help
| show context: $foo + $bar
|
| This is specifically numeric addition and those operands
| are probably at least somewhat number-like. Yes you can
| potentially overload it, but by convention, it will still
| be something like addition, so you don't have to wonder
| if you are adding, concatenating, appending a list, or
| something else, because they have different operators.
| gh-throw wrote:
| Yeah, I mean more in the information it carries for the
| human reader than its effect on how the machine sees it.
| Diederich wrote:
| > really obfuscated handling of nested data structures
| including objects
|
| Can you expand on that a bit? Are you talking about how Perl5's
| variable sigils?
| marbu wrote:
| The issue with nested structures is a good point.
|
| Another problem I noticed would be natural language like syntax
| sugar, which makes it harder to maintain your knowledge of the
| language if you don't use it regularly. I learned some perl
| long time ago during one project, and after I stopped working
| with the project, I also gradually stopped using perl for quick
| scripts, and settled on sed/grep/awk again for quick simple
| stuff, and python for the other tasks.
| Tepix wrote:
| I think they lost it with Perl 6. Perl 6 was a bit late, but it
| could have been a better rejuvenation for Perl than Python 3
| was for Python.
|
| Instead it took way too long, had confusing naming with the
| various implementations and frankly some features that are not
| very useful for anyone but linguists. I mean, why would you
| want to redefine your language from within the language? To
| confuse your co-workers? To win the obfuscated perl contest?
|
| Perl 6 also has some real innovation like its new regular
| expressions. I'm afraid they will never get widely adopted.
|
| FWIW i never had a problem with nested data structures in perl.
| I found the perl documentation ("perldoc perldata") to be
| fantastic.
| lizmat wrote:
| Please note that Perl 6 is no longer a thing: it has been
| renamed to the Raku Programming Language (https://raku.org).
| If you want to stay up-to-date, you can check out the Rakudo
| Weekly News at https://rakudoweekly.blog
| arglebargle69 wrote:
| This is precisely the problem
| tsjq wrote:
| Hahaa. So true
| kqr wrote:
| This was the problem. It's now been fixed. Or do you
| think Perl 6 was the more meaningful name?
| dbt00 wrote:
| The problem isn't that all this happened, or maybe that
| is the problem, the problem is that the future of Perl
| was very confusing for a very long time.
|
| Python 3 was announced in 2006, committed to as the
| future in 2008, and the last significant release of
| Python 2 was in 2010. There was a hard deprecation
| deadline of the Python 2 in 2015, which was postponed in
| 2014 to 2020. It wasn't fantastic and there was some pain
| and some poor decisions but everybody knew where the
| language was going and how to stay in front of it.
|
| Perl 6 was announced in 2000 and there were only 2
| releases of Perl 5 for 7 years. Then in the 2007-2010
| timeframe regular releases of Perl 5 resumed. Eventually
| everyone kind of realized that Perl6 was DOA as the next
| major release of Perl, but that process happened
| gradually over the course of nearly 20 years, by which
| time most of the rest of the world had written off Perl
| as a significant entity.
| znpy wrote:
| Eh, it sorta still is? Not really, but if you spent ten
| years announcing an upcoming perl6, then you rename it to
| Raku... There will be confusion, at least.
| emodendroket wrote:
| Not just confusion. If you hype it up as the future and
| then drop it how excited are people really going to get
| for the old stuff?
| lizmat wrote:
| Perl 6 was released in December 2015. A little under 4
| years later, it was renamed to Raku. Plenty of time to
| not be confused.
| coldpie wrote:
| I'm not in the Perl world. I have heard of Perl 6 and
| know what it is. I've never heard of Raku before this
| thread. "perl6" and "perl 6" together have 58 matches on
| this page right now (before my comment). Raku has 28.
| DonHopkins wrote:
| They should have done what the YAML designers did when
| they suddenly realized to their great surprise that the
| language they themselves designed and named was NOT
| actually a markup language:
|
| Keep the exact same name and a perfectly straight face,
| then recursively retronymonically redefine it to mean
| something completely different: the opposite of what it
| initially meant!
|
| "Yet Another Markup Language" => "YAML Ain't Markup
| Language"
|
| So "PERL 5" is to "Practical Extraction and Reporting
| Language 6", as "PERL 6" is a "PERL E___ R___ L___ 6".
|
| (Pattern matching and filling in the blanks is left as an
| exercise for GTP-3.)
| Doctor_Fegg wrote:
| Programmers Embraced Rasmus Lerdorf?
| lostapathy wrote:
| Perl 6 wasn't "a bit late" - the path forward meandered for
| years, so the point even diehard perl fans (me, at the time)
| questioned whether it could/would ever happen. And as pointed
| out down thread, the branding completely changed at least
| once or twice along the way, to the point perl fans of 20
| years ago don't even know "perl 6" became something else
| today.
| smitty1e wrote:
| I was at the point of deciding whether to focus on Perl or
| Python when there was the 01Apr "Parrot" gag on Slashdot.
| This was a couple of decades back.
|
| Then Larry Wall announced Perl6 and focusing on Python while
| awaiting P6 was an easy call.
| [deleted]
| andi999 wrote:
| To me it was the documentation. Whenever I tried to get into
| it, I only came across books/tutorials(I dont remember) which
| start with, oh pearl, here are regular expressions. And then a
| very very unstructured heuristical explanation of regular
| expressions. Usually gave up at that point.
| Tepix wrote:
| Perl's documentation is/was fantastic. On top of it there
| were some of the best books that covered it.
| ptspts wrote:
| I've learnt Perl from the man pages. They are interesting and
| insightful.
| gerikson wrote:
| The official Perl documentation is quite good, in my humble
| opinion.
| spookthesunset wrote:
| > IMHO the biggest issue that blocked Perl's broader adoption
| was the really obfuscated handling of nested data structures
| including objects
|
| Oh man did we ever abuse the shit out of the loosy-goosy data
| structures you could make in perl. Almost any time you needed
| to debug or trace something, you'd pretty print the entire data
| structure you were passing around. Some of those suckers would
| be _huge_ and you 'd be passing that structure around to almost
| everything in your codebase!
|
| As an outsider it might appear scary and a massive code
| smell... but when you worked on that codebase it just kinda all
| made sense somehow. It was just how perl programs rolled.
|
| I have yet to work in any other language that let you use and
| abuse the native data structures quite like you could in Perl.
| cutler wrote:
| How are Perl's arrays and hashes any different from those in
| Python (lists & dicts), Ruby or Javascript in terms of
| practical usage?
| philote wrote:
| Other than Perl's autovivification I'm not sure there's
| really a big difference.
| stinos wrote:
| _Where Perl overdid on hackery, Python may have overdone on
| sugar_
|
| Haven't used Perl often, but that's sort of my impression as
| well. And that Python sugar feels mostly pretty well reasoned
| about. And fairly usable and readable as well. Whereas in Perl
| I sometimes had the impression a bunch of people with CS
| degrees made something they thought out while on LSD and just
| decided to add it. Cool at the moment, but not too usable by
| sober minds afterwards.
| DonHopkins wrote:
| Hey, HyperCard was designed under the influence of LSD, and
| it came out pretty good!
|
| https://news.ycombinator.com/item?id=24083738
|
| https://www.mondo2000.com/2018/06/18/the-inspiration-for-
| hyp...
|
| "In 1985 I swallowed a tiny fleck of gelatin containing a
| medium dose of LSD, and I spent most of the night sitting on
| a concrete park bench outside my home in Los Gatos,
| California." -Bill Atkinson
| kqr wrote:
| As you probably know, contrary to almost every other language
| out there, Perl was _not_ designed by people with CS degrees
| adding things that sound cool.
|
| Perl was designed by a linguist along the principles of "what
| would English look like if it was a programming language?"
|
| Not in the superficial syntactic sense, but the underlying
| grammar. What is the implicit "it"? What can we derive from
| context and decision so we don't have to spell it out? And so
| on.
|
| This makes it very convenient to express common things in
| different ways (just like English, there is no one true way
| to say something) but it also creates some peculiar
| constructs that make sense but you'd go "who _says_ this? "
| (again, much like in English.)
| joe_the_user wrote:
| I think Larry Wall's theory of language development is
| interesting and the long term failure of Perl shows
| interesting ways in which computer language development and
| natural language development are rather different.
|
| 1) Natural language doesn't have to worry about backward
| compatibility in the same way. The exact meaning of older
| phrases don't have to coexist with those of new phrases.
|
| 2) Natural language doesn't have to recruit new users in
| the same way. I think Spanish is one of the easiest
| commonly spoken languages - if a random person speaking no
| commonly-spoken-in-the-world language had to choose
| languages, Spanish would be ideal. English is weird in
| saying things with idioms, Chinese has tones and complex
| characters, etc. English has evolved in a perl-like fashion
| and if it was a programming
|
| 3) No children learn perl or any programming language as
| their "first language". Everyone learning perl had to wade
| through it's modes and variable names like "_" and
| translate them to their internal concept language. (should
| add: verbs like "be", "do", "have" etc are very fuzzy in
| English as well as proposition "like" "to", "from", at etc
| but this fuzziness is incorporated as a person learns the
| language. But adding an equivalent weirdness to a language
| someone is just learning isn't necessarily going to be
| appreciated).
|
| 4) Communicating with other humans is arguably a key
| function of computer languages as well as natural
| languages. But computer language do also have to
| communicate exact to descriptions to the very dumb devices
| known as computers. So "getting the gist" and "getting it
| exactly" have to be somewhat close and makes "there's more
| than one way to do things" more problematic, especially as
| ways to do things multiply.
| cutler wrote:
| It also means you have to grok the language to reap the
| benefits. Perl is often judged harshly by those who
| prioritise ease of use for beginners over linguistic
| elegance and usefulness. Can you imagine going to China and
| complaining that Mandarin and Cantonese suck because
| they're not beginner-friendly or that medicine is a
| pointless practice because it involves learning many
| complex terms? I've never understood the "Python for
| readability" mantra.
| twic wrote:
| > This makes it very convenient to express common things in
| different ways
|
| This story has been told for decades, but it just isn't
| true. _What_ is particularly convenient to express in Perl?
| The only thing i can think of is the implicit use of $_.
| Everything else is no better than or worse than in a more
| conventional language.
| wahern wrote:
| There are a ton of hacks in the Perl parser and
| interpreter that use context to support otherwise
| irregular syntax. For example, autovivification:
| https://en.wikipedia.org/wiki/Autovivification DWIM is
| the goal behind TMTOWTDI.
|
| Things like sigil's are useful in this regard because
| they provide hints that allow extending the language w/
| irregular syntax, like with autovivification. Perl wasn't
| designed; it slowly accreted features as use cases
| emerged, moderated by implementation constraints, and
| that was intentional.
|
| Python code today is nowhere near as simple as 20 years
| ago. Python, Java, and similarly aged languages are
| ending up w/ a cornucopia of mismatched language syntax
| and semantics much like Perl, except Perl was never blind
| to the inevitable. Lua is one of the few exceptions, but
| that's because Lua has gone through a couple top-down
| redesigns in addition to its more regular backward
| compatibility breaks.
| DonHopkins wrote:
| Ok, then if not actually designed under the influence of
| LSD, then certainly under the influence of religious
| fanaticism.
|
| The tired old "Perl was designed by a linguist" cliche is
| endlessly Parroted (pardon the pun!), but doesn't actually
| necessitate or imply good programming language design. But
| look at the actual factual source of that folklore -- it
| would be more accurate to say "Perl was designed by a
| wanna-be missionary", and that certainly shows ("Exegesis",
| "Apocalypse", "bless", etc):
|
| https://en.wikipedia.org/wiki/Larry_Wall
|
| >While in graduate school at the University of California,
| Berkeley, Wall and his wife were studying linguistics with
| the intention of finding an unwritten language, perhaps in
| Africa, and creating a writing system for it. They would
| then use this new writing system to translate various texts
| into the language, among them the Bible. Due to health
| reasons these plans were cancelled, and they remained in
| the United States, where Wall instead joined the NASA Jet
| Propulsion Laboratory after he finished graduate school.
| Wall is an active member of the New Life, Church of the
| Nazarene.
|
| Going on a missionary expedition in Africa to invent and
| teach illiterate people of color a written language to read
| the Bible in certainly sounds to me more like religious and
| linguistic imperialism than a sound motivation for
| programming language design.
|
| https://en.wikipedia.org/wiki/Linguistic_imperialism
|
| >Linguistic imperialism or language imperialism is
| occasionally defined as "the transfer of a dominant
| language to other people". This language "transfer" (or
| rather unilateral imposition) comes about because of
| imperialism. The transfer is considered to be a sign of
| power; traditionally military power but also, in the modern
| world, economic power. Aspects of the dominant culture are
| usually transferred along with the language.
|
| Translating CS literary classics like the "Pascal Users
| Manual and Report" and Anders Hejlsberg's "Turbo Pascal
| Reference Manual", or even textbooks about sustainable
| farming techniques, nutrition, medicine, sex ed, and birth
| control, into their invented written language would do more
| economic and life sustaining good for those poor Africans
| than translating the Bible.
|
| kqr> "people with CS degrees adding things that sound cool"
|
| People with CS degrees add cool things that are sound, not
| things that sound cool.
|
| Do you really believe that programming languages should be
| intentionally designed to be MORE like religions, MORE
| imperialistic, MORE evangelical, instead of less?
|
| Compare Larry Wall's contributions to this otherwise deep
| fascinating conversation about language design, versus the
| contributions of less religiously motivated, more
| scientifically trained programming language creators with
| CS degrees, like Guido van Rossum, James Gosling, and
| Anders Hejlsberg:
|
| A Language Creators' Conversation: Guido van Rossum, James
| Gosling, Larry Wall & Anders Hejlsberg
|
| https://news.ycombinator.com/item?id=19568378
|
| https://www.youtube.com/watch?v=csL8DLXGNlU&t=49m41s
|
| James was literally taken aback by Larry's macho IDE
| shaming:
|
| https://news.ycombinator.com/item?id=19568381
|
| "I think IDEs make language developers lazy." -Larry Wall
|
| "IDEs let me get a lot more done a lot faster. I mean I'm
| not -- I -- I -- I -- I -- I'm really not into proving my
| manhood. I'm into getting things done." -James Gosling
| cat199 wrote:
| So, picking a few religious-themed keywords out of a hat,
| and using this + non programming interests as a strawman
| basis to attack the whole language as designed by
| 'religious fanaticism' ? If I have to pick the
| 'superstitious' side, it would be the side of this
| argument.
|
| This isn't 'Temple OS'. By this line of reasoning we
| should all only use strongly-typed FP since it's the only
| 'rational enough' language family.
| useragent86 wrote:
| This bigoted, anti-religion, ad-hominem ranting would
| result in a stern chastisement, or even an outright ban
| by dang for "ideological flamewar" were it not posted by
| a user with 14k karma points. And it's far from the only
| such comment DonHopkins has made on HN (he even continues
| by quoting Wikipedia rants about "Christian colonialism":
| https://news.ycombinator.com/item?id=26660365).
|
| Yet HN mods have the gall to claim that "reflexive,"
| combative commenting is not allowed, and "reflective,"
| truth-seeking comments are what's required:
| https://news.ycombinator.com/item?id=26548649
|
| Clearly, certain users are allowed to say whatever they
| want on HN. If HN were honest, it would go ahead and give
| them orange checkmarks.
|
| It would also not be allowed if it were against any
| religion other than Christianity.
| gjm11 wrote:
| Let's stipulate that Larry Wall is a religious fanatic
| (though I think that's only true if you use the word
| "fanatic" in a highly nonstandard way). So what? What
| actual impact has that had on the design of Perl? What
| features of Perl's design are worse as a result of Larry
| Wall's religious beliefs or practices? I don't see any
| sign that _any_ are.
|
| (You mention exactly one thing about Perl's design,
| namely the "bless" keyword. That's a bit quirky, but it's
| not a terrible name for what it does and nothing
| obviously better occurs to me.)
|
| > Going on a missionary expedition [...] sounds to me
| more like [...] than a sound motivation for programming
| language design.
|
| In what way were Larry Wall's missionary ambitions a
| "motivation for programming language design" at all? I
| don't see any sign that they were.
|
| (I do remember, from many years ago, something in Perl's
| licence or readme file along the lines of "I make Perl
| because I think it pleases the Author of my story. If you
| have a problem with that, your notion of Authorship needs
| some revision :-)", but I think that means not "I wrote
| Perl to help me convert the heathen" but "Everything I do
| is for the greater glory of God". So far as I can see,
| that doesn't imply any particular language-design
| choices.)
|
| [EDITED to add: I looked it up. The above doesn't
| misquote too badly, but one place where it diverges from
| the original is that he actually wrote "nice things like
| this", not "Perl" specifically. I think this makes it
| even clearer that _the Perl language design_ as such is
| not what LW is saying was religiously motivated. You can
| find the actual text at https://github.com/Perl/perl5 if
| you care.]
|
| I listened to as much as I could bear to of that language
| design conversation. (The audio is _incredibly_ bad for
| almost all of it, unfortunately.) I didn 't notice Larry
| Wall's contributions being notably less insightful, more
| dogmatic, more ignorant, or whatever it is you're
| gesturing towards. The one example you give is that Larry
| Wall doesn't like IDEs and James Gosling does, which
| doesn't seem like good evidence of anything.
|
| So, please, if you're going to make this sort of claim,
| make it explicit enough to engage with properly. _What_
| about Perl is the way it is becaues of Larry 's
| "religious fanaticism"?
|
| (As it happens I'm an atheist and don't like Perl very
| much. There's plenty I dislike a lot about both
| Christianity and Perl. It's the alleged _connection_ you
| 're trying to draw between them that I don't see at all.)
| emodendroket wrote:
| I think this is a silly line of inquiry at best, but if
| one were to attempt to take it seriously, surely "there
| is precisely one way to do it" is an approach that would
| better fit the "imperialist" frame than Perl's actual
| approach.
| DonHopkins wrote:
| Which Imperialistic Programming Language dictates that
| "there is precisely one way to do it"?
|
| Not Python -- it has Zen-like practical suggestions about
| what matters, instead of ideological doctrine about how
| to do it:
|
| https://www.python.org/dev/peps/pep-0020/
|
| >There should be one-- and preferably only one --obvious
| way to do it.
|
| >Although that way may not be obvious at first unless
| you're Dutch.
|
| Does The Zen of Python really sound "imperialistic" to
| you? The Zen of Python
| Beautiful is better than ugly. Explicit is better
| than implicit. Simple is better than complex.
| Complex is better than complicated. Flat is
| better than nested. Sparse is better than dense.
| Readability counts. Special cases aren't special
| enough to break the rules. Although practicality
| beats purity. Errors should never pass silently.
| Unless explicitly silenced. In the face of
| ambiguity, refuse the temptation to guess. There
| should be one-- and preferably only one --obvious way to
| do it. Although that way may not be obvious at
| first unless you're Dutch. Now is better than
| never. Although never is often better than
| *right* now. If the implementation is hard to
| explain, it's a bad idea. If the implementation
| is easy to explain, it may be a good idea.
| Namespaces are one honking great idea -- let's do more of
| those!
| DharmaPolice wrote:
| > There should be one-- and preferably only one --obvious
| way to do it.
|
| This always felt like an excessive over-reaction to
| Perl's "there's more than one way to do it" motto and
| never struck me as desirable or true.
|
| In the earlier days of Python I remember reading
| StackOverflow questions which attracted differing
| solutions and Python advocates (who were a bit abrasive
| at the time) would reconcile this with the above by
| saying some answers weren't sufficiently "pythonic". It
| all seemed rather strange.
| emodendroket wrote:
| I think this is pretty common though. Most language
| communities converge on some standard way of doing
| things. I always try to go along with the philosophy of
| the language I'm working in, even if I wouldn't
| necessarily choose that myself from a blank slate.
| emodendroket wrote:
| Not exactly but I think the idea that Perl (or for that
| matter Christianity) is imperialistic is itself absurd,
| so that doesn't seem like an answer.
|
| Anyway, the closest I've experienced is Go, to answer
| your question.
| DonHopkins wrote:
| Most historians and victims of its missionaries would beg
| to differ that Christianity isn't imperialistic.
|
| https://en.wikipedia.org/wiki/Christianity_and_colonialis
| m
|
| >Christianity and colonialism
|
| >Christianity and colonialism are often closely
| associated with each other because Protestantism and
| Catholicism participated as the state religions of the
| European colonial powers and in many ways they acted as
| the "religious arms" of those powers. According to Edward
| Andrews, Christian missionaries were initially portrayed
| as "visible saints, exemplars of ideal piety in a sea of
| persistent savagery". However, by the time the colonial
| era drew to a close in the last half of the twentieth
| century, missionaries became viewed as "ideological shock
| troops for colonial invasion whose zealotry blinded
| them", colonialism's "agent, scribe and moral alibi."
|
| >In some areas, almost all of the colony's population
| were removed from their traditional belief systems and
| were turned into the Christian faith, which the
| colonizers used as a reason to destroy other faiths,
| enslave the natives, and exploit the lands and seas.
|
| >"Colonialism is a form of imperialism based on a divine
| mandate and designed to bring liberation - spiritual,
| cultural, economic and political - by sharing the
| blessings of the Christ-inspired civilization of the West
| with a people suffering under satanic oppression,
| ignorance and disease, effected by a combination of
| political, economic and religious forces that cooperate
| under a regime seeking the benefit of both ruler and
| ruled." -Jan H. Boer of the Sudan United Mission
| HeckFeck wrote:
| I think it is a stretch to argue that every missionary is
| motivated by 'Imperialism'. Certainly some may have been
| in the past, but if one sincerely accepts the tenants of
| a religion then it isn't surprising one has enthusiasm to
| spread it. I've seen plenty of evangelists for every
| ideology under the sun. People who think they are right
| will go to great lengths to spread their ideas.
|
| Also, the end of slavery was pushed by conscientious
| Christian evangelists like John Newton and William
| Wilberforce in the UK. It is easy to argue against
| slavery in Christianity owing to the Imago Dei doctrine.
| I suspect it is less easy to argue against slavery in
| other religions and cultures; many of which still
| practice forms of it today.
|
| Spreading your religion while separating your culture is
| difficult. The same way it is difficult for a migrant to
| fully adapt the customs of any host culture. I think the
| relationships between these ideas are more complex than
| the evil catch-all of 'Imperialism!'.
| emodendroket wrote:
| I think it might be easier to see the point you are
| making if we substituted some other ideas. For instance,
| how many of us are ready to argue that freedom and
| democracy are evil or imperialist ideas? Yet they served
| as a rationale for the invasion of Iraq.
| HeckFeck wrote:
| There's more than one way to argue it.
| emodendroket wrote:
| I think one could easily make similar arguments about,
| say, the Internet. But let's leave it aside. Let me ask
| you something: even granting it's true, what does
| anything here have to do with Perl, beyond guilt by
| association?
| chipotle_coyote wrote:
| I don't think it's a stretch to argue that Christianity
| is imperialistic, and by extension Christian missionaries
| are de facto agents of imperialism. However, I think it's
| a stretch to argue that _Perl_ is imperialistic. :)
|
| It's fascinating to learn that Larry Wall might have
| become a missionary had his life gone a different
| direction, but I don't think one can make a compelling
| case that Wall's religiosity had a major effect on Perl's
| language design. Don Knuth is a devout Lutheran who
| played church organ, taught Sunday school, and wrote a
| book about the Bible -- but it just doesn't seem likely
| we should be concerned that typesetting our work with TeX
| subtly infuses it with Christian apologia.
| gwd wrote:
| > Going on a missionary expedition in Africa to invent
| and teach illiterate people of color a written language
| to read the Bible in certainly sounds to me [...] like
| religious and linguistic imperialism...
|
| Honestly, this could only be said by someone who had
| never met anyone whose spoken language hadn't been
| written. I personally know people who have recently done
| exactly this: Developed a writing system for a tribe of
| people who previously had no writing system for their own
| language. The people themselves are amazed to see their
| language written down. They have generally internalized
| the negative attitudes of the larger culture they live in
| toward their own language; they'll say things like (and
| this is going to be offensive, but again, it's them
| saying it about their own language, having internalized
| it from the larger African language groups around them),
| "I thought our language was just a monkey language".
| Seeing it written down gives them a sense of value and
| pride toward their own culture they've never had before.
| This is exactly the opposite of "the transfer of a
| dominant language to other people". On the contrary, it
| gives people a powerful tool to fight linguistic
| imperialism.
| khrbrt wrote:
| That's very interesting. I thought it was odd that so
| many writing systems for indigenous languages[0] use
| invented alphabets instead of adapting Latin letters but
| this makes total sense when the written form is a source
| of pride and identity.
|
| 0: https://en.wikipedia.org/wiki/Canadian_Aboriginal_syll
| abics
| orf wrote:
| > 503: No server is available to handle this request.
|
| Should have used PHP.
| bluenose69 wrote:
| Perhaps my experience with Perl is similar to that of others who
| have been programming since the 1970s.
|
| I loved Perl back in the day, when it seemed like a great
| alternative to constructing unix pipelines of awk, sed, etc.
|
| Although I mostly used Perl for interactive use, I also found it
| helpful for quite a few short programs, say in the 20 to 200 loc
| category. But I noticed a problem: these programs were tricky to
| understand a year later. Perl was still useful, mind you, but
| just not as pleasant at the edit stage as it was at the writing
| stage.
|
| And then Python came along. It soon became clear that Python
| programs would "age well". For quite a while, Python and Perl
| coexisted in my toolbox.
|
| And then Perl started to drift into it's present state. All the
| new goodness (and I'm sure it _is_ good) just seemed to come at a
| cost of more complexity. But why should I learn the new way of
| doing Perl, when Python was already filling the gap for that sort
| of work?
|
| Gradually, my use of Perl decreased, from every hour to every
| week, to ... well, never.
|
| I wish Perl had just gone into bug-fix mode long ago, so that it
| could have remained a reliable and understandable tool for a
| certain set of tasks. And then I'd still use it for pipelines, as
| I use awk, sed and the rest.
| senderista wrote:
| I still use Perl for occasional one-liners in pipelines as well
| (where it's simply more expressive than sed or awk), but I've
| given up on it for scripting in favor of (first) Ruby and
| (later) Python. About a decade ago, though (long after I'd
| switched to Python), I found that a regex-heavy program I'd
| written for processing terabytes of JSON files ran several
| times faster in Perl than in Python. I wonder if Perl still has
| a noticeable edge in text processing speed?
| cutler wrote:
| A Perl regex is certainly more performant than the Python
| equivalent however I was surprised to find one of PHP's .ini
| options enables regex performance which surpasses even
| Perl's.
| tragomaskhalos wrote:
| I would always use Python over Perl for ad-hoc scripting jobs
| above a trivial level of complexity, but would worry about its
| performance vs Perl for more permanent tasks. Worked on a
| codebase that has a lot of Perl glue, including a lot of text
| munging, and tbh whilst rewriting that stuff in Python would
| mean that it's not reliant on grey old geezers to maintain it,
| I would worry about the performance hit. Wonder if commenters
| have any explicit comparisons they could share.
| bonzini wrote:
| Pipelines or, more in general, an escape hatch within shell
| scripts when awk doesn't cut it, are indeed my main remaining
| use of Perl. I used it recently for some JSON processing
| script, because I couldn't expect jq to be installed and I
| couldn't even know in advance if the Python interpreter was
| python, python3 or python3.8, but that was painful...
| dkarl wrote:
| I think there is room for a tool that is used for the same
| purpose as awk and Perl one-liners, but feels more familiar to
| 2020s programmers. Something that intentionally doesn't scale
| up to complex scripting, and is designed from the beginning to
| be relatively readable and learnable for people whose
| background doesn't already include the old-school command line
| text processing tools.
| bsder wrote:
| > Although I mostly used Perl for interactive use, I also found
| it helpful for quite a few short programs, say in the 20 to 200
| loc category. But I noticed a problem: these programs were
| tricky to understand a year later. Perl was still useful, mind
| you, but just not as pleasant at the edit stage as it was at
| the writing stage.
|
| This. Exactly.
|
| I had to start bringing printed out Perl code to my job
| interviews in order so that the interviewer was in _my_ subset
| of Perl. And then the interviewer was lost, but that was better
| than him thinking that I didn 't know Perl.
|
| That was a giant red flag that I needed to be using a better
| language. I jumped to Python in 1996, arguably at the height of
| Perl's popularity, and never looked back.
| kqr wrote:
| I started with Perl and Python much later (mid-to-late-2000s)
| and my experience is the opposite. Python programs aged
| horribly (just after 6 months it could be a half day's work to
| get the build working locally again) whereas with Perl
| programs, written correctly with plenty of tests, I could jump
| into them two years later and everything just worked exactly as
| where I left it off.
|
| I'm sure python has had several improvements in this regard
| since, but it just seems to me like it comes at a cost of more
| complexity (virtualenvs and whatnot.)
| ghshephard wrote:
| I think the OP was referring to the readability of the code,
| versus the build pipeline. I'd have to agree with them - I
| could never understand my _own_ Perl code 6 months after I
| had written it, whereas I have little difficulty reading
| _anybody 's_ Python code.
| sleepysysadmin wrote:
| >Stepping outside the Perlish echochamber for a moment
|
| I'm surprised. Many people can't do this.
|
| Honestly haven't seen any perl since a hackthebox machine before
| covid where you compromise a user with a perl shell.
|
| >In practice, Python has snowballed simply because of network
| effect. Everyone knows Python so everyone uses it so everyone new
| has to learn it.
|
| I would interject and suggest this is incorrect. Python has 1
| thing that Perl does not.
|
| '{' and '}' and ';' and $`', '$&'
|
| Clearly unnecessary. Python simply does it better. By that simple
| reality Perl is doomed to death.
|
| >Does the colour of the spoon really matter that much, or is it
| simply that everyone wants the same colour, regardless of what it
| is? Do we want to throw away what makes our blue spoons
| distinctive blue colour just to get in with the "in" crowd, even
| though we don't actually like green?
|
| This is a very bad analogy. It's making the assumption that all
| spoons are equally effective. Syntax alone the green spoons are
| green spoons but Perl's blue spoons have a different handle, 1
| with spikes that may hurt you. Why do people use the green
| spoons? They have scars on the hands from the spikes.
| rurban wrote:
| Again the maintainers solely responsible for that debacle are
| blaming others. It's perl6's fault, it's ruby's fault, it's
| javascript.
|
| Whilst they dont admit they had nicely developed specs and list
| of features to implement (for perl6), but couldn't manage
| (technically) to implement even the most simple ones from 2002 to
| 2021. Management is not-existing, developers all went elsewhere.
| You don't want to argue with people you have no idea. Famous is
| e.g. how Russ Cox was treated when re2 and backtracking DDOS was
| presented to p5p:
| https://perl.perl5.porters.narkive.com/guZUVhlv/article-on-p...
|
| Just a few amateurs and system admins, who use it for their job
| are dabbling with it and keep destroying the codebase. It was
| unmaintainable in 2002, and it's more so now. The language is
| fine, p5p (the development process) is totally broken.
| mancerayder wrote:
| Link is 503'ed, but isn't Python the main external factor? Who
| cared about Perl6 other than enthusiasts?
|
| I witnessed the change as, overnight, my Perl expertise became
| 100 percent useless in the job market. Today, almost no one
| younger than 35 has even seen Perl code unless they work in a
| megalarge corporation that has legacy code.
| Tepix wrote:
| The linked page is down for me.
|
| Here are alternative links to the same emails by Paul "LeoNerd"
| Evans
|
| external factors email
| https://marc.info/?l=perl5-porters&m=161688954811345&w=2
|
| internal factors email
| https://marc.info/?l=perl5-porters&m=161688963311406&w=2
| cafard wrote:
| Thank you for the working link.
| redis_mlc wrote:
| FYI: I use perl5 every day. Works fine. Love the moderate static
| and dynamic type checking, forward references and Mojolicious -
| which Python has none of.
| peterhi wrote:
| I was a Perl dev for more than a decade and the only problem we
| had was when we started to grow the company. We needed
| programmers who could do Perl but graduates had not even heard of
| it. How do you evaluate a graduate who had been taught Java as to
| how well they would do with Perl? Would they even want to learn
| it?
|
| Learn Java. Work in finance. Take the money :)
|
| Perl devs were self taught hackers. Finding them was nigh on
| impossible
|
| We ended up with a bunch of Java devs and pivoted to Java for all
| new applications. As a commercial decision it was sound and the
| company is doing well
|
| I'm doing Ruby now and facing the same problems but at least the
| graduates have heard of Ruby so they at least know what we are
| asking them to do
|
| And yes Perl6 was a massive issue. At least they finally
| acknowledged that it was really a Perl inspired language and not
| Perl at all
| commandlinefan wrote:
| Sounds like a bunch of perl clutching to me.
|
| ;P
| Rompect wrote:
| 503
| warpspin wrote:
| One of the factors which lead to Perl's decline is there are too
| many ways to do it :-)
|
| This is fine for a lot of stuff, but somewhere in the 2000s, it
| became increasingly annoying you could not properly use Perl's
| biggest value up to that time, CPAN, anymore, because when you
| brought in 5 dependencies, you ultimately had 5 different object
| systems, 15 type validator libraries, 5 different time libraries
| and probably 20 different exception systems in your project, all
| happily eating away at your memory and your sanity.
|
| This is still a major problem today, where you basically cannot
| pull anything from CPAN anymore without the smallest package
| requiring a different fat object system.
|
| A lot could have been avoided by early on building a proper
| standard library delivered with the language, but instead at that
| time Perl delivered a lot of obsolete cruft, simply because it
| always was part of Perl, instead of real basics.
|
| That's at least my take on things. Though of course, npm proves
| many people do not give a damn about overly long dependency
| lists, so maybe it's just what I personally dislike about the
| direction Perl has taken.
| daotoad wrote:
| This was a huge pain in the neck. The rise of Moo/se has helped
| somewhat.
|
| Back in the day there was that horrible trend of using "inside
| out" objects that would let you reliably subclass something
| without knowing it's underlying module system.
|
| Ovid's Cor project has some really great work on specifying a
| default OO sytem for Perl 5 (or maybe 7).
| https://github.com/Ovid/Cor/wiki
| pansa2 wrote:
| > _5 different object systems_
|
| This is an issue in Lua as well. The language is unopinionated
| and designed to offer "mechanism, not policy", meaning you can
| design your own object system based on the language-provided
| primitives.
|
| The problem is that everyone does design their own object
| system - and they're all different, with no interoperability.
| space_ghost wrote:
| I've been happily using Perl daily for 20 years. I still use it
| daily, despite slowly moving to NodeJS for most production work.
| There's just some things that Perl does better than everything
| else -- text processing and gluing external programs together,
| namely -- that I very frequently find myself doing.
| matvore wrote:
| I love using Perl too (the real one, not Raku) for the same
| reasons, except I haven't even been using it as long as you
| (only 4 years or so).
|
| One other thing you can do with Perl is transition very
| smoothly from one-liner, to stand-alone script, to multi-module
| systems, as your requirements get more and more complex.
|
| I think the visceral reactions people claim to have to the
| syntax and other warts are rather sad. Perl certainly has warts
| but with some determination you can get used to them and become
| much more productive as a result.
|
| I am not a big fan of OO in general, and it seems the major
| complaints against Perl include the object system and nested
| references. I happily avoid those features, and this may be why
| I don't resonate with the Perl criticisms.
| pnathan wrote:
| I started off professionally writing Perl 5. A few comments.
|
| Perl 5 fails in separate areas.
|
| * no standard OO system * no standard exception system * no
| standard module system * context-driven polymorphism * the
| standard library didn't have JSON and a few other key needs built
| in, so dragging in CPAN all the time was a hassle.
|
| The first three issues generate maintenance issues that are not
| found in other languages that are roughly isomorphic. The fourth
| generates bugs. The fifth generates deployment problems out of
| line with its competitors.
|
| Perl is also, as alluded to elsewhere, an expert tool. Those have
| not fared well for the past 25 years, sadly. Hopefully in the
| next 25 years, as the industry matures and stratifies, experts
| will have the opportunity to select and use difficult but high
| quality tools on the regular.
|
| The Perl 6 horse got put together for another ritual beating, I
| see. Have at it.
|
| Sigils and the other ideas from linguistics are a notion which I
| believe will be adopted down the road more and more. I see them
| as one of the best syntactic ideas of Perl, although the context-
| shifting use of them (@ vs $) is something I see as bug-prone.
| sershe wrote:
| I remember Perl being distinctly painful to maintain. My favorite
| example was when I made a little blog engine in college, that had
| a calendar component that showed the old posts but had various
| neat features (in addition to actually handling all the special
| cases of rendering a calendar).
|
| A couple years later I needed a slightly different calendar
| render for a freelance project that had to be in Perl. I looked
| at my old, terse Perl code (it was maybe a couple screens if
| that), tried to understand what the hell it is doing, and wrote
| the new calendar from scratch. I also made sure to "write C in
| Perl" so someone could actually understand it later.
|
| It's possible to write clean code in Perl, but from pretty much
| every codebase I've seen, it is not natural :)
| cariaso wrote:
| I was a bioinformatician who worked on the Human Genome Project [
| https://www.foo.be/docs/tpj/issues/vol1_2/tpj0102-0001.html ]. I
| used perl daily for years. In ~2004(?) I attended a San Francisco
| Perl Mongers User Group meeting where Randal Schwartz confirmed
| that Perl6 would sufficiently break backwards compatibility that
| the CPAN would be started from scratch. I walked out of that
| meeting and said out loud "oh well, I guess it's time to switch
| to python".
|
| I firmly believe that it wasn't specifically about the switch to
| perl6, it was about the loss of the cpan that broke the camel's
| back.
| jlv2 wrote:
| The whole "Perl 6 won't be backwards compatible" effectively
| took the wind out of the sails. If you force people to have to
| redo what they already have, that will give them an incentive
| to investigate other alternatives. Couple this with the 15
| years of "Perl 6" going nowhere just opened the door for
| everything else to grow in it's place.
| dehrmann wrote:
| > I guess it's time to switch to python
|
| Which would go one to have its own breaking change.
| raverbashing wrote:
| pip didn't start from scratch with Python 3, so the py2->3
| was a much less breaking change
| the_only_law wrote:
| I had a minor interest in bioinformatics when I was a child and
| everything I would read about it pointed towards Perl beings
| pretty big tool. I toyed with the language a little around the
| time, probably couldn't recall much now.
| Glavnokoman wrote:
| External factors?!?! C'mon, admit it is just a terrible language.
| dmingod666 wrote:
| There were 2 mails, one external and one internal.
| shagie wrote:
| For reference - the internal factors post is https://www.nntp
| .perl.org/group/perl.perl5.porters/2021/03/m...
| goto11 wrote:
| I tried to figure out how to do object oriented programming in
| Perl but got stuck at "an object is a thingy which contains a
| reference to itself" ...and apparently you had to "bless" that
| reference?
|
| Then I discovered Python and haven't looked back.
| mixologic wrote:
| I feel like the old Perl saying "There's more than one way to do
| it" Is what makes Perl a powerful tool for an individual, and an
| impediment to progress in an organization.
|
| It's possible to be expressive enough in perl that your
| colleagues cant really fully understand what it is you're trying
| to accomplish.
| gerikson wrote:
| I agree (as a Perl fan). There's never any debate over what's
| "idiomatic" Perl. It's as idiomatic as you want it to be!
| lelanthran wrote:
| > I feel like the old Perl saying "There's more than one way to
| do it"
|
| And every Perl developer took that as a personal challenge to
| find and use all the ways in a single program :-)
| emodendroket wrote:
| The obvious answer to me is that the drawn-out, confused,
| ultimately abortive transition to Perl 6 sucked all the energy
| out of the ecosystem and it fell behind. Awkward support for OOP
| and the whole manual reference thing also probably didn't help.
| Ruby in a lot of ways seems like a more modern language that is
| similar to Perl.
| ii550 wrote:
| Larry Wall's homepage color might be another non-insignificant
| factor :D
|
| www.wall.org/~larry
| maxharris wrote:
| I'm surprised that the author didn't mention syntax, symbols,
| keywords and the like. I remember when Perl was popular in the
| late 90s, and I could never figure out because it was simply too
| difficult and confusing for me to read. I found it much easier to
| understand languages that favor the use of words over symbols,
| and I suspect this is the case for many other people as well.
| at_a_remove wrote:
| I used to be on many mailing lists and noted the decline of
| traffic long before the announcement of Perl 6. While you could
| argue that everything that could be asked had been asked, I do
| not know if I buy that. Stack Overflow suggests that there's a
| baseline of questions out there because new people are always
| arriving; I would then expect that mailing list question rate to
| level off at some trickle, but it completely stopped in some
| groups.
|
| Perl's readability is low, in my opinion, due to a few factors.
| First and most obvious is the reliance on, well, tons of symbols,
| resulting in the refrain "executable line noise." The second
| factor is the philosophy of there being more than one way to do
| it; this means that you have less local idiom in the language and
| so you have to spend more time guessing how _this_ programmer did
| it. The third factor is what I would consider cultural: one-
| liners. The one-liner is an interesting exercise but it only
| proves how clever you are in _writing_ the code for a very
| arbitrary restriction, the number of characters used, and the
| tradeoff is readability.
|
| Another big arc would be CPAN. So many modules, each covering a
| different eighty percent of what you needed to do. And heaven
| help you if you were on Windows for some odd reason because many
| of those modules needed a compiler, or at least the ones I came
| across did. The standard library was simply too anemic, and so
| you were left trying to find just the right package and hope you
| could work around its shortcomings instead of doing something
| obvious and getting on with your day.
|
| I do not buy into the network effect of the article. Perl was
| there before Python, and it was larger than Python for some time.
|
| Culturally, it was a ticking time bomb, waiting to be supplanted
| by a language that was not a write-once, read-never design. In a
| similar sense, PHP's culture assured its fast adoption and rise,
| but also would bring it an ugly reputation, which it still
| struggles with -- perhaps now unfairly!
| spookthesunset wrote:
| CPAN, way back in the day, was ahead of its time but it
| eventually became eclipsed by other package managers.
|
| And like you said... other languages like python came
| "batteries included" with a ton of stuff that you'd have to
| spend quite some time hunting around for on CPAN.
| cutler wrote:
| The mod_php factor with cheap hosting thing isn't the whole story
| as many cheap hosts only offer PHP/CGI.
| wazoox wrote:
| I've made a presentation on this very subject to a hackers
| conference in 2013. It's very clear to me, it's because of Perl6.
| In 2013, Perl was 26 years and Perl6 was 13 years already, half
| as old as Perl itself but nothing close to production ready.
|
| The launch in fanfare of Perl6 in 2000 had a general chilling
| effect on Perl: many people considered from that point that there
| was no point learning and using Perl 5, because Perl6 was "just
| around the corner" and was "the future of perl".
|
| It's just last year that people finally came to their mind :
| Perl6 became Raku and is a different language, period. And Perl 5
| is supposed to get out of its 20-years of maintenance cycle by
| becoming perl 7 and changing some defaults it should have done
| back in 2007 or so...
|
| Well. That's life.
| Diederich wrote:
| I think two major things, beyond the sheer audacity of it,
| really slowed Perl6 down. This is NOT meant to sound negative;
| I basically owe my entire career to Perl. I got paid to write
| Perl every day from 1993 until 2015, and I still really like
| the language, warts and all, and _love_ the amazing features
| /ideas in Perl6/Raku.
|
| The first is Larry Wall's basic personality. He is a really
| nice guy, all the way through. Along with that, I think he's
| fairly passive. Years ago, I read a comment from him where he
| noted that of all of the things he's posted online, the vast
| majority were replies. He rarely directly _initiated_.
|
| Clearly he initiated Perl, as well as
| https://en.wikipedia.org/wiki/Patch_(Unix) (for those who might
| not know, this was basically the reverse of 'diff', and is
| effectively the spiritual ancestor of MANY of the tools and
| technologies we use today.)
|
| But the genesis of Perl was really small; like Linux and many
| other projects, it was done to solve very specific problems,
| and also for the fun of it. Perl utterly exploded, effectively
| dragging Larry Wall along with it.
|
| All that to say: even as Larry was able to put forward
| technical direction, as seen in the creation of Perl6 and
| subsequent design/development processes, I don't think he ever
| felt very comfortable being a community leader.
|
| The second major factor early in Perl6 was that Larry had some
| substantial medical problems at really key, important times.
|
| I don't know if these and other factors, if different, might
| have allowed Perl6(Raku) to become successful. It's possible
| that the sheer, awesome scope of Perl6 was just too big.
|
| One way or another, what ended up happening was a damn shame.
| In retrospect, I think it's clear that Larry should have, in
| 2000, announced the creation of a new language, a language that
| shared many/most of the broad goals and ideas of Perl.
|
| But 21 years ago, such an announcement would have been almost
| impossible. The _total_ amount of hurt and divisiveness that
| ended up coming about due to Perl6 might have been minimized
| with such an action, but it would have been strongly front-
| loaded, with an unbearable amount of community pain
| concentrated into a single point.
| cutler wrote:
| I believe Jon Orwant's mug was largely responsible for Perl
| 6.
| Diederich wrote:
| This is a very neat and relatively obscure reference, but
| yeah, Orwant's very considered 'tantrum' was almost
| certainly the psychological 'kick' Larry needed to get out
| of a local maxima.
| munificent wrote:
| _> The launch in fanfare of Perl6 in 2000 had a general
| chilling effect on Perl: many people considered from that point
| that there was no point learning and using Perl 5, because
| Perl6 was "just around the corner" and was "the future of
| perl"._
|
| Yup, the Osborne effect:
| https://en.wikipedia.org/wiki/Osborne_effect
| AMerrit wrote:
| This is exactly it for me. Perl just seemed to be stuck in a
| stasis with the whole Perl6 mess for over ages while the world
| moved on. I still maintain some perl scripts and it's great for
| small tasks, but by the time they got everything sorted out no
| one under 30 knows perl at all anymore as it seemed like a dead
| end.
| emilper wrote:
| "while the world moved on"
|
| yet the world still does not have half the features Perl 5
| already had for 20 years :)
|
| ... from scoping to support for every major programming
| paradigm
| cutler wrote:
| Much as I like Perl I'm not sure I'd agree with you. What
| does Perl have that Ruby doesn't?
| ajross wrote:
| That's pretty much exactly it. The core of the perl community
| decided that what they _really_ wanted to do was spend their
| time bathing lazily in their shared hubris, designing (with...
| surprising patience) a new perfect language. And I don 't
| really blame them, that's a lot of fun.
|
| But perl had become successful not by being a perfect
| embodiment of TMTOWTDI or whatever but by being a _simply
| amazing practical language for practical problems_. And without
| the support for the practice of perl, perl 5 rapidly withered
| as new problems became more practically solved in Python or
| Ruby.
|
| It's worth noting that Python almost did exactly the same thing
| to itself, too. But it was saved because Python 3 wasn't nearly
| as incompatible as Perl 6, and that it actually shipped
| reasonably promptly. But IMHO it's no accident that the
| explosion of node.js happened just as Python broke the world
| with their incompatible upgrade.
| Supermancho wrote:
| Focusing on the community is a strange take. I dont know much
| about Perl6 or care...anymore than I knew anout PHP6. Perl is
| syntactically complete and has great library support.
|
| People dont choose Perl because it's too flexible in how to do
| things ie what is idiomatic in Perl...well it depends on how
| well you know Perl. This hurts readability and adoption. It
| also has warts like any other language but thats hard to detect
| when reading code is an issue.
|
| The best parts of Perl have already been adopted by other
| languages. No reason to use Perl that I can see.
| 7thaccount wrote:
| As someone who learned both well after the 2000s, it was
| painfully obvious to me that Python was easier to learn/use and
| had a lot more momentum than Perl (this was around 2012). I
| think that's really the nail in the coffin in that they both
| cover the same scripting niche, but Python won out and less
| people began to use Perl. Also, Perl5 has a modules approach in
| that there are several potential OO frameworks like Moose,
| while Python had it as part of the base language which a lot of
| people prefer. Python also became a solid data science and
| numerical methods language, so it ended up winning out. I never
| thought Perl5 was bad, just not as good as Python. As far as
| P6/Raku, I think the language design is good, but I won't use
| something like that professionally until it reaches a certain
| quality and production readiness. It really is pretty neat and
| is like a superior Python without the useful frameworks.
|
| Edit: the Python REPL approach was also much better for
| debugging scripts than how I had to do things in Perl.
| tyingq wrote:
| _" Also, Perl5 has a modules approach in that there are
| several potential OO frameworks like Moose, while Python had
| it as part of the base language which a lot of people prefer.
| "_
|
| Perl's built-in OO, without Moose, works fine, and isn't
| substantially different from python's.
|
| What is different is that "everything is an object" in
| python. That's not true for Perl. So Perl OO is a bit saddled
| with references (pointer like things) and sigils ($this,
| @that, %theother) and therefore intimidating looking data
| structures, dereferencing, etc. To me, that's what makes OO
| Perl painful. To be fair, it's also one reason why Perl is
| often a lot faster than Python...basic types don't have the
| same amount of overhead.
|
| Personally, I love Perl and still use it often. But I can see
| why Python sucked away the user base.
| wombatpm wrote:
| This right here. I had a project in 2003 that I started in
| Perl and wanted to do right with OO. That lasted two days.
| I switched to Python and have never turned back
| jonathankoren wrote:
| I like Perl, and find the complaints about sigils weak
| given how many people swear by POSIX scripting, when there
| are so many better tools out there like Perl.
|
| However I also found Perl's OO to be painful. I'd call it a
| cruel joke. I could never comfortably wrap my head around
| its implementation because it always felt like a horrible
| kludge on top of the module system. Is it a module? Is it a
| class? Is it an object? Are they normal functions? Are they
| class methods? Or are they member methods? The answer to
| all for these questions is a resounding yes! TIMTOWTDI
| bites us once again.
|
| Perl is great for its primary use case of being the
| thinking person's BASH, and it has the greatest regexp and
| stdio support for any language I've used, but I wouldn't
| build anything OO with it.
| tyingq wrote:
| I didn't mean to say that sigils were a general issue.
| Just that they made complex data structures (and thus,
| OO) more complex...and intimidating for newcomers.
|
| As for wrapping your head around Perl OO, really it's
| just bless(). Bless($thing,'namespace') says "this $thing
| is an object, in this namespace". You can make an object
| without adding a namespace beyond the default main
| namespace...
|
| Like: sub test {print "whee\n";} my
| $foo={}; bless($foo,'main'); $foo->test();
|
| That will print out "whee". Because I "blessed" $foo into
| the main namespace, calling $foo->test() is calling the
| subroutine "test" in the main namespace, with '$foo' as
| the first argument.
|
| So OO in Perl is just mapping a namespace to a blessed
| reference via bless($ref,'namespace'). Then
| $ref->call($arg) runs the "namespace::call" sub, but as
| if you did namespace::call($ref,$arg).
| salamander014 wrote:
| In one of my previous positions, part of my work was
| maintaining legacy build and automation scripts, many of
| which were written in Perl.
|
| The one thing that stood out to me, was what happened when I
| had to show somebody else what a script did. (I was always
| showing somebody with _some_ programming experience, but not
| always with the matching language).
|
| It didn't matter what language they had experience with,
| Python was always easy to walk them through the code. I know
| this sounds scary to most, but when you are low on people and
| even lower on resources, you do what you can.
|
| When I needed to explain Perl to somebody without Perl
| experience, the eyes would glaze over as soon as @ and $ and
| % characters started showing up (re: immediately).
|
| It's not that Perl isn't a great or powerful language. It is.
| I use Perl style regex almost every day. Perl taught me
| hashmaps.
|
| But Python code looks familiar to a lot more people. No
| mystery symbols. No needing to explain that the @ symbol is
| an array, except when reading from it. Then you use $.
|
| When I explain Python code to someone who doesn't know
| Python, they ask me about the actual code. Why I made certain
| decisions regarding the design or functionality.
|
| When I explain Perl code to someone who doesn't know Perl,
| they tell me it looks like gibberish.
| acdha wrote:
| > But Python code looks familiar to a lot more people. No
| mystery symbols. No needing to explain that the @ symbol is
| an array, except when reading from it. Then you use $.
|
| I learned Perl first and used it professionally for a
| number of years but switched to PHP and Python more or less
| for this reason. Perl had a great package manager,
| performed well, etc. but no matter whose code it was, it
| required more work to read code and even seasoned
| developers would waste time on bugs which turned out to be
| some magic syntax quirk which was too easy to miss.
| perltidy helped a lot but why not start with a language
| where many of these problems can't exist?
|
| The other big reason was error handling: Python's reliance
| on exceptions is a huge win for stability & avoiding
| certain security bugs. Perl code was harder to read with
| all of those return code checks and even seasoned
| developers would mess up more complex scenarios.
| twic wrote:
| > No needing to explain that the @ symbol is an array,
| except when reading from it. Then you use $.
|
| Perl is stuffed with unforced errors like this. Lack of
| named parameters! Reading from filehandles by putting angle
| brackets around them! Filehandles being a distinct type
| from scalars! Hashes and arrays not being usable in the
| same way scalars are (can't put them inside an array or a
| hash, have to use a reference)! Even at the time, this
| stuff was distinctively bad. I wrote loads of Perl in the
| late '90s, and as soon as Python became viable, i leapt at
| it, because the language was so much simpler and more
| uniform.
|
| All this is particularly wild considered in the light of
| the fact that awk, an explicit precursor to Perl, has a
| significantly simpler syntax. How did Larry Wall look at
| awk and think "i know, what i need to do is take out the
| named parameters, and add some more sigils!".
|
| I do wonder if, it hadn't been for Perl, there might have
| been room for awk to grow into something more general.
| Probably not. But i don't see any _technical_ reason why
| not.
| jandrese wrote:
| I agree with you on a lot of this. Complex (nested) data
| structures are a real pain in the ass in Perl, especially
| back in the early 2000s.
|
| However, named parameters have been a thing for ages.
| It's extremely common to call functions using an
| anonymous hash like so: $sock =
| IO::Socket::INET->new(PeerAddr => 'www.perl.org',
| PeerPort => 'http(80)',
| Proto => 'tcp');
| twic wrote:
| By named parameters, i mean: sub
| double($value) { return $value * 2; }
|
| Which you can't write in Perl (or at least couldn't in
| 1998). You have to write this: sub double
| { my $value = shift(@_); return
| $value * 2; }
|
| "Named parameters" probably isn't the right name. This is
| such a basic feature of programming languages that i
| don't even know what it's called.
| jandrese wrote:
| The term you are looking for is "pass by reference".
|
| Perl does not have pass by reference, you have to use
| pointers if you want to do it. It will even go so far as
| to duplicate an entire array or hash you pass to a
| function, which can surprise novice Perl programmers when
| they build a giant data structure and start passing it
| around only to discover their program running slowly. Or
| worse, finding their changes to the structure being
| undone when the function exits.
| cygx wrote:
| _> The term you are looking for is "pass by reference"._
|
| Nope, just parameter declarations. I also kind of doubt
| the by-value semantics will surprise anyone the way you
| describe: If you pass things by value without explicitly
| taking a reference, the structure (arrays and hashes,
| specifically) will be flattened into the argument list.
| If you're unaware of this, things will probably go wrong
| long before you've had time to be surprised by stuff
| getting copied...
| cutler wrote:
| "Unrolling @" was a common bugbear amongst Perl
| programmers and caused a few I know of to leave for Ruby
| or Python. Normal, parenthesised parameters were
| considered experimental until not that long ago so is it
| any wonder Perl failed to compete with Ruby and Python?
| gwbas1c wrote:
| > When I explain Perl code to someone who doesn't know
| Perl, they tell me it looks like gibberish.
|
| I had a very brief experience with Perl in school around
| 2001-ish.
|
| All those concepts you brought up made me never want to
| touch it again. The language just comes across as a tool
| made out of necessity in the 1980s / 1990s, but then better
| tools came around.
|
| But, more importantly, I will never apply for a job that
| lists Perl. It's just a relic from the past.
| Florin_Andrei wrote:
| Perl almost encourages obfuscation. Some folks took pride
| in writing hard to read Perl code - and the language gave
| them all the rope they could hang themselves with.
|
| For that reason I always disliked Perl, quite strongly, and
| from the beginning (I've first seen it in the '90s).
|
| Bad, naive language design, that's all. The prevalence of
| Python nowadays is a sign of maturity.
| spookthesunset wrote:
| After working a python shop for few years one thing I
| always liked was it was rare that you could tell who wrote
| what bits of code. Not sure why that was... it might have
| been how the language itself forced certain idioms. But
| typing this out I also think it could be the shop's
| practice of face to face code reviews. Before you'd merge
| anything into master you'd always snag somebody to sit next
| to you and look over your code.
|
| So it could have been the language, but it could have been
| the culture too.
| lacker wrote:
| Python and Go are both like that. The language really
| encourages a single way of doing things, so when a new
| programmer sticks 20 lines of new logic in the middle of
| someone else's file, it quite often aesthetically blends
| in. I like it, but sometimes there's a trade off against
| power and flexibility.
| goatlover wrote:
| Python has magic methods, metaclasses and decorators,
| which gives you quite a bit of flexibility when you need
| it. Maybe not quite to the extent of Ruby, but more than
| Go.
| Florin_Andrei wrote:
| I've had to read other people's Perl code before, and
| that experience basically made "flexibility" a bad word
| in this area for me.
|
| Please stop the ^$%@#$%#@^@$%^&( nonsense, Perl hackers.
| That's not flexibility, it's childish bravado. Write code
| that people can read. If some of that precious
| "flexibility" is lost in the process, that's a net gain
| actually.
| cutler wrote:
| Long live Perl golf. Can't we have a bit of fun with our
| language in this anodine, Python-dominated world?
| dcolkitt wrote:
| This is the correct answer. Python and Ruby pretty much ate
| Perl's lunch. Depending on whatever you were working, one of
| those two languages, was almost always a strict improvement
| over Perl.
|
| The only place really shines comparatively is in CLI one-
| liners. But even there, awk is usually a better tool.
| citrin_ru wrote:
| I agree that Python and Ruby ate Perl, but for me they are
| not strictly an improvement. Just spoons of a different
| colour. Python is more novice friendly, but for someone who
| uses language every day it is not a problem to learn Perl
| syntax and BCP.
| cutler wrote:
| Ruby is pretty close to Perl for one-liners. Try it.
| klyrs wrote:
| I was doing web development back then, and Perl in your
| cgi-bin was pretty hot tech, especially compared to c. But
| then PHP came around, and I never really looked back. I've
| moved on, and out of web development, and I keep circling
| back to C, but never perl. Python does pretty much
| everything I'd want Perl for.
| rualca wrote:
| > It's very clear to me, it's because of Perl6.
|
| It doesn't seem right to ignore the increased popularity of
| better and more user-friendly interpreted languages such as
| python, which has since became ubiquitous even in spite of the
| python2-python3 transition.
|
| Also, there was the inception of node, which brought javascript
| front and center.
|
| In fact, among the interpreted languages that were popular 20
| years ago, which ones besides python still hold some relevance?
|
| Perl, whether v5 or v6, can't exactly compete with javascript
| or python in terms of ubiquity and user-friendlyness.
|
| If Perl's learning experience is harsher, and in the end
| there's less demand and job prospects, why would anyone pick
| Perl over any alternative?
| edoceo wrote:
| PHP was popular 20 years ago and seems to still have wide
| adoption.
| fatbird wrote:
| The fact that PHP was, in the era of shared hosting
| accounts, the default scripting language was like a
| slingshot maneuver around the sun. It's hard to understate
| the incredible momentum that surge of casual users brought
| to it that no other language received, and has sustained it
| over the long, painful modernization that was needed to
| make it relevant today. More than PHP, we're still using
| platforms that were begun in that era: WordPress, Drupal,
| etc. There's still Zencarts out there.
|
| It's more remarkable that Python is still relevant, which
| is a testimony to the overall quality of its design and its
| usefulness in a large number of different areas. Had Python
| been only a web scripting language, it would have been
| eclipsed by PHP just like Perl.
| cutler wrote:
| I don't know about quality of design. Python's popularity
| is largely due to how much it dumbs down and being a
| first mover in the scientific world. Python has no built-
| in regex support and its crippled lambdas are nothing
| more than the indulgence of its BDFL who has a bias
| against functional programming. Compare that with Matz's
| approach to language design.
| fatbird wrote:
| Arguably, that's good design, at least in terms of actual
| success. Where is Ruby relative to Python? "Dumbed down"
| means good pedagogical language--it's always had an
| advantage there as well in scientific computing. And the
| strength of its design is seen in the fact that it's
| still used by very experienced/advanced users.
|
| Also, it wasn't a first mover in scientific computing--
| Matlab and Maple were around long before numpy. Matlab
| dates from the early 80s; numpy from 2005. Python has
| stolen a lot of mindshare _from_ Matlab with numpy and
| scipy and Jupyter. Even today I help PhDs switch from
| Matlab to scipy.
|
| Personally, I've always liked the ethic of Python that
| there's only one way to to do it, normally. It means the
| boilerplate code looks the same everywhere, and when you
| break the "rules" of that one way, you do it with a
| reason, a conscious justification, rather than as a
| stylistic flourish or an idiosyncratic preference.
| acdha wrote:
| > Python has no built-in regex support
|
| Are you basing this claim on something like not having a
| special literal syntax? Python has had regular expression
| support for ages and it works quite well:
| https://docs.python.org/3/library/re.html
| cutler wrote:
| Yes, I'm comparing it to languages which have regex
| operators (Perl, Ruby) and where you don't have to
| `import re`.
| acdha wrote:
| Okay, so that's a somewhat different claim and it really
| comes down to how much you care about an operator versus
| a extra couple of characters. Most programmers know how
| to touch-type and do not hammer out regexps so quickly
| that the difference between: $foo =~
| s/foo/bar/
|
| and foo = re.sub("foo", "bar", foo)
|
| is a significant factor in deciding which language to
| use, especially since there are legibility tradeoffs
| (i.e. escaping) and the Python approach for handling e.g.
| groups is cleaner for non-trivial code and avoids the
| chance of accidentally clobbering $1, $2, etc. -- a bug
| pattern I've seen affect people more than once.
|
| Personally, if I were advocating Perl I'd probably go
| with angles like the extended capabilities or more
| complete Unicode support which Python users need to get
| from the regex module (https://pypi.org/project/regex/).
| [deleted]
| hossbeast wrote:
| Php is banned within many companies as too insecure of a
| platform to build anything on.
| rufius wrote:
| By at least some measures, it's the most popularly deployed
| language as well. This is probably at least 50% due to
| counting WordPress.
|
| That said, I did pick up PHP and Laravel out of curiosity.
| It truly is nothing like the PHP I learned in 2001.
|
| e: a word
|
| I've also seen a lot of job postings in that field. Seems
| like Laravel has a substantial following in the way that
| Rails does.
| spookthesunset wrote:
| Back in the 2000's Perl was my bread and butter.
|
| The thing about perl6 was it over promised and... well... never
| delivered. It was to be a from scratch rewrite. It was gonna
| have all these space-age feature like a VM to host other
| languages like what .net or Java does. It was gonna try to fix
| years of baggage. It was gonna be super hot. But it never
| shipped in time.
|
| Meanwhile python was an excellent alternative. Ruby on Rails
| was just coming around. C# was becoming a real contender (c#
| remains one of my favorite languages...).
|
| All those languages were getting tons of community support.
| Perl's community was starting to slow. It's top devs were busy
| with v6. V5 was not getting any cool new features. And it was
| made quite clear that v6 had many breaking changes from v5.
|
| I dunno. I file perl6 in the same bucket I file Netscape and
| Winamp. Proof that doing ground up "from scratch" rewrites are
| great ways to kill forward momentum on your product. Rewrites
| take much longer than any estimate. To pull it off you need to
| have unlimited budget and the ability to support and improve
| the current version while also building a brand new version
| whose scope constantly creeps to maintain parity with your
| current version. The second you stop maintaining and improving
| what you have in the market _today_ , your competitors will eat
| your lunch.
|
| It is what killed Netscape to a large extent.
|
| It killed Winamp to a large extent.
|
| And it put a couple nails in perl's coffin too.
| dhosek wrote:
| In 2008, I was in charge of standing up a new service at the
| company that I worked. They were a heavy Perl shop. I
| considered using Perl 6 for it since it was "just around the
| corner." After some investigation, we realized that (a) it was
| _not_ just around the corner and (2) Perl developers were hard
| to come by. We went with Java /Spring instead.
| Tycho wrote:
| To me the core problem is that it's much harder to read than its
| direct competitor, Python.
| forgotmypw17 wrote:
| I started a project with Perl as the primary language recently
| (couple of years ago) because it has remained stable for 20+
| years.
|
| The lack of breaking changes between releases, so common in other
| languages, was a major selling point for me.
|
| Just about every other language I've used, as a high-level coder,
| would not have stood up to 20 years, but Perl has.
|
| I think of it as a feature-complete language, enough to get what
| I want done without making me worry about migrations when "old"
| syntax is "deprecated".
|
| I still start my Perl scripts with "use 5.010", and it is enough
| for me to generate HTML from text and do whatever else in
| between.
| zeckalpha wrote:
| Perhaps a port of reticulate from R to Perl would allow Perl to
| get at least as many bindings as Python but allow it to keep its
| blue spoons?
|
| https://cran.r-project.org/web/packages/reticulate/index.htm...
| jiofih wrote:
| 503, inability to handle common web workloads might be one factor
| /s
___________________________________________________________________
(page generated 2021-04-01 23:02 UTC)