21–30 of 157 posts
The final section, which I was anticipating for the whole article, was essentially this: http://en.wikipedia.org/wiki/Osborne_effect What killed Perl? An imaginary Perl did.
The article is entitled "Why Perl Didn't Win", not "Why Perl is Dead". Perl hasn't been killed.
Back then I saw that people who worked around enterprise projects that used some kind of a relational database used a lot of Java. People who were jumping to the Web 2.0 Bandwagon, used stuff like Python and Ruby largely because of the frameworks. Thereby what's really apparent is tools that are best suited for the job get traction.
Perl is still unmatched for many things. Unixy things like dealing with large quantities of text. Gluing things together, getting stuff done quickly etc etc.
Perl's every day use cases were going way, as database and web heavy things ruled the business scenarios. Perl largely occupied a niche and ruled it. So is Python today(Web frameworks), and ruby. Also Perl reached a very high peak in the 90's. And reaching that kind of level again isn't possible unless Perl does some very new and paradigm changing.
Perl 6 is kind off believed will do that eventually some day. But from what I last heard a few day back in this very forum, there are not close to anything serious even in another 2 years from now.
Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain. Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to…
I work on a small team (C++), so this has never been an issue. If you break coding guidelines someone will notice and let you know.
But this really should be integrated into work-flows. (ie/ into Gitlab, Jira, etc.) There should be some kind of step - before you are allowed to merge code - that checks that you are withing coding guidelines.
Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain. Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to…
I've been diving into some of our legacy Perl and man, the learning curve of the various sigils and implicit variables. Even working with collections was challenging.
I'm working to make it better Perl (I have a copy of Modern Perl on my desk), but that's solely to make it understandable so that we can rewrite it / replace it with something like Salt.
The defense has always been that Perl is designed more like natural language than programming language, ok, but: natural languages are a LOT harder to learn than programming languages. Put me in a room with Haskell and I'll learn it in a month. Give me a month of training in french and I'll maybe be able to not make an entire ass of myself if I try to get from point A to point B. Human languages are hard. Design wise -- I'm not sure that's what you want to aim for.
Almost everything you learn is... surprising. Like flattening lists. Useful in a context, maybe, but is that the kind of thing anyone would ever expect? And why is "list" (@) part of the variable name in the first place? It's like "dynamically typed, kind of, except your variable name has to say if it's one thing or many things or many things referenced with keys". What the fuck? I'd rather the python way of "it's a name that points to a thing, whatever that thing is". GOT IT. Simple.
I program in C++ for a living, probably the biggest clusterF of a language ever devised (outside of perl), and the thought of reading Perl still terrifies me.
Write once, read never.
Speak for yourself! (or maybe, for annoying coworkers???) It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though. For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstra…
I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product). And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then. There were two personal reasons why…
This notion of cognitive overhead (or any other kind of overhead) and how it scales (as programs get larger, applications get older, and/or systems become more interconnected) is really what's important to language and system design.
Yet most of what gets bandied about between programmers seems to involve what is nifty or what can save you some kind of overhead on mostly rather small scales. Even if a library or language feature can save you from typing another line of code 1200 times throughout a project, that doesn't necessarily mean it's a no-brainer. Ask yourself: What other kinds of costs are incurred? If your nifty doodad increases compile times by a factor of 10, or completely kills the cache across large parts of your application, or makes large swathes of the code hard to debug, it may not work out cost-benefit wise.
So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.
Ironic in the Alanis sense, because one thing that drew me to Perl in the first place was the bog simple use of Dictionary, as compared to writing the same thing in C.
I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product). And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then. There were two personal reasons why…
And funny enough Objective-C is taking this quite seriously, being a very verbose language (the new Swift language also keep the verbose method names, enums and properties).
While Perl is exactly the opposite. There's a reason people jokingly call it a write-only language.
It has real implication on its usage. You use Perl for one-off scripts you intend to forget and maybe delete after you run them a few times.
While CPAN happened, I wonder how much Perl was an obstacle in multiple people joining to work on a single library (versus multiple people just downloading it and using it, big difference).
The same things could be argued as for why, why C didn't win, or C++ didn't win, or even really PASCAL/Smalltalk/Lisp didn't win. "Winning" is temporary and not the end goal of any language and is best left to be declared by Charlie Sheen like pundits trying to demonstrate their language bigotry. Is Perl the first tool that some of us think of when solving a problem? It might not be for you but it is frequently for m…
Winning isn't everything. :)