Ancient languages: Perl (2004)(sites.google.com)
sites.google.com
Ancient languages: Perl (2004)
https://sites.google.com/site/steveyegge2/ancient-languages-perl
88 comments
Fun fact: Perl probably encompasses more supporting library code than any other language other than C.
The Comprehensive Perl Archive Network (CPAN) currently has 123,757 Perl modules in 28,037 distributions, written by 10,829 authors, mirrored on 270 servers.
Back in 2004 (almost 10 years; there's been some developments since then) someone ran SLOCCount on all of CPAN, and it estimated the development cost at about $677 million dollars. http://web.archive.org/web/20041010230806/http://www.etla.or...
Before you choose another language for your project, ask yourself if it's not going to cost more to write everything you'll need, or if using pre-existing, time-tested code might do the trick for cheaper.
The one downside about Perl that I think is the most unfortunate is the ninja aspect. You have to be a Perl ninja to write good Perl code. There's no two ways about it. If you come from a different language, you have to ignore all the rules and guidelines you used to develop in, and learn the Perl way, or be ye damned. Which is why most Perl code you've been forced to maintain sucks.
The Comprehensive Perl Archive Network (CPAN) currently has 123,757 Perl modules in 28,037 distributions, written by 10,829 authors, mirrored on 270 servers.
Back in 2004 (almost 10 years; there's been some developments since then) someone ran SLOCCount on all of CPAN, and it estimated the development cost at about $677 million dollars. http://web.archive.org/web/20041010230806/http://www.etla.or...
Before you choose another language for your project, ask yourself if it's not going to cost more to write everything you'll need, or if using pre-existing, time-tested code might do the trick for cheaper.
The one downside about Perl that I think is the most unfortunate is the ninja aspect. You have to be a Perl ninja to write good Perl code. There's no two ways about it. If you come from a different language, you have to ignore all the rules and guidelines you used to develop in, and learn the Perl way, or be ye damned. Which is why most Perl code you've been forced to maintain sucks.
That's mostly a function of age*avg.popularity.per.year. Java, python, ruby, etc. have been around long enough that available libraries are equivalent if not better.
A lot of CPAN's libs are likely cruft from the language being so old, the size of it says nothing. What's more interesting is how often libraries are updated with new code, and how often people use them.
A lot of CPAN's libs are likely cruft from the language being so old, the size of it says nothing. What's more interesting is how often libraries are updated with new code, and how often people use them.
Oh, right, old code. CPAN is funny in that they have a central location to test multiple versions of code on multiple platforms and comment/patch them over time. I don't know of anything similar for any other language, probably because there isn't a CPAN equivalent for any other language (edit: there is JSAN and CCAN, but not quite the same).
http://stats.cpantesters.org/
Want to see how old code stacks up in testing? Let's pick a module and see all its dependencies and their test results. XML::Feed as a random example: http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=lates...
Hmm, says no results for some of them. Let's drill down and select HTTP::Negotiate to see its test results. http://www.cpantesters.org/distro/H/HTTP-Negotiate.html
Looks like the latest version has been tested on lots of platforms, and it's good! Let's pick a different piece of code, something older, say from 2005? https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1... http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.ht...
Ah! So we see the last version it worked with and on which platforms, but on the latest perl it's failed its tests. We can drill down and see why the tests failed: http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94...
Hmm, unprefixed autoloaded parameter. That's probably not too difficult to fix. I guess even though there's old crufty code that isn't always maintained across versions, we have pretty good visibility into when something failed, and with good tests we know why and how to fix it.
There's a lot more resources to take advantage of through CPAN, like bug trackers, review sites, development wikis, etc. http://en.wikipedia.org/wiki/CPAN
http://stats.cpantesters.org/
Want to see how old code stacks up in testing? Let's pick a module and see all its dependencies and their test results. XML::Feed as a random example: http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=lates...
Hmm, says no results for some of them. Let's drill down and select HTTP::Negotiate to see its test results. http://www.cpantesters.org/distro/H/HTTP-Negotiate.html
Looks like the latest version has been tested on lots of platforms, and it's good! Let's pick a different piece of code, something older, say from 2005? https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1... http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.ht...
Ah! So we see the last version it worked with and on which platforms, but on the latest perl it's failed its tests. We can drill down and see why the tests failed: http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94...
Hmm, unprefixed autoloaded parameter. That's probably not too difficult to fix. I guess even though there's old crufty code that isn't always maintained across versions, we have pretty good visibility into when something failed, and with good tests we know why and how to fix it.
There's a lot more resources to take advantage of through CPAN, like bug trackers, review sites, development wikis, etc. http://en.wikipedia.org/wiki/CPAN
>Hmm, says no results for some of them.
A bad sign. This is usually the result of a single test hanging indefinitely, leading to the necessity of killing the entire automated testing process. As a consequence the test results don't get sent to cpantesters.org, putting the onus on the user to file a bug report.
A bad sign. This is usually the result of a single test hanging indefinitely, leading to the necessity of killing the entire automated testing process. As a consequence the test results don't get sent to cpantesters.org, putting the onus on the user to file a bug report.
This is admittedly anecdotal but: I made the jump from Perl to Ruby, and I can tell you I miss the quality of CPAN.
Yes you're right that CPAN has older stuff in it compared to say rubygems.org. It also has, as a gross generalization, older programmers with IMHO more mature and thorough approach to how they package reusable code. This is a language adopted first by graybeard Unix sysadmins in the late 80s and early 90s, then by the first generation of "CGI" web programmers, then by what we'd call today "web developers."
So the fact that CPAN contains old code has tons of upsides because the CULTURE of CPAN was set by more seasoned programmers. The documentation, for example, is of generally much higher quality than in Ruby gems, typically involving a nice Synopsis with lots of pertinent examples, documentation of methods/functions that thoroughly lists params and expected output (imagine that!), and that actually discusses edge cases from time to time. There are usually tests that actually run; by default a CPAN install runs a test suite which must pass before proceeding.
Rubygems are great but unlike CPAN which began as a manual system where adding a module involved dealing with judgmental humans it's all automated, making an account takes a few seconds and there are no real standards. The culture is just different. This has benefits, like lower barrier to entry, but downsides too. I am continually appalled at the level of documentation in common gems. I guess people expect you to just look at the code, as "view source" options abound in online docs, but then you end up chasing a code path through many methods and classes just to figure out the basics. And there are often real issues with the code, too; while Ruby has plenty of users, they are disproportionately Rails devs who stay in that little ecosystem, so a general purpose Ruby module tends to have fewer eyes on it. Don't get me wrong there is lots of high quality amazing stuff in Rubygems and I'm grateful for it, but you can't spend much time on Rubygems and NOT end up seeing a general difference in standards vs CPAN.
Anyway my point is older != cruft and older != bad. Older often means "used by many people for many years, with many bugs removed and many useful features added." Here's one small example. Let's say you want to pull a query param out of an HTTP request. You don't know in advance if it is a GET or POST. In Perl the (c 1994) CGI module solves this trivially without you having to drill down into how the requ was made. In ruby there is no method-neutral way to do this, you have to reinvent the wheel, inspecting the req, sniffing method, and (if you're using any of the code suggestions on Stackoverflow) MANUALLY splitting out the params by decoding the query string and splitting on ampersand. No one has solved this problem with a Ruby module (probably because if you're using Rails, as everyone is, there's a helper for this task).
People call Perl a "read only language" but CPAN's "old" culture makes code re-use more easy than even in a more elegant language like Ruby.
Yes you're right that CPAN has older stuff in it compared to say rubygems.org. It also has, as a gross generalization, older programmers with IMHO more mature and thorough approach to how they package reusable code. This is a language adopted first by graybeard Unix sysadmins in the late 80s and early 90s, then by the first generation of "CGI" web programmers, then by what we'd call today "web developers."
So the fact that CPAN contains old code has tons of upsides because the CULTURE of CPAN was set by more seasoned programmers. The documentation, for example, is of generally much higher quality than in Ruby gems, typically involving a nice Synopsis with lots of pertinent examples, documentation of methods/functions that thoroughly lists params and expected output (imagine that!), and that actually discusses edge cases from time to time. There are usually tests that actually run; by default a CPAN install runs a test suite which must pass before proceeding.
Rubygems are great but unlike CPAN which began as a manual system where adding a module involved dealing with judgmental humans it's all automated, making an account takes a few seconds and there are no real standards. The culture is just different. This has benefits, like lower barrier to entry, but downsides too. I am continually appalled at the level of documentation in common gems. I guess people expect you to just look at the code, as "view source" options abound in online docs, but then you end up chasing a code path through many methods and classes just to figure out the basics. And there are often real issues with the code, too; while Ruby has plenty of users, they are disproportionately Rails devs who stay in that little ecosystem, so a general purpose Ruby module tends to have fewer eyes on it. Don't get me wrong there is lots of high quality amazing stuff in Rubygems and I'm grateful for it, but you can't spend much time on Rubygems and NOT end up seeing a general difference in standards vs CPAN.
Anyway my point is older != cruft and older != bad. Older often means "used by many people for many years, with many bugs removed and many useful features added." Here's one small example. Let's say you want to pull a query param out of an HTTP request. You don't know in advance if it is a GET or POST. In Perl the (c 1994) CGI module solves this trivially without you having to drill down into how the requ was made. In ruby there is no method-neutral way to do this, you have to reinvent the wheel, inspecting the req, sniffing method, and (if you're using any of the code suggestions on Stackoverflow) MANUALLY splitting out the params by decoding the query string and splitting on ampersand. No one has solved this problem with a Ruby module (probably because if you're using Rails, as everyone is, there's a helper for this task).
People call Perl a "read only language" but CPAN's "old" culture makes code re-use more easy than even in a more elegant language like Ruby.
Ruby is probably not the best example as the Ruby community seems to suffer from mass ADD and live on the bleeding edge.
Agreed but keep in mind the Perl community were black sheep for years because the language is so (admittedly) hairy and ugly oh and also not a "real" programming language because it gained adoption when scripting languages still had a stigma. And the community had its own issues; there were sites like "Matt's Script Archive" distributing horridly insecure code (read through http://en.wikipedia.org/wiki/Matt's_Script_Archive). But time has a way of changing both communities and how they are seen. Like I said, old is good. Programming communities age like wine. (Which means they improve and improve -- until they peak at which point all bets are off.)
That certainly brings back memories... formmail, the early web discussion board (UBB?), etc
Reminds me of Matt's Scripts Archive:
http://www.scriptarchive.com/
For a long time, it seemed like everyone was using his form mail and web forum scripts.
http://www.scriptarchive.com/
For a long time, it seemed like everyone was using his form mail and web forum scripts.
I used formmail.pl! Multiple times!
It cured me of any inclination I might have had to actually learn and use Perl.
It cured me of any inclination I might have had to actually learn and use Perl.
Seems like a better lesson to learn would be "Don't use software written by people who've never read an RFC and know nothing about security." That way you could avoid awful software written in any language.
Yeah. The condition of rubygems are generally so bad (unfinished and/or abandoned), that I would strongly recommend Python over Ruby for new projects - which is a shame, in the core language Ruby is more elegant and more fun to write, and I know Ruby much better than I know Python. (for a concrete example, compare "NumPy" to the various attempts at good math structures in ruby)
I wish I could recommend perl - CPAN modules generally really are amazingly high quality. But the mental cost of the perl programming model: no named params! arrayref vs array vs list! Contextual::Return! blessing scalars into objects! - that cost is just so friggin high that I can't imagine asking anyone to follow me there anymore.
I wish I could recommend perl - CPAN modules generally really are amazingly high quality. But the mental cost of the perl programming model: no named params! arrayref vs array vs list! Contextual::Return! blessing scalars into objects! - that cost is just so friggin high that I can't imagine asking anyone to follow me there anymore.
You may find that stuff is quite easy to learn when taught by a good teacher. Try giving chromatic's Modern Perl a read sometime.
References do suck. All languages have ugly misfeatures, by nature. (Some language groupie collectives are in denial...)
But you get named parameters (and type checking of them!) for functions/methods through CPAN. And lots of other language extensions.
High flexibility in programming languages -- Perl isn't close to e.g. Lisp macros -- do have costs, of course. You need to use automatic tools, code reviews and coding standards. But you should do that anyway.
I really doubt the extra time/cognitive costs make for a noticeable extra burden, considering that you'll have to learn lots and lots of other stuff anyway.
But you get named parameters (and type checking of them!) for functions/methods through CPAN. And lots of other language extensions.
High flexibility in programming languages -- Perl isn't close to e.g. Lisp macros -- do have costs, of course. You need to use automatic tools, code reviews and coding standards. But you should do that anyway.
I really doubt the extra time/cognitive costs make for a noticeable extra burden, considering that you'll have to learn lots and lots of other stuff anyway.
> Before you choose another language for your project, ask yourself if it's not going to cost more to write everything you'll need, or if using pre-existing, time-tested code might do the trick for cheaper.
I believe 99.9% of the people will find any libraries they need in pretty much any mainstream language. There is a point where quantity stops being a factor.
I believe 99.9% of the people will find any libraries they need in pretty much any mainstream language. There is a point where quantity stops being a factor.
Here's one example of what i'm talking about: http://poe.perl.org/
It's a framework for writing reactive programs so you don't have to write all the glue normally associated with event-driven apps. It's got 1,044 framework-specific modules to take advantage of (in addition to making it easy to write them yourself).
There's a point where the wheel's already been made and trying to find a better one stops being a factor.
It's a framework for writing reactive programs so you don't have to write all the glue normally associated with event-driven apps. It's got 1,044 framework-specific modules to take advantage of (in addition to making it easy to write them yourself).
There's a point where the wheel's already been made and trying to find a better one stops being a factor.
from experiance python and other more modern languages just dont have the coverage of CPAN.
Some of us just want to get shit done and not rewrite the wheel (and debug it).
Some of us just want to get shit done and not rewrite the wheel (and debug it).
Python also had to contend with the 2.x/3.x split which, for some people, feels like two different languages.
So there is a 'stability' aspect (which is not changing fundamental things). Perl 6 is having those issues, too much change and its threatening to hemorrhage a bunch of CPAN.
Having been present at the 'birth' of Java and watching the forces at work on it as a language and on it as an environment. I find the forces that change languages interesting. And the question about when to change the language versus when to fork it and make a new language much more complex than I expected.
So there is a 'stability' aspect (which is not changing fundamental things). Perl 6 is having those issues, too much change and its threatening to hemorrhage a bunch of CPAN.
Having been present at the 'birth' of Java and watching the forces at work on it as a language and on it as an environment. I find the forces that change languages interesting. And the question about when to change the language versus when to fork it and make a new language much more complex than I expected.
I prefer being able to debug it. (Or maybe more accurately: not spending hours upon hours trying to debug it)
How many of those modules only exist to compensate for weaknesses in the core language though? For example, looking at http://search.cpan.org/~pevans/Scalar-List-Utils-1.30/lib/Li... just befuddles me: every function is a one-liner or built-in in Python and most reasonable modern languages. Yet Python's stdlib is much smaller than Perl's. Note that the module in question has to have a bunch more functions than necessary in order to work around more problems in the core language: you need sum0 in addition to sum because you can't just use default arguments and you need both min/max and minstr/maxstr because context dependent type interpretation confuses everything. Of course, this doesn't generalize at all to other types besides strings in contrast to python's keyargs.
Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre. The real problem here is that instead of having a small orthogonal core that everyone can learn and use, you have an incredibly complicated core that no one really understands that devolves lots of basic functionality to a giant network of modules.
I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects. But 100,000 bandaids isn't something to be proud of.
Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre. The real problem here is that instead of having a small orthogonal core that everyone can learn and use, you have an incredibly complicated core that no one really understands that devolves lots of basic functionality to a giant network of modules.
I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects. But 100,000 bandaids isn't something to be proud of.
Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre.
It should seem bizarre, because no one ever argues that.
I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects.
The module of greatest use to me today allows me to iterate through cells in a spreadsheet. Is it really a defect in a language that something like Spreadsheet::Parse Excel or Apache POI exists?
It should seem bizarre, because no one ever argues that.
I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects.
The module of greatest use to me today allows me to iterate through cells in a spreadsheet. Is it really a defect in a language that something like Spreadsheet::Parse Excel or Apache POI exists?
First: you're confusing "missing feature" with "weakness". Some people actually prefer not having 100,000 built-ins. IMHO comparing how you eat an apple with how you eat an orange is stupid. It's not the same fruit, and they work a little differently, and that is okay. If you prefer eating apples because you think the way to eat oranges is stupid, that is okay too.
Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it.
Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.
Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it.
Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.
Some people actually prefer not having 100,000 built-ins
Have you actually ever looked at Python? The core language is pretty small; much smaller than perl certainly. My point is that if you design the core well enough with orthogonal components and capabilities, you can give people the equivalent of many thousands of purpose-built modules.
I have no idea what you're trying to say with your fruit analogy.
Perl does have a small core that everyone can learn and use.
That hasn't been my experience; the core language seems to have a staggering number of rarely used quite odd features that accumulated early on. It seems extremely hard to write a new implementation of perl that supports all that cruft; one can't even parse perl correctly except by using the existing implementation.
Have you actually ever looked at Python? The core language is pretty small; much smaller than perl certainly. My point is that if you design the core well enough with orthogonal components and capabilities, you can give people the equivalent of many thousands of purpose-built modules.
I have no idea what you're trying to say with your fruit analogy.
Perl does have a small core that everyone can learn and use.
That hasn't been my experience; the core language seems to have a staggering number of rarely used quite odd features that accumulated early on. It seems extremely hard to write a new implementation of perl that supports all that cruft; one can't even parse perl correctly except by using the existing implementation.
Let's not get too wrapped up in language design. Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful.
Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless.
As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless.
As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
> As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
Most Turing-complete languages can be parsed (even Ruby, which is, among currently-popular languages that aren't Perl, noted for being parsing-unfriendly.) Perl can't be parsed not just because it is Turing-complete, but because (unlike most other languages), parsing Perl requires simulating its execution and it is Turing-complete, which combined require solving the halting problem to parse perl.
Insofar as it is valuable to be able to parse code written in a programming language, perl's unique barrier to parsing is a drawback.
Most Turing-complete languages can be parsed (even Ruby, which is, among currently-popular languages that aren't Perl, noted for being parsing-unfriendly.) Perl can't be parsed not just because it is Turing-complete, but because (unlike most other languages), parsing Perl requires simulating its execution and it is Turing-complete, which combined require solving the halting problem to parse perl.
Insofar as it is valuable to be able to parse code written in a programming language, perl's unique barrier to parsing is a drawback.
Really the halting problem comes down to "Can we tell if a function will end or not?" A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue. (A much simpler halting problem using parsing is do 1;)
We could remove the ability for Perl to compile, interpret and execute code at run-time, which would mainly involve removing eval, use, require, import, do, etc. But would that be better or worse than not being able to "parse" Perl code?
(As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed; you just can't get away from the pesky thing!)
We could remove the ability for Perl to compile, interpret and execute code at run-time, which would mainly involve removing eval, use, require, import, do, etc. But would that be better or worse than not being able to "parse" Perl code?
(As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed; you just can't get away from the pesky thing!)
> Really the halting problem comes down to "Can we tell if a function will end or not?"
Except that "program" is usually used instead of function, that's the usual statement of the halting problem, not something it "comes down to".
> A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue.
The problem with parsing Perl is that Perl cannot be parsed independently of simulating its execution. That fact, combined with the halting problem, means that it cannot be parsed (or, more accurately, that any program that correctly parses Perl cannot be guaranteed to terminate on all valid inputs.)
> As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed
All Turing-complete programming languages are subject to the halting problem. But that's not a problem for parsing most of them (including Ruby) the way it is for Perl because parsing most languages does not require simulating the execution of the code being parsed.
Ruby can be parsed, though its parser is notoriously ugly. [1]
[1] see, e.g., http://programmingisterrible.com/post/42432568185/how-to-par...
Except that "program" is usually used instead of function, that's the usual statement of the halting problem, not something it "comes down to".
> A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue.
The problem with parsing Perl is that Perl cannot be parsed independently of simulating its execution. That fact, combined with the halting problem, means that it cannot be parsed (or, more accurately, that any program that correctly parses Perl cannot be guaranteed to terminate on all valid inputs.)
> As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed
All Turing-complete programming languages are subject to the halting problem. But that's not a problem for parsing most of them (including Ruby) the way it is for Perl because parsing most languages does not require simulating the execution of the code being parsed.
Ruby can be parsed, though its parser is notoriously ugly. [1]
[1] see, e.g., http://programmingisterrible.com/post/42432568185/how-to-par...
You might want to check chromatic's comment on this subject in this comment tree (he has written, amongst other things, my favorite Perl book and hence has gone over these subjects carefully). He argues the halting problem for the parser is only an academic problem.
Edit: https://news.ycombinator.com/item?id=6163283
Edit: https://news.ycombinator.com/item?id=6163283
With respect, this is incorrect. You can have load-time execution without making parsing impossible. See Common Lisp for an example.
Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful.
I don't think either of these statements is true.
This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless.
I disagree. This is not about subjective aesthetics. There are some fruits that are poisonous and are thus objectively bad, totally apart from the question of what fruit you think tastes best. Some of perl's language design features are objectively bad. For example, the way references are implemented makes it absurdly difficult to reason about simple things like nested sequences. If that complexity was needed to get some positive benefit like outstanding performance, then maybe it would be justified. But there are no significant benefits. They are the way they are because Larry Wall didn't understand anything about programming languages when he made perl.
As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
With respect, every language I'm familiar with can be easily parsed except for perl. This has nothing to do with Turing Completeness or the Halting Problem. This has to do with having a sufficiently well designed syntax that tools can easily parse files written in the language without having to implement the whole damn language. That's an important property to have every language besides perl nails it because it is easy to do, but perl doesn't because Larry Wall didn't know anything about programming language design when he started.
I don't think either of these statements is true.
This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless.
I disagree. This is not about subjective aesthetics. There are some fruits that are poisonous and are thus objectively bad, totally apart from the question of what fruit you think tastes best. Some of perl's language design features are objectively bad. For example, the way references are implemented makes it absurdly difficult to reason about simple things like nested sequences. If that complexity was needed to get some positive benefit like outstanding performance, then maybe it would be justified. But there are no significant benefits. They are the way they are because Larry Wall didn't understand anything about programming languages when he made perl.
As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
With respect, every language I'm familiar with can be easily parsed except for perl. This has nothing to do with Turing Completeness or the Halting Problem. This has to do with having a sufficiently well designed syntax that tools can easily parse files written in the language without having to implement the whole damn language. That's an important property to have every language besides perl nails it because it is easy to do, but perl doesn't because Larry Wall didn't know anything about programming language design when he started.
As you showed (see chromatic's answer) in your first comment, you have no clue about even the small built in library in Perl.
Yet you have lots and lots of really flaming opinions about something you obviously haven't used enough to understand the tradeoffs -- everything has good and bad sides.
So, a counter question at your level:
Why do we get so many stinking language war trolls out of your Python environment? Something must be seriously sick when an open source environment generates that type of sick behavior in its members?
Now, I don't care about your personal problems -- but you trolls lower the HN quality. You all write the same flames about things you don't want to know. Just don't use it.
(Afaik, Perl is executable directly when loading in a pre-phase -- which might change the execution environment for other code when it is compiled. this is another tradeoff, where Perl is squarely on the side of expressibility. A feature with plus and minus effects (like making syntax extensions easier) -- except for stinking language war trolls, where everything except their model is bad...)
Edit: As I noted in another place -- yeah references suck. Now, can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
Yet you have lots and lots of really flaming opinions about something you obviously haven't used enough to understand the tradeoffs -- everything has good and bad sides.
So, a counter question at your level:
Why do we get so many stinking language war trolls out of your Python environment? Something must be seriously sick when an open source environment generates that type of sick behavior in its members?
Now, I don't care about your personal problems -- but you trolls lower the HN quality. You all write the same flames about things you don't want to know. Just don't use it.
(Afaik, Perl is executable directly when loading in a pre-phase -- which might change the execution environment for other code when it is compiled. this is another tradeoff, where Perl is squarely on the side of expressibility. A feature with plus and minus effects (like making syntax extensions easier) -- except for stinking language war trolls, where everything except their model is bad...)
Edit: As I noted in another place -- yeah references suck. Now, can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
you have no clue about even the small built in library in Perl.
I've written production perl code; no doubt with less skill than many posting here, but my comments are based on experience with the language.
Moreover, I've avoided making personal attacks on anyone. That's something you might like to try. If you can.
Perl is executable directly when loading in a pre-phase
So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution. OK, that's a problem...and what benefits do we get from that decision? Do we get lightning fast performance specifically from that design decision? No. Do we get more expressivity? I don't see any extra expressivity that stems from that decision; I mean, Common Lisp's load-time/compile-time eval-when constructs seem more powerful than perl's counterparts but it doesn't have this problem. I have no problem with language designers making decision decisions that I don't really care for. But some decisions that involve extra complexity for no benefit are just...wrong.
I don't like C++'s template system, but I can see what problems it is intended to solve and I can see some benefits from it. What benefits accrue from making perl impossible to parse without execution?
yeah references suck
But that's not the problem! Lots of language features suck...the question is why does perl have references that are so hard to understand? Is there any reason besides 'Larry Wall didn't know anything about programming language design when he wrote perl and eternal backwards compatability mean we can never change this'?
can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
Err, I don't think you understand the issue here. The problem with python lambdas is that they can only contain expressions and not statements, so you can say lambda x: x+1 but you can't incorporate a try/finally statement into a lambda. That's a language wart, no question. But that has nothing to do with list comprehensions. Comprehensions limit you to expressions and not statements just like lambdas.
With respect, I don't think you know what you're talking about here. I'm happy to discuss language design warts, including Python's, but I'd prefer to do so with people who, you know, know something about the subject.
I've written production perl code; no doubt with less skill than many posting here, but my comments are based on experience with the language.
Moreover, I've avoided making personal attacks on anyone. That's something you might like to try. If you can.
Perl is executable directly when loading in a pre-phase
So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution. OK, that's a problem...and what benefits do we get from that decision? Do we get lightning fast performance specifically from that design decision? No. Do we get more expressivity? I don't see any extra expressivity that stems from that decision; I mean, Common Lisp's load-time/compile-time eval-when constructs seem more powerful than perl's counterparts but it doesn't have this problem. I have no problem with language designers making decision decisions that I don't really care for. But some decisions that involve extra complexity for no benefit are just...wrong.
I don't like C++'s template system, but I can see what problems it is intended to solve and I can see some benefits from it. What benefits accrue from making perl impossible to parse without execution?
yeah references suck
But that's not the problem! Lots of language features suck...the question is why does perl have references that are so hard to understand? Is there any reason besides 'Larry Wall didn't know anything about programming language design when he wrote perl and eternal backwards compatability mean we can never change this'?
can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
Err, I don't think you understand the issue here. The problem with python lambdas is that they can only contain expressions and not statements, so you can say lambda x: x+1 but you can't incorporate a try/finally statement into a lambda. That's a language wart, no question. But that has nothing to do with list comprehensions. Comprehensions limit you to expressions and not statements just like lambdas.
With respect, I don't think you know what you're talking about here. I'm happy to discuss language design warts, including Python's, but I'd prefer to do so with people who, you know, know something about the subject.
So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution.
No, it doesn't. Anyone who told you so was fibbing. Perl's design allows you to add your own keywords to the language in such a way that the parser knows their arity and any contextual coercions--in other words, as if they were operators defined in the parser itself. This is rare (it doesn't happen often) and it's almost never ambiguous, but because the language used to define these custom keywords is Turing complete, it's possible to create pathological cases which depend on random factors to define a keyword in one of multiple ways...
... but no one ever does that except to prove that it's possible.
No, it doesn't. Anyone who told you so was fibbing. Perl's design allows you to add your own keywords to the language in such a way that the parser knows their arity and any contextual coercions--in other words, as if they were operators defined in the parser itself. This is rare (it doesn't happen often) and it's almost never ambiguous, but because the language used to define these custom keywords is Turing complete, it's possible to create pathological cases which depend on random factors to define a keyword in one of multiple ways...
... but no one ever does that except to prove that it's possible.
1. You really have no theories you want to share, about why we see this kind of trolls from Python people continuously?
>>Moreover, I've avoided making personal attacks on anyone.
I argued you wrote extreme flames about subjects you showed you didn't understand -- then claim to understand them. I call yet-another-Python-troll.
>>I don't think you understand the issue here.
You missed(?) my point: With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. It is there from inflexibility ("no braces!")
So, everything has warts(/tradeoffs), you flame about some that you obviously don't understand:
>> what benefits do we get from that decision?
You really see no possible benefit -- except in Common Lisp? -- from being able to modify the execution environment in code before running a program?
2. I gave the example -- to help with language extensions. No need for that in any environment...?
>>Moreover, I've avoided making personal attacks on anyone.
I argued you wrote extreme flames about subjects you showed you didn't understand -- then claim to understand them. I call yet-another-Python-troll.
>>I don't think you understand the issue here.
You missed(?) my point: With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. It is there from inflexibility ("no braces!")
So, everything has warts(/tradeoffs), you flame about some that you obviously don't understand:
>> what benefits do we get from that decision?
You really see no possible benefit -- except in Common Lisp? -- from being able to modify the execution environment in code before running a program?
2. I gave the example -- to help with language extensions. No need for that in any environment...?
You really have no theories you want to share
Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities.
With real inline lambdas and map, you don't need to create/teach list comprehensions Python style.
map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult?
Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program?
You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago.
like making syntax extensions easier
But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer.
Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?
Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities.
With real inline lambdas and map, you don't need to create/teach list comprehensions Python style.
map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult?
Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program?
You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago.
like making syntax extensions easier
But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer.
Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?
You really show your troll nature when you complain about "personal attacks" (being called troll) while doing two personal attacks yourself:
>>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities.
>>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult?
Thanks for a good laugh, troll.
>>Common Lisp offers more expressivity
You are arguing that the specific Common Lisp way is a better implementation of different execution phases.
Not relevant, as you know.
I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad.
So this is another point where you are shown to be trolling.
Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls.
I think I'll stop feeding you now. Please stop trolling on HN.
>>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities.
>>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult?
Thanks for a good laugh, troll.
>>Common Lisp offers more expressivity
You are arguing that the specific Common Lisp way is a better implementation of different execution phases.
Not relevant, as you know.
I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad.
So this is another point where you are shown to be trolling.
Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls.
I think I'll stop feeding you now. Please stop trolling on HN.
...which is why I build simple Tcl <--> C shims to C libraries and get on w/ enjoying my programming environment/experience.
His take on Larry Wall is terribly uncharitable:
First: Larry is insane. This means more to me than anything in the language itself. I prefer my heroes to have a firm grasp on sanity. I was never a fan of Don Quixote. Larry says God talks to him, and tells him that He hates non-Perl programmers. Larry is a fruit cake, a nut job, crazy as a loon, batty as a belfry.
Did you miss the fact that this is indeed a drunken rant?
Does that matter? Does being drunk make you uncharitable, or does it merely prevent you from controlling yourself before you announce it to the world?
Yes
Yegge "proved" someone insane literally by arguing as if a humorous speech was serious. If that isn't uncharitable or worse, I need a new dictionary.
Also, this is an old, old rant. It must have been posted multiple times with other URLs.
Also, this is an old, old rant. It must have been posted multiple times with other URLs.
Sorry, I thought we were talking about Yegge, I knew Wall's speech was not meant to be serious... wasn't sure about Yegge's post.
Drunken rant? He comes off as much more reasonable than Yegge. Which part is the drunken rant? I only skimmed the religious part because it doesn't interest me, but I have read much worse than this from both religious types and software prima donnas. This is mild.
OK, so he says stuff about his religious views. Not my cup of tea either but he doesn't come off as a jerk about it. And it's fair, IMO, for someone to say their religious views influence their work. That is up to them, their personal opinion. Just because I am not religious myself doesn't mean I have to trash him about it. (Hint: When he says he hears from God, I don't think that's literal.)
I'm wondering if both you and Yegge are misrecognizing some of his sarcasm? (I guess Yegge is probably also exaggerating the personal aspect for comedic effect.)
OK, so he says stuff about his religious views. Not my cup of tea either but he doesn't come off as a jerk about it. And it's fair, IMO, for someone to say their religious views influence their work. That is up to them, their personal opinion. Just because I am not religious myself doesn't mean I have to trash him about it. (Hint: When he says he hears from God, I don't think that's literal.)
I'm wondering if both you and Yegge are misrecognizing some of his sarcasm? (I guess Yegge is probably also exaggerating the personal aspect for comedic effect.)
OK, now I reread and I see the claim is that Yegge is drunk. Makes more sense now.
Did you read the speech as well? For example, he did quite literally liken Perl to a President and other languages as babies. The other pieces seemed about right but I admit I struggled mightily to follow that speech.
"First: Larry is insane."
As cdoxsey says, this as uncharitable, however it's not without a grain of truth. He's a bit of a loon, but a lovable loon.
That being said, what he helped add to the technology ecosystem is as important as GNU/Linux. Perl is remarkably expressive, and I've found in my 18 year IT career that no other single tool has paid me back as much for investing my energy into learning it, both in better "kung fu" (than you Ringo Langly), and also in plain old cash-money.
It's worth adding to your bag of tricks, even if you feel, as the article's author does, that the docs are unwieldy, the community is filled with zealots and cults of personality (to Larry himself, as well as to Merlyn and his ilk), and the syntax is irritating. It's still worth your time. If you invest enough in it to grok the language, you __WILL__ be a better overall developer.
As cdoxsey says, this as uncharitable, however it's not without a grain of truth. He's a bit of a loon, but a lovable loon.
That being said, what he helped add to the technology ecosystem is as important as GNU/Linux. Perl is remarkably expressive, and I've found in my 18 year IT career that no other single tool has paid me back as much for investing my energy into learning it, both in better "kung fu" (than you Ringo Langly), and also in plain old cash-money.
It's worth adding to your bag of tricks, even if you feel, as the article's author does, that the docs are unwieldy, the community is filled with zealots and cults of personality (to Larry himself, as well as to Merlyn and his ilk), and the syntax is irritating. It's still worth your time. If you invest enough in it to grok the language, you __WILL__ be a better overall developer.
"Every operator in Perl (not just the Range operator) has six different behaviors depending on the invisible context in which its surrounding expression is being evaluated."
... and unfortunately context sensitivity of operators became much more prevalent in Perl 6 than Perl 5. It was hard to imagine the core Perl maintainers thought that context sensitivity was a feature that needed further enhancement, but that's just what they did in Perl 6.
Programming language design comes down to one word: teamwork. Software is collaborative writing. The better languages allow teams of developers with mixed levels of skill to work together and be productive, to build on each other's code.
Perl 5 had enough quirks and cute context idioms to be clever and interesting, yet it was still possible to decipher what other coders had intended and learn a few new tricks along the way. Perl 6 is a toolkit for outright hostile obfuscation making it damn near impossible for a team of developers to wrap their heads around each others' code. Not surprisingly Perl is fading into the past.
... and unfortunately context sensitivity of operators became much more prevalent in Perl 6 than Perl 5. It was hard to imagine the core Perl maintainers thought that context sensitivity was a feature that needed further enhancement, but that's just what they did in Perl 6.
Programming language design comes down to one word: teamwork. Software is collaborative writing. The better languages allow teams of developers with mixed levels of skill to work together and be productive, to build on each other's code.
Perl 5 had enough quirks and cute context idioms to be clever and interesting, yet it was still possible to decipher what other coders had intended and learn a few new tricks along the way. Perl 6 is a toolkit for outright hostile obfuscation making it damn near impossible for a team of developers to wrap their heads around each others' code. Not surprisingly Perl is fading into the past.
> and unfortunately context sensitivity of operators became much more prevalent in Perl 6 than Perl 5.
What makes you think so? So far I was convinced of the exact opposite.
Examples:
* Perl 5 has the same operator for bitwise string AND and for bitwise integer AND. Perl 6 has separate operators, reducing context sensitivity.
* Perl 5's reverse() operator reverses lists in list context, and strings in scalar context. Perl 6 has separate verbs for these operations (reverse and flip), thus reducing context sensitivity
* In Perl 5, context flows inwards, so operator can actually be context sensitive in the classical sense. In Perl 6, operators know nothing about their caller, thus they cannot be context sensitive in the same crazy way that some Perl 5 operators are.
What makes you think so? So far I was convinced of the exact opposite.
Examples:
* Perl 5 has the same operator for bitwise string AND and for bitwise integer AND. Perl 6 has separate operators, reducing context sensitivity.
* Perl 5's reverse() operator reverses lists in list context, and strings in scalar context. Perl 6 has separate verbs for these operations (reverse and flip), thus reducing context sensitivity
* In Perl 5, context flows inwards, so operator can actually be context sensitive in the classical sense. In Perl 6, operators know nothing about their caller, thus they cannot be context sensitive in the same crazy way that some Perl 5 operators are.
fortunately, nobody is really using Perl 6. The perl community is continuing to support and evolve perl 5 in a reasonable direction.
>> Perl 6 is a toolkit for outright hostile obfuscation making it damn near impossible for a team of developers to wrap their heads around each others' code. Not surprisingly Perl is fading into the past.
I don't know enough about Perl 6 to comment on your opinions of it. I do find it really funny when you condemn a language (Perl) based on a very different language (Perl 6).
I guess you dislike C because C++ is overly complex, too...?
Edit: saraid216, I don't know if you troll or have no clue? Google. Most every source you'll find emphasize that Perl/Perl 6 should be seen as different languages.
I don't know enough about Perl 6 to comment on your opinions of it. I do find it really funny when you condemn a language (Perl) based on a very different language (Perl 6).
I guess you dislike C because C++ is overly complex, too...?
Edit: saraid216, I don't know if you troll or have no clue? Google. Most every source you'll find emphasize that Perl/Perl 6 should be seen as different languages.
> (Perl) based on a very different language (Perl 6)
Since when does a version increment make it a "very different language"?
How is it comparable between C and C++?
If anything, it's disliking C89 because of C90.
Since when does a version increment make it a "very different language"?
How is it comparable between C and C++?
If anything, it's disliking C89 because of C90.
Because it really is a seperate language. Going from Perl 5 to Perl 6 is like going from Algol to C++11
I like Perl. It's usually the fastest way to get stuff done. It also brings out the programmer within the programmer. Any jerk can write obfuscated Perl. A good Perl programmer writes clean, easily re-used and modified code. It's a very hacker friendly language.
As to its decrease in popularity, I'll point to two factors: (1) the rise of PHP, which took over most of the daily web-based tasks that Perl uses and (2) the rise of frameworks, which meant that people writing web sites were using newer languages so they didn't have to re-roll the basic stuff with each project. Perl didn't compete in that area until much later.
As far as its daily use, I still see it all the time and like many programmers, I implement new Perl code frequently. The flexibility across operating systems is a nice bonus.
For anyone who wants to see Perl written with grace and foresight, try these resources:
http://www.perlmonks.org/
http://www.pm.org/
As to its decrease in popularity, I'll point to two factors: (1) the rise of PHP, which took over most of the daily web-based tasks that Perl uses and (2) the rise of frameworks, which meant that people writing web sites were using newer languages so they didn't have to re-roll the basic stuff with each project. Perl didn't compete in that area until much later.
As far as its daily use, I still see it all the time and like many programmers, I implement new Perl code frequently. The flexibility across operating systems is a nice bonus.
For anyone who wants to see Perl written with grace and foresight, try these resources:
http://www.perlmonks.org/
http://www.pm.org/
I'm probably going to get downvoted for this, but...I actually really like writing Perl. It's fun, and even the documentation has character.
I rather enjoy reading and writing it.
I also rather enjoy the excellent career in the bay area that Perl has facilitated.
As I was preparing to leave my last job, I learned Python and Ruby. (I even uploaded a gem for the latter.) I like both of those languages, and I've been toying with them for many years, but my day job has always been Perl.
It didn't seem likely that my next day job would be Perl, at least based on what I keep 'hearing'.
Strangely enough, the perfect position for me turned out to be a bike ride from home. And in Perl.
And I am quite fine with that.
I also rather enjoy the excellent career in the bay area that Perl has facilitated.
As I was preparing to leave my last job, I learned Python and Ruby. (I even uploaded a gem for the latter.) I like both of those languages, and I've been toying with them for many years, but my day job has always been Perl.
It didn't seem likely that my next day job would be Perl, at least based on what I keep 'hearing'.
Strangely enough, the perfect position for me turned out to be a bike ride from home. And in Perl.
And I am quite fine with that.
That was a fun read from 2004, if largely irrelevant in 2013. Perl 6 finally has a stable release, but hardly anyone uses it. Perl will continue to have a place in UNIX sysadmin and quite a few hackers' toolkits for a while, but by now most new programmers are starting with Python or Ruby or even Javascript as their primary scripting language. New programmers are generally not learning Perl and haven't been for a while.
For reasons not completely unrelated to the rant.
Yeah. I think pg said it well:
Kevin Kelleher suggested an interesting way to compare programming languages: to describe each in terms of the problem it fixes. The surprising thing is how many, and how well, languages can be described this way.
[...]
Perl: Shell scripts/awk/sed are not enough like programming languages.
Python: Perl is a kludge.
Ruby: Perl is a kludge, and Lisp syntax is scary.
http://www.paulgraham.com/fix.html
Kevin Kelleher suggested an interesting way to compare programming languages: to describe each in terms of the problem it fixes. The surprising thing is how many, and how well, languages can be described this way.
[...]
Perl: Shell scripts/awk/sed are not enough like programming languages.
Python: Perl is a kludge.
Ruby: Perl is a kludge, and Lisp syntax is scary.
http://www.paulgraham.com/fix.html
Wait, awk is "not enough like a programming language"?!
Awk is a lovely little programming language... (rather lovelier than Perl if you ask me, though obviously less industrial-strength)
Awk is a lovely little programming language... (rather lovelier than Perl if you ask me, though obviously less industrial-strength)
The issue was that none of the trio of shell scripts/awk/sed could stand alone, so the "language" by necessity consisted of all three tools. You'd write the main loop in shell and use awk and sed when required.
Remember, this was 1987—25 years ago, before bash and other modern shells, and with much more primitive versions of awk and sed. Nor was the web available to look things up.
Writing shell/awk/sed scripts back then was awful, no matter how much the Bell Labs folks touted its superiority.
When perl showed up on comp.sources.unix it was an incredible breath of fresh air. I downloaded and built perl based on its claim to replace shell script/awk/sed programming and Larry Wall's reputation as the author of rn [1], my preferred newsreader for usenet. Perl lived up to its billing and was an enormous improvement for writing scripts.
[1] http://en.wikipedia.org/wiki/Rn_%28newsreader%29
Remember, this was 1987—25 years ago, before bash and other modern shells, and with much more primitive versions of awk and sed. Nor was the web available to look things up.
Writing shell/awk/sed scripts back then was awful, no matter how much the Bell Labs folks touted its superiority.
When perl showed up on comp.sources.unix it was an incredible breath of fresh air. I downloaded and built perl based on its claim to replace shell script/awk/sed programming and Larry Wall's reputation as the author of rn [1], my preferred newsreader for usenet. Perl lived up to its billing and was an enormous improvement for writing scripts.
[1] http://en.wikipedia.org/wiki/Rn_%28newsreader%29
Hmm, I used awk in 1987, and it was just fine... it really hasn't changed all that much since. "nawk" ("new awk") vs. "awk" was an issue, with the former being preferable (I don't recall why offhand, other than it seemed a lot less buggy), but even that dated from the mid-'80s.
Perl certainly offered new functionality, but it felt palpably kludgier than awk. The idea that it was some sort of giant advance over awk was rather overplayed, especially within awk's domain, where awk's cleaner language design and more focused features were real advantages over perl. [When perl first showed up, I remember thinking how churlish its "a2p" script was... who'd want to switch to perl, given a working awk program?!]
Perl certainly offered new functionality, but it felt palpably kludgier than awk. The idea that it was some sort of giant advance over awk was rather overplayed, especially within awk's domain, where awk's cleaner language design and more focused features were real advantages over perl. [When perl first showed up, I remember thinking how churlish its "a2p" script was... who'd want to switch to perl, given a working awk program?!]
I'm not terribly familiar with awk, but it seems very useful. My understanding is that it lacks a lot of the features that people expect from a modern, general-purpose programming language (not that it can't be or hasn't been done--but you're probably not going to be writing a web server in awk for example), but also that awk has been improved significantly since the mid 80s when Larry Wall decided to create perl as basically "a better awk." But awk is definitely very good in its niche, which is processing text data.
I expect he means that awk may seem more like a DSL than a full-fledged language, even though/if it's possible to use it like a programming language. (Another example may be that it wasn't really intended to be a general-purpose language, IIRC that chapter in Masterminds of Programming.)
I don't know that anyone necessarily believes you couldn't program with awk in an absolute sense, but it doesn't read like a glorified shell script in the way that perl is explicitly designed to.
I don't know that anyone necessarily believes you couldn't program with awk in an absolute sense, but it doesn't read like a glorified shell script in the way that perl is explicitly designed to.
I didn't realise it was from 2004 until I got to the bottom (although I did wonder if he meant "In the fifteen years since Perl 5").
>You see, someday I will start my own company, and I'll decide my own hiring bar.
Yes, meanwhile people using Perl succesfully should care, because?
Yes, meanwhile people using Perl succesfully should care, because?
I'll summarize the article:
1) He hates Larry, therefore we should all hate Larry's language.
2) He looked in the official detailed technical docs when he was looking for a "learning..." book or a "... for dummies" book. By analogy he was looking for dietel and dietel but when he picked up stroustrop his eyes started burning.
3) He hates the idea that references exist and some people like them and use them. Although you don't have to use them, at all. Also if you insist on implementing your own object oriented design the slow hard way by hand using references instead of "use Moose;" like a normal person, its hard and slow just the way you asked for it, instead of being made impossible.
4) He doesn't like the large number of features. He especially dislikes the single/double character magic variables. Some of them take as much as 30 seconds with google to learn and use!
5) Strange rant about lego as a programming language analogy, which boils down to much like lego, languages should have just a handful of fully understood small pieces that hurt your feet when stepped on barefooted; You must fully understand all (few) language features before programming. I think he's calling for the return of Basic Assembly Language on a S/360 mainframe, or perhaps a more RISC alternative like enterprise grade 6502 machine code.
Its a weird essay. I think its a parody of the recent spat of perl-hate.
1) He hates Larry, therefore we should all hate Larry's language.
2) He looked in the official detailed technical docs when he was looking for a "learning..." book or a "... for dummies" book. By analogy he was looking for dietel and dietel but when he picked up stroustrop his eyes started burning.
3) He hates the idea that references exist and some people like them and use them. Although you don't have to use them, at all. Also if you insist on implementing your own object oriented design the slow hard way by hand using references instead of "use Moose;" like a normal person, its hard and slow just the way you asked for it, instead of being made impossible.
4) He doesn't like the large number of features. He especially dislikes the single/double character magic variables. Some of them take as much as 30 seconds with google to learn and use!
5) Strange rant about lego as a programming language analogy, which boils down to much like lego, languages should have just a handful of fully understood small pieces that hurt your feet when stepped on barefooted; You must fully understand all (few) language features before programming. I think he's calling for the return of Basic Assembly Language on a S/360 mainframe, or perhaps a more RISC alternative like enterprise grade 6502 machine code.
Its a weird essay. I think its a parody of the recent spat of perl-hate.
> Although you don't have to use them, at all. Also if you insist on implementing your own object oriented design the slow hard way by hand using references instead of "use Moose;" like a normal person, its hard and slow just the way you asked for it, instead of being made impossible.
If you are a perl programmer, you have to know and use references(pass hash, pass array with other params, nested data structures...). "you don't have to use them" is true in the sense that you don't have to use anything - you don't have to use lists, hashes, OOP, what have you. The same goes for OOP. Moose is an option for new code, not for code which has been written with blessed references.
I don't have anything against references; I do have something against using references and de-references for nested data structures and passing data structures to functions. Yes, I do understand references, but I will take the way Python and Ruby make do without references over Perl's references any day.
If you are a perl programmer, you have to know and use references(pass hash, pass array with other params, nested data structures...). "you don't have to use them" is true in the sense that you don't have to use anything - you don't have to use lists, hashes, OOP, what have you. The same goes for OOP. Moose is an option for new code, not for code which has been written with blessed references.
I don't have anything against references; I do have something against using references and de-references for nested data structures and passing data structures to functions. Yes, I do understand references, but I will take the way Python and Ruby make do without references over Perl's references any day.
"not for code which has been written with blessed references."
Thanks for pointing that out, it is an unfair article because the whole premise of the parody was if the author was running a blue sky startup... so legacy code sucks is not much of an argument.
Some time ago I reflexively converted everything perl OO that I touched to "modern" Moose and it seems to have been worth it. Detection of non-Moose OO should be a Perl::Critic complaint. You can always add something to the exclude= line in a perlcritic.rc file. We've already got Perl::Critic::Tics and ::Lax and a bunch others, so ::FanOfMoose to complain about non-Moose OO is within the realm of possibility.
Thanks for pointing that out, it is an unfair article because the whole premise of the parody was if the author was running a blue sky startup... so legacy code sucks is not much of an argument.
Some time ago I reflexively converted everything perl OO that I touched to "modern" Moose and it seems to have been worth it. Detection of non-Moose OO should be a Perl::Critic complaint. You can always add something to the exclude= line in a perlcritic.rc file. We've already got Perl::Critic::Tics and ::Lax and a bunch others, so ::FanOfMoose to complain about non-Moose OO is within the realm of possibility.
5) Strange rant about lego as a programming language analogy, which boils down to much like lego, languages should have just a handful of fully understood small pieces that hurt your feet when stepped on barefooted; You must fully understand all (few) language features before programming. I think he's calling for the return of Basic Assembly Language on a S/360 mainframe, or perhaps a more RISC alternative like enterprise grade 6502 machine code.
Rather, he's arguing for a modern Lisp.
I've never stepped on parens while barefoot, though, so I can't speak to whether it'd hurt as much as lego.
Rather, he's arguing for a modern Lisp.
I've never stepped on parens while barefoot, though, so I can't speak to whether it'd hurt as much as lego.
Not recent. It appears to be a repost from 2004.
Language haters are only marginally less grating than language fanbois, who in turn are slightly less annoying than functional language fanbois.
Not a particularly enlightening - or for that matter, accurate or representative - opinion piece.
Not a particularly enlightening - or for that matter, accurate or representative - opinion piece.
Many Unix systems include Perl by default. This seems like a small thing, but in areas where 3rd-party software is not allowed (security and audit compliance issues), having a Perl interpreter is wonderful.
However, the base install of perl should be used for system maintenance only and not used for general purpose apps as
the base install is just so old (5.8) that its a security hole. Installing a newer version is easy and can be updated independently of the system perl without breaking anything.
They include Perl, but do they include a Perl that is compatible with and has been tested with the code that you're trying to run?
http://steve-yegge.blogspot.in/2006/10/egomania-itself.html
Here he talks a bit about the perl community
Here he talks a bit about the perl community
the existence of a language should not be a threat, its ok for you to move on from Perl.
Here's why Perl is great: http://www.foo.be/docs/tpj/issues/vol1_1/tpj0101-0002.html
Steve wrote this before Clojure came out! I wonder what Steve thinks of it. I have done some work in it and it seems really quite good for Real Projects (tm).
Steve seemed to start out really liking clojure, but the more he used it, the more gripes he seemed to have: https://groups.google.com/forum/#!msg/seajure/GLqhj_2915A/f-...
"It’s an astoundingly high-quality language, sure—in fact, I’m beginning to think it’s the best I’ve ever seen" [http://joyofclojure.com/foreword/]
As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl. Well, almost.
http://steve-yegge.blogspot.com/2006/10/egomania-itself.html