Date: 8/7/2008 5:23 am
Rating: 0
http://en.wikipedia.org/w/index.php?title=Template:POTD/2008-08-07
- busy day!)
Sent to you by afbach via Google Reader:
I noticed a discussion about Perl on Hacker News this morning. The linked article is about why the author likes Perl. As with all articles of this type, it attracted the usual "Ruby is better!!" comments. The Hacker News discussion is slightly more intelligent, arguing that Perl is ugly, that the article's author "gave up on Ruby too soon", and that regular expressions are slow (as though that has something to do with Perl). Anyway, I thought I would address these points, and share with you why I think you should use Perl.
The first thing that you should realize when thinking about any programming language, Perl included, is that it sucks. It has tons of engineering trade-offs that you wouldn't have made, but you're stuck with them anyway. For example, the perl core is filled with legacy crap that doesn't work right and can never be fixed, for compatibility reasons. It trades correctness for compatibility. I would never do that, but I don't get to make that decision, because Perl is not my project. I could go on and on about what I don't like about Perl; trust me, there are hundreds of things that I absolutely hate and that make me want to cry -- but that's not the point of this article.
Every other language I've used has sucked just as badly as Perl. I really like Lisp, I think it's exactly the way a programming language should work. Provide the minimum, and let me build the rest. That way I will always be happy. But why did Common Lisp need to build in at least 3 separate ways to map keys to values (getf, assoc, and hash tables)? The answer is because the language designers wanted all three. Again, not my project... so I don't get to make the decisions. I can either live with them, choose another set of compromises that I don't really like (another language), or make my own language, which is yet another compromise. None are ideal. No language is perfect. No language you build yourself will be perfect, unless you have infinite time to write all the libraries that the non-perfect language already had. Tradeoffs, tradeoffs, tradeoffs. That's what engineering is.
So hopefully by now, you've thought of some reasons why you don't like your language of choice. If you haven't, it's because you haven't used it enough, and you aren't really in a good position to recommend or criticize programming languages. It took me a long time to realize that Perl isn't perfect. Before then, I just told everyone it was the greatest thing, and they probably laughed at me for being a shill fanboi. Now that I've grown up a bit, I can think rationally about programming languages. Hopefully, you can too.
Anyway, think about those features in your language that you hate, that really make you think "how could someone have been so dumb as to do it this way!" Think about the features from other languages that you love but are missing from your favorite. Really; do it. Don't you wish that Common Lisp had continuations? Don't you wish that Python executed faster?
With those reasons in mind, I think you'll find that they don't really stop you from solving problems. If the problems made you seriously unproductive, you would have switched languages long before you gave those problems a second thought. Features that you think are harmful, you can simply not use. Features that don't exist can probably be emulated. (Python doesn't have lexical closures like Perl's, but you can emulate them with a class. Problem solved.) The end result is that the syntax and implementation compromises of your language don't really matter much. You call some functions, make some classes, throw in a dash of builtins, and your problem is solved. Yeah, maybe the syntax is ugly. But now you are rich and famous and can move on to problem number n plus one!
As you can see, real programs are rarely about syntax. If you need to speak HTTP, no awesome language feature is going to do that for you. Even if your language has The Perfect Featureset, writing an HTTP header parser is going to be a waste of your time. Libraries are the key to productivity; ignoring one piece of syntax you don't like is going to be a lot faster than reading the HTTP spec, implementing it, and testing it.
That's why libraries are important, they let you spend your time solving problems that haven't been solved instead of reinventing the wheel. If you don't have good libraries, you can't write good software.
As an example, the software that runs this blog (Angerwhale) uses 212 different Perl modules. If I had to write all that code myself, there would be a lot less functionality. And before you make fun of me for needing all those libraries "just for a blog", please think about all the complexity that you don't see. Some things that go on under the covers include working with posts encoded in any character encoding, supporting different rich text formats, computing the MD5 sum of the post for the HTTP ETag header, handing filesystem paths in a cross-platform manner, parsing the configuration file, reading PGP signatures, etc. It adds up fast. Without libraries, I would have a lot less features, or a broken piece of crap that kind-of-sort-of-okay-maybe-not works. (Incidentally, PHP doesn't have very many libraries...)
I am convinced that the Perl community knows libraries better than anyone else. We have the CPAN, with tens of thousands of distributions that already exist. Ten thousand is hard to comprehend, but try searching for your favorite programming topic on search.cpan. You will probably find that your problem has been solved in an easily-digestible library form. Clicking a few links just saved you from a week of coding.
The important thing about Perl is that we have a culture of writing good libraries. No Perl programmer would write a few lines of code, post it to a blog, and call it a "library". Everyone feels obligated to create a CPAN distribution, with documentation (sometimes a bit on the minimal side, but not everyone is a writer), a test suite, a Makefile, etc. I'm not sure why, but this always happens. I think it's because there is a strong convention, and tools that make following the convention easy.
The existence of libraries make writing more libraries even easier. So the cycle feeds itself; we have a lot of libraries, that makes writing another library easier, now we have more, writing another library is even easier... and before you know it, we have more than anyone can imagine.
I've looked at other languages, and the communities just aren't like Perl. They set up sites for sharing libraries, but nobody contributes. Sure, RubyForge has a some libraries. PEAR has a few. Python has a lot. But there is no culture of writing or using libraries, and most people end up with a library or two next to some wheel reinvention and cut-n-paste code. (Search for "rails". Most of these programmers will depend on one library, Rails, but then get the rest of their code by cutting-and-pasting from blogs.) These people don't really understand libraries, and won't bother writing any themselves. As people continue to not write libraries, there continue to not be any libraries. Perl's huge number of libraries makes it easy to write more; the other languages' lack of libraries makes it hard to write more. So I don't think Ruby is going to magically have tens of thousands of libraries in another few years; they are going to keep doing what they're doing now. (Hopefully I don't need to explain why a packaging system and central library repository is a better strategy than cutting and pasting from blogs.)
The C community has also failed to understand libraries. It has a few, like GTK+, but most C programmers don't think about libraries when they are programming. I don't blame them; with no way to declare dependencies in your code, no namespaces, and no out-of-band error signaling, using and writing libraries is a horrific nightmare. I'm surprised that there are as many libraries as there are.
But it irritates me when I need to get at gpg from a web application, and can't just use a "libgpg". I have to fork a gpg process, setup file descriptors just right, write input to a pipe, wait for input on another pipe, and then parse the result -- all for what amounts to a few XOR operations and bit shifts. How could anyone think this is a good idea? (There is libgpgme, but this just hides the fork inside a library. There is still tons of totally unnecessary work going on.)
Git is similarly bad. If a programmer that had a culture of using and writing libraries wrote Git, most of Git would be classes that thin command-line scripts instantiated and mutated according to command-line arguments. There would be no important code in the scripts, only in the easily-reusable classes. This would make using git from another program trivial; just create an instance of the class, call a method, and you're done! Instead, since the C programmers never thought that anyone would need a library, you have to fork and exec a binary that returns the data you want in a custom format, that you then have to write a parser for. Great idea, guys. (Even git-fast-import, the easiest possible thing to make into a library, is just a big old monolithic binary. You have to learn a "simple" new language just to talk to it. Who thought that was a good idea!?)
So finally to the conclusion. If you are like me, most programming you do is about gluing things together with libraries. Perl may not be the prettiest language, but we have so many libraries that you won't have much time to see the ugliness. This is the reason why people stick with Perl, even though other languages have prettier syntax. It is so easy to get stuff done, and contribute your "stuff" back to the community, that we never even worry about the ugly syntax. It just goes away, and all we think about are solving our problems.
Things you can do from here:
- Subscribe to Planet Perl using Google Reader
- Get started using Google Reader to easily keep up with all your favorite sites
Date: 8/7/2008 7:54 am
Rating: 0
JT
afbach wrote:
Nice article - found by Don (right after the spinning woman picture
http://en.wikipedia.org/w/index.php?title=Template:POTD/2008-08-07
- busy day!)
Sent to you by afbach via Google Reader:
via Planet Perl on 8/4/08I noticed a discussion about Perl on Hacker News this morning. The linked article is about why the author likes Perl. As with all articles of this type, it attracted the usual "Ruby is better!!" comments. The Hacker News discussion is slightly more intelligent, arguing that Perl is ugly, that the article's author "gave up on Ruby too soon", and that regular expressions are slow (as though that has something to do with Perl). Anyway, I thought I would address these points, and share with you why I think you should use Perl.
The first thing that you should realize when thinking about any programming language, Perl included, is that it sucks. It has tons of engineering trade-offs that you wouldn't have made, but you're stuck with them anyway. For example, the perl core is filled with legacy crap that doesn't work right and can never be fixed, for compatibility reasons. It trades correctness for compatibility. I would never do that, but I don't get to make that decision, because Perl is not my project. I could go on and on about what I don't like about Perl; trust me, there are hundreds of things that I absolutely hate and that make me want to cry -- but that's not the point of this article.
Every other language I've used has sucked just as badly as Perl. I really like Lisp, I think it's exactly the way a programming language should work. Provide the minimum, and let me build the rest. That way I will always be happy. But why did Common Lisp need to build in at least 3 separate ways to map keys to values (getf, assoc, and hash tables)? The answer is because the language designers wanted all three. Again, not my project... so I don't get to make the decisions. I can either live with them, choose another set of compromises that I don't really like (another language), or make my own language, which is yet another compromise. None are ideal. No language is perfect. No language you build yourself will be perfect, unless you have infinite time to write all the libraries that the non-perfect language already had. Tradeoffs, tradeoffs, tradeoffs. That's what engineering is.
So hopefully by now, you've thought of some reasons why you don't like your language of choice. If you haven't, it's because you haven't used it enough, and you aren't really in a good position to recommend or criticize programming languages. It took me a long time to realize that Perl isn't perfect. Before then, I just told everyone it was the greatest thing, and they probably laughed at me for being a shill fanboi. Now that I've grown up a bit, I can think rationally about programming languages. Hopefully, you can too.
Anyway, think about those features in your language that you hate, that really make you think "how could someone have been so dumb as to do it this way!" Think about the features from other languages that you love but are missing from your favorite. Really; do it. Don't you wish that Common Lisp had continuations? Don't you wish that Python executed faster?
With those reasons in mind, I think you'll find that they don't really stop you from solving problems. If the problems made you seriously unproductive, you would have switched languages long before you gave those problems a second thought. Features that you think are harmful, you can simply not use. Features that don't exist can probably be emulated. (Python doesn't have lexical closures like Perl's, but you can emulate them with a class. Problem solved.) The end result is that the syntax and implementation compromises of your language don't really matter much. You call some functions, make some classes, throw in a dash of builtins, and your problem is solved. Yeah, maybe the syntax is ugly. But now you are rich and famous and can move on to problem number n plus one!
As you can see, real programs are rarely about syntax. If you need to speak HTTP, no awesome language feature is going to do that for you. Even if your language has The Perfect Featureset, writing an HTTP header parser is going to be a waste of your time. Libraries are the key to productivity; ignoring one piece of syntax you don't like is going to be a lot faster than reading the HTTP spec, implementing it, and testing it.
That's why libraries are important, they let you spend your time solving problems that haven't been solved instead of reinventing the wheel. If you don't have good libraries, you can't write good software.
As an example, the software that runs this blog (Angerwhale) uses 212 different Perl modules. If I had to write all that code myself, there would be a lot less functionality. And before you make fun of me for needing all those libraries "just for a blog", please think about all the complexity that you don't see. Some things that go on under the covers include working with posts encoded in any character encoding, supporting different rich text formats, computing the MD5 sum of the post for the HTTP ETag header, handing filesystem paths in a cross-platform manner, parsing the configuration file, reading PGP signatures, etc. It adds up fast. Without libraries, I would have a lot less features, or a broken piece of crap that kind-of-sort-of-okay-maybe-not works. (Incidentally, PHP doesn't have very many libraries...)
I am convinced that the Perl community knows libraries better than anyone else. We have the CPAN, with tens of thousands of distributions that already exist. Ten thousand is hard to comprehend, but try searching for your favorite programming topic on search.cpan. You will probably find that your problem has been solved in an easily-digestible library form. Clicking a few links just saved you from a week of coding.
The important thing about Perl is that we have a culture of writing good libraries. No Perl programmer would write a few lines of code, post it to a blog, and call it a "library". Everyone feels obligated to create a CPAN distribution, with documentation (sometimes a bit on the minimal side, but not everyone is a writer), a test suite, a Makefile, etc. I'm not sure why, but this always happens. I think it's because there is a strong convention, and tools that make following the convention easy.
The existence of libraries make writing more libraries even easier. So the cycle feeds itself; we have a lot of libraries, that makes writing another library easier, now we have more, writing another library is even easier... and before you know it, we have more than anyone can imagine.
I've looked at other languages, and the communities just aren't like Perl. They set up sites for sharing libraries, but nobody contributes. Sure, RubyForge has a some libraries. PEAR has a few. Python has a lot. But there is no culture of writing or using libraries, and most people end up with a library or two next to some wheel reinvention and cut-n-paste code. (Search for "rails". Most of these programmers will depend on one library, Rails, but then get the rest of their code by cutting-and-pasting from blogs.) These people don't really understand libraries, and won't bother writing any themselves. As people continue to not write libraries, there continue to not be any libraries. Perl's huge number of libraries makes it easy to write more; the other languages' lack of libraries makes it hard to write more. So I don't think Ruby is going to magically have tens of thousands of libraries in another few years; they are going to keep doing what they're doing now. (Hopefully I don't need to explain why a packaging system and central library repository is a better strategy than cutting and pasting from blogs.)
The C community has also failed to understand libraries. It has a few, like GTK+, but most C programmers don't think about libraries when they are programming. I don't blame them; with no way to declare dependencies in your code, no namespaces, and no out-of-band error signaling, using and writing libraries is a horrific nightmare. I'm surprised that there are as many libraries as there are.
But it irritates me when I need to get at gpg from a web application, and can't just use a "libgpg". I have to fork a gpg process, setup file descriptors just right, write input to a pipe, wait for input on another pipe, and then parse the result -- all for what amounts to a few XOR operations and bit shifts. How could anyone think this is a good idea? (There is libgpgme, but this just hides the fork inside a library. There is still tons of totally unnecessary work going on.)
Git is similarly bad. If a programmer that had a culture of using and writing libraries wrote Git, most of Git would be classes that thin command-line scripts instantiated and mutated according to command-line arguments. There would be no important code in the scripts, only in the easily-reusable classes. This would make using git from another program trivial; just create an instance of the class, call a method, and you're done! Instead, since the C programmers never thought that anyone would need a library, you have to fork and exec a binary that returns the data you want in a custom format, that you then have to write a parser for. Great idea, guys. (Even git-fast-import, the easiest possible thing to make into a library, is just a big old monolithic binary. You have to learn a "simple" new language just to talk to it. Who thought that was a good idea!?)
So finally to the conclusion. If you are like me, most programming you do is about gluing things together with libraries. Perl may not be the prettiest language, but we have so many libraries that you won't have much time to see the ugliness. This is the reason why people stick with Perl, even though other languages have prettier syntax. It is so easy to get stuff done, and contribute your "stuff" back to the community, that we never even worry about the ugly syntax. It just goes away, and all we think about are solving our problems.
Things you can do from here:
- Subscribe to Planet Perl using Google Reader
- Get started using Google Reader to easily keep up with all your favorite sites
