7 ms·
Perl was the poster child of scripting languages. When I started hacking on Perl 4 in the mid-1990s (before there was a Perl 5), it was a miracle language. I wa
by beat 10y ago
Perl was the poster child of scripting languages. When I started hacking on Perl 4 in the mid-1990s (before there was a Perl 5), it was a miracle language. I was throwing out multi-thousand line C programs wholesale and replacing them with 50 line Perl scripts that worked far better (daemons and Sybase reports, mostly).
Around 2000-2001, I worked on Perl 5 in a close-knit team at a dotcom startup. Even with daily interaction, it was really hard to keep coding standards straight and readability under control. The problem with Perl is that it tends to be a different language for every programmer. Its flexibility leads to arcane code that can only be easily understood by the person who wrote it.
Years later, in different roles, I've worked extensively with both Ruby and Python (I prefer Ruby). I will never, ever, ever go back to Perl for anything more than one line long. I still use Perl for 'perl -e' one-liners in the shell, mostly complex greps. That's it. If I write anything small enough that structure doesn't matter, I use /bin/sh. If I write something large enough that structure matters, I use Ruby.
Why? Because I like to be able to read my code.
Ruby is wonderfully expressive. It can do everything Perl can, and it does it in a much more readable, much more human way.
- acdha 10y agoMy experience was very similar. I used to write a ton of Perl for system administration, mod_perl web apps, etc. but swore off cold-turkey in the early-to-mid 2000s when I realized that every time I opened a .pl file the first thing I did was run it through perltidy and then spend a bit of time figuring out the author's personal conventions. My rule is pretty similar now: Perl or Bash is fine for one-liners or a script which fits in an 80x25 window and doesn't use non-scalar data structures but anything longer or which has much expectation of maintenance is written in something like Python where the culture and tooling favor readability.
- raiph 10y agoYou are speaking of the 22 year old Perl 5. This HN thread is about Perl 6. Larry Wall (primary author of record for both Perl 5 and Perl 6) noted in an article[1] that: "Perl 6 is also a completely different language ... [that specifically addresses] readability" Or, in greater depth: "Perl 6 is also a completely different language that has been rethought and rebalanced on every level, with much stronger support for both functional and object-oriented programming as well as reactive and concurrent programming. There is now pervasive concern for composability, evolvability, readability, and maintainability. We try to "hang everything on the right peg" to allow proper separation of concerns. While we still believe in providing multiple ways to accomplish something, we now try to encourage one of those ways as an appropriate starting default. So we think the language scales both down and up to the level of talent of the programmer; the programmer can start out in "baby talk" without getting into too much trouble and then whenever he or she is ready to learn a new concept, the language is ready to support that and to make it easy to refactor the code as the programmer grows in sophistication. For developers who are already sophisticated, they'll see that most of the problems endemic to the currently available dynamic languages are solved in Perl 6. We understand lexical and dynamic scoping. We detect most typos at compile time. We don't have a global interpreter lock. We encourage Smalltalk-style trait composition over uncontrolled mixins, multiple inheritance, or monkey patching." [1] http://www.infoworld.com/article/2882300/perl/perl-creator-larry-wall-rethought-version-6-due-this-year.html http://www.infoworld.com/article/2882300/perl/perl-creator-l...
- beat 10y agoGreat. So why should I go to Perl 6? What's the compelling use case? Ruby had a compelling use case - Rails. Rails completely reinvented how web applications could be written, and it did so in large part because it relied on the nature of the language (specifically its reliance on duck typing). That's why attempts to mimic Rails in other languages always feel a little clunky. JavaScript, for all its blecherous losing horror, had a compelling use case - it ran in browsers. Later, Node became a compelling use case, for dealing with both performance issues and package management problems that plagued other systems (including Rails). Python had multiple compelling use cases. It became very popular in math programming and teaching, for its clarity and consistency. Perl's compelling use case was with Perl 4, as a general purpose glue scripting language in a Unix world. It solved tremendous problems. Perl 5 didn't have a compelling case, and it grossly exaggerated the already bad problems with complexity and inconsistency. Am I talking about Perl 5? Yes, because for 22 YEARS, we've been saddled with that crap. Two decades of waiting for Perl 6, for Perl to unfuck itself and become something useful for more than one person at a time. That's like, my entire career. Longer than most programmers in this industry have been in the industry. Longer than some of them have been alive. 22 years. So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?
- raiph 10y ago> So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve? All good questions. My personal answers boil down to "no need" (to switch), "see the rest of this thread" (to read what promise Perl 6 might have), and perhaps https://docs.perl6.org/language/rb-nutshell https://docs.perl6.org/language/rb-nutshell (to read how someone familiar with Ruby explains how to map Ruby knowledge on to Perl 6).
- beat 10y agoSince programming language is often tied to programming framework, then switching languages means sacrificing frameworks. That's a problem. Admittedly, it's a form of Lava Flow Antipattern, but it's significant. I'm giving up a useful toolset, and I'm giving up accumulated domain knowledge. So why do it? Mainly, if the framework I'm currently using can't do things I need to do, or if it's incredibly painful to use. To the extent that someone has neither of those problems, a new language is a cure worse than the disease, whatever its benefits. Look at it this way... imagine there's a rib joint across the street. It may not have the best bbq, but it's there. Do I walk across the street for bbq, or do I drive halfway across town to get slightly better? I'll take what's there, thank you. Now, if I'm a vegan, I'll get up and go somewhere else.
- TheLarch 10y ago"The problem with Perl is that it tends to be a different language for every programmer." Exactly. Larry Wall cited an analogy somewhere: if you want to know where to put walkways on a new campus, wait until pedestrians have worn trails into the grass and pave there. Perl docs repeatedly makes jokes along the lines of, "it does what you want, unless you want consistency. Bottom line, Perl was designed without predictability and consistency in mind. This makes it blazingly fast for development by one person, but the administrative overhead between multiple programmers balloons. Because of a natural inclination to reduce the number of characters one uses, as you get comfortable with Perl you start taking more and more shortcuts. A singular moment in my long career occurred when I opened some old Perl code after leaving the language for a time. I stared for a long moment, dumbfounded. It was as if an alien had visited my computer and overwritten my code with what Wall has affectionately described as "line noise." Also, I was awed by the feature set in Perl 6. I don't think any language outside of Lisp, C, and Smalltalk has had such profoundly new ideas. Pronouns in Perl 5 are still unique to my knowledge after 20+ years. Wall is wildly imaginative. Perl is what made me realize, in the mid-90's, that OO is largely just a marketing term. A sufficiently powerful language provides whatever portions of OO you need a la carte.