21–30 of 88 posts
Hah, what's funny is that Jeff Hobbs, the author of the article, is one of the main Tcl developers.
Except, that Jeff (who used to work for me at Scriptics) is a pragmatic kind of guy and is likely to not allow his allegiance to Tcl prevent him from seeing what else is going on out there.
I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code.
This caused a backlash which lasted several years, during which the programming public panned the languages almost universally.
But a funny thing happened; rather than shriveling up and going away, the languages and their practitioners matured. Community focus became less centered on glue code and scrolling effects, and attention was shifted to writing clean, maintainable code which uses the language's best features (metaprogramming, easy hash/object manipulation, etc) in manageable, modular ways.
Now both ecosystems are flourishing, and though Perl doesn't have quite the install base of JavaScript, it's still a viable contender to Ruby and Python in their areas of expertise, and it can be called the best tool for some of those jobs.
The whole article fails to mention any advantage of Perl over the languages it's compared to (wonder why). The sooner Perl falls into obscurity, the better.
I currently code for my day job in a proprietary extension to a proprietary dialect of BASIC from the mid-80's. This language is legitimately broken, and has significant disadvantages at every turn. It has no real functions, no block-level scoping, lists are stored as delimited strings, there are no hashes, and nothing even resembling objects. Perl has all of these things. If you're coding in Perl and you write bad c…
My last project at work was rewriting a 4k line monstrosity in Perl into 500 lines of Python which do exactly the same. I can't even blame the original authors (it was likely their first larger program), it's just that Perl makes it so easy to write horrible code.
Article's conclusion: After a short lapse, Perl development is picking up and enthusiasm for Perl 5 is as strong as ever. I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code. This caused a backlash which la…
I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language.
I readily concede that this is probably an artifact of my limited experience with perl. Just noting what I see, not looking for a flame war.
How many of YC companies use perl do you think?
Earlier quoted context omitted.
Why not just write Python in Python instead ;)?
I like my braces ;}. Also, Perl 5 is feature-stable, and probably always will be. Python is in this 2.x-3.x limbo right now where it's difficult to find libraries that are going to work as-is for much longer. If you write a Perl application well, maintenance will as easy as reasonably possible, which I think is the only real measure of a good language. Most of the 'ease of use' problems disappear once you know what y…
CPAN is the killer app for Perl. Every time I flip across to another language I usually love the syntax and structures but the lack of a CPAN equivalent is always grating and I usually end up right back at Perl to get stuff done fast.
The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day you need to use Net::SSH and it wants to upgrade DBI::Search for some bizarre reason, which requires you to compile a beta version of the GZIP library because it's using some new interface that's not included with your CentOS 5 install. Then you find out DBI::Search requires DBI 1.41 and you're only using 1.40. There's a backwards incompatible behavior that affects your code in 1.41, which is why you haven't upgraded yet. You go through all 100k lines of your project and make sure all the DBI code handles this new case.
Then you have to try and install the changes on all 75 of your servers. You may have some sort of capistrano script to make this simpler, or you may have used RPM versions of your CPAN packages. Neither solution is less painful than the other. CPAN wasn't really designed to work with your sysadmin's workflow, so neither solution is particularly useful.
At the end of the day, you would have spent less time just writing the damn code yourself to call out to the ssh binary.
The whole article fails to mention any advantage of Perl over the languages it's compared to (wonder why). The sooner Perl falls into obscurity, the better.
Article's conclusion: After a short lapse, Perl development is picking up and enthusiasm for Perl 5 is as strong as ever. I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code. This caused a backlash which la…
"Perl development is picking up and enthusiasm for Perl 5 is as strong as ever." I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language. I readily concede that this is probably…
By the numbers, though, I still agree with the quoted statement. Perl development is picking up compared to the past few years, and enthusiasm for Perl 5 is the strongest it's been (at least since 5.0).
CPAN is the killer app for Perl. Every time I flip across to another language I usually love the syntax and structures but the lack of a CPAN equivalent is always grating and I usually end up right back at Perl to get stuff done fast.
I used to think this way. After living without CPAN for 3 years using different languages, I appreciate the lack of dependency additions my projects get. The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day yo…