There’s one common criticism that I don’t get: That Perl 5 is hard to learn. I have a theory about this, but warning, rant incoming.
People used to read programming books. I learned both Perl and C from books; for me Perl wasn’t any harder. Yes, the syntax is unique — but you learned to read weirder things, C++ certainly isn’t any more intuitive in a vacuum.
But of course, few people read books anymore, so where do people learn languages? I guess universities and blog posts. (And increasingly YouTube videos, which have even less content density.)
Universities only teach old versions of Java. Blog posts are limited in size. Sad conclusion: any language that has more than a blog post’s worth of differences to Java 1.x will find it hard to reach very broad adoption.
Indeed, people used to read programming books (I still have two C++ Builder and a "Complete Java Reference" bricks on my bookshelf), but IMO the problem is not that people don't read books, but that a good written reference documentation are very rarely written(or are hard to find) for today's new languages.
It seems all classes of content from video, to blog posts and books suffer from various con-people publishing lots of crap with catchy titles and ordinary people just loose hope browsing through them. In such environment the cost of time spent on a crappy video or blog article is negligible, but if one buys books that are badly written or auto generated one can waste hours and hours before one realises.
So I can't blame today's wannabe programmers for choosing videos and blog articles instead.
> but IMO the problem is not that people don't read books, but that a good written reference documentation are very rarely written(or are hard to find) for today's new languages.
Ok, but you can get most of Perl5 from 25 year old books at this point. (Wasn't the version number changed to 5 for a book anyway? or was that Perl4?). A little modernization help might be nice, use bytes vs use chars?, less emphasis on mod_perl which doesn't seem widely used anymore, maybe some coverage of Moose, etc. But if you got the basics from a old book, you'd be fine to learn the rest.
On the topic of new languages, I just started somewhere where they use Rust, and read the O'Reilly Rust book and seem to have done ok; lots of style comments on my first diff, and I'm slower than in other languages I already knew, but otherwise seems fine.
I forget what book I read to pick up Erlang; may have been Joe's or the O'Reilly; but that's an older language... It was public for ten years prior to me picking it up, and private for 15ish before then.
I read both the Camel book (Programming Perl) and the slimmer one (Learning Perl) but I still found perl 5's split between by-value data structures (@foo/$foo[0], %foo/$foo{"bar"}) and by-reference data structures ($foo->[0], $foo->{"bar"}) really confusing. Ruby and Python managed to avoid needing to differentiate these cases, they would just silently dereference things as needed, and from what I can tell Perl basically had this split for backward compatibility with perl 4 which didn't even support nested data structures. Steve Yegge has a whole section of his Perl rant talking about this (https://sites.google.com/site/steveyegge2/ancient-languages-...). The sigils only make it more confusing because they really don't help you here. $foo is either a reference to @foo or a reference to an element of @foo depending on whether it is immediately followed by an index ("[0]") or if there is a dereference operator ("->") in between. And you only need the dereference operator if you're going to need to get a nested data structure. So like you can't just do $foo[2][4] (as I recall, it's been years) you have to do $foo->[2][4]. If you just need to go one level in you can do either $foo[2] or $foo->[2] depending on your whims. It's kind of madness.
First, I agree that using Perl today feels like using something from a different era. Having sigils at all feels so antiquated to me now.
But the mechanics of the sigil thing never confused me. Either because it was explained to me very well, or possibly -- Larry Wall is a linguist, after all -- because there's an analogy to grammatical cases, which English largely doesn't have anymore, but my native language does.
The sigil depends on what you want to get out of the expression, not what you put in. So @foo would name the whole array, while $foo[2] would name a single element from it.
> If you just need to go one level in you can do either $foo[2] or $foo->[2] depending on your whims. It's kind of madness.
You misremember, but I don't blame you, it's a very unorthodox rule. These are very different expressions.
$foo[2] accesses the second (third depending on how you count) element of @foo. @foo is a "value array", whenever possible, I tended to use those because I found them more convenient and intuitive.
For programmers coming from JavaScript or Python, and people building more complex data structures, using a reference array might be more intuitive. Those are stored in scalar variables, like $foo, but to disambiguate with the syntax for accessing @foo, you have to explicitly dereference it with $foo->[2].
my @foo = (1,2);
$foo[1]; #2
my $foo_r = \@foo
$foo_r->[1]; #2
my @bar = (1,2,$foo_r);
$bar[2]->[1]; #2
Re the sigils, you're right, I would just add, $ is for scalar and a scalar iirc can be /either/ a value or a reference, that's why $foo_r and $foo[1] above both start with $. That's what I found unhelpful, it would have been nice to have a distinct sigil for refs (but presumably Larry was out of available symbols at that point!).
and yet rust is very complicated and plenty of people read the rust book to learn it.
my first paid software gig was writing perl and i still use it for text processing quick jobs and such but the truth is it’s just a weird language full of bizarre conventions that is a bad choice for building large systems. better languages replaced it
You're right, Rust is an interesting counterexample to this trend I'm ranting against in years. I'm a fan of it. Whether it ever reaches adoption beyond the tiny fragment of people who dive deeply into technologies anyway remains to be seen, however. I've noticed that the backlash that it's too complex is already starting to build up.
I feel kind of bad for Perl. I never learned it. I'm no foreigner to "hard" languages. I know Bash, I know Makefiles, I can write a "sed" script with a little effort. Of course I know Python and C and I even put in the effort to learn Rust. But Perl never bubbled up the priority list. We used it a little bit for internal scripts at my previous job, but I rarely had to interact with those, so I never took the time to actually learn it. I'm certain there's a good language in there, but it's so rarely used during my time in the industry (I'm in my mid-30s), that it's just never been worth the effort. I'm sorry, Perl.
I don't think Perl is really that hard to learn. It does have a few traps for people new to the language though.
Raku on the other hand is easy to learn. Of course it is so easy to learn that knowing another language, any other language, can make it more difficult to fully grasp. That is because Raku is strangely consistent.
Most languages have a set of syntaxes for different actions. Raku has a set of features, and the syntax mostly just falls out from that.
When someone who knows another language tries to learn Raku they naturally translate what they already know to Raku features. That will only get you a surface level understanding of the language. No other language is really comparable.
Raku also has a new view of regexes. In Raku a regex is just a DSL for matching text. So rather than bolt on feature after feature like other languages have done it allows you to embed regular Raku code for situations where that is easier. You can also combine them using grammars (a type of class) to get a full parser out of several parts.
In fact the grammar feature in Raku is the only one that is powerful enough to parse Raku easily. Part of that has to do with the ability to mutate the language.
It has been said that the best way to solve a programming problem is to create a language in which solving the problem is easy. Raku, using that ability, allows you to do that easily.
>I'm certain there's a good language in there, but it's so rarely used during my time in the industry (I'm in my mid-30s), that it's just never been worth the effort. I'm sorry, Perl.
No apology needed, I'm sure even Perl realizes it was a little stagnant while the rest of the industry zoomed by.
I used Perl in the mid 90's, so I suspect I'm ~20 years older than you. ;) Back then it was a jack-of-all-trades language, good at parsing logs or text files, pinched hit for php if you needed add scripting to websites, etc.
Over time, javascript improved, python gathered mind-share, and perl still worked but wasn't keeping up with new libraries.
I'd like to see Raku do well, although I doubt I'll use it professionally - seeing as how I've got around ~8 years left until I retire.
Interesting, not sure I agree but i think you're onto something.
I have been frustrated by framework walkthroughs that fail to explain the expected prior knowledge. Recently I've been using Laravel, and something as simple as "You need to include the following 'use' statements" would have saved me tens of minutes several times over by now. They just launch into code, with no context. I fear they know that if they make the content long, no one will read it.
I'm left frustrated by the experience and I suspect long term anyone that cannot be bothered learning half a page of content isnt going to make anything long lasting anyway.
I don't think Perl is/was any harder to learn than C. Easier, in fact, since you don't have to worry about making a mistake with pointers.
I've not found colleagues who learned Java or C# first have had trouble learning Perl. When they've learned "modern" Perl with Moose/Moo, they've been happy with it.
Perl is a scripting language. To me it's very similar to Python and a Lot easier to learn than something low level like C that doesn't have everything built-in and just available for you.
I think you are in the right direction -- the problem with perl is it's hard to find high-quality internet articles about it. There are many excellent articles about (picking a random example I care about) the borrow checker, or async, in Rust. There might be even better books, but the articles give me something to be inspired by and start investigating.
I think Perl's decline started 15-20 years ago, as that's when Perl 6 was "coming soon", and people didn't bother learning Perl 5 because of that. I can't remember ever seeing an interesting article about programming in Perl, either here or on Twitter.
Had to disagree that there aren't high quality posts on perl. For example the articles from perl by MJD https://www.plover.com/~mjd/perl/ are top notch. Similarly the articles from Randall Schwartz are quite good. But all these articles were written long ago. Since perl has fallen out of favour these days, probably there are less posts covering Perl and consequently fewer high quality articles that are recent.
I also grew up learning programming via textbooks--there wasn't really a choice for me, pre-Internet. It had its pros and cons, but what I miss the most is being able to have a single well-written textbook that, when you were finished, you will have gained a solid understanding of the foundation and reasonable approaches on how to use the language.
These days information is so much more readily available for free, but it feels so often I have to resort to reading StackOverflow, shitty YouTube videos, and even shittier OFFICIAL documentation from developers who obviously don't care about technical writing. Machine Learning is especially bad about this.
I was with you up until the last paragraph. I don't know how typical my experience was, but when I was in college (class of 2016) we also had to write a lot of C, and a smattering of other languages (e.g. one early class in OCaml, AI/ML classes in Python, etc.). I think you may be on to something with the idea that Perl is less known now due to not being taught in college due to other languages being focused, but I think you conclusion that Java is the only thing people will find familiar might be a bit too strong.
I learned a bit of Perl from authors who focused only in Perl, great videos and books that allowed me to understand Perl how it worked differently from Python (at the time was taking over learning media).
But using Perl in the real world was much more difficult. Posting to Perl Mongers about a simple question of some block was often met with equally difficult answers. Many Perl scripts used at my past work places were written by very well versed Perl developers, using every possible shortcut to make the code smaller (and more confusing).
learning to use perl is not hard. any language is easy when you only learn and use a subset of it. and perl is very powerful. you don't need to learn all of it in order to write code.
what makes perl hard is to learn all of it and deal with code that uses features that you haven't learned yet.
perl is like english. easy to get started with, but the more you learn the more complex and more difficult it gets
People used to read programming books. I learned both Perl and C from books; for me Perl wasn’t any harder. Yes, the syntax is unique — but you learned to read weirder things, C++ certainly isn’t any more intuitive in a vacuum.
But of course, few people read books anymore, so where do people learn languages? I guess universities and blog posts. (And increasingly YouTube videos, which have even less content density.)
Universities only teach old versions of Java. Blog posts are limited in size. Sad conclusion: any language that has more than a blog post’s worth of differences to Java 1.x will find it hard to reach very broad adoption.