On 2/14/07, Bryan Sant wrote:
Contrary to popular belief, I'm not a complete and total Java bigot... Okay, I lied, I am. Java is the shiz-nigget. However, I'm honestly wanting to invest in a new language for fun and profit.
Good for you. I have several languages under my belt, and am always interested in learning another. Granted, this has led me down some dark roads in the past...
I'd like to learn one of the following well: Python, Ruby, or Perl.
A decent selection to choose from.
Here are my problems with each language respectively: Ruby. You'd think this one would be a slam dunk for me. It's OO, it's hip, it gets all the press. But Ruby is the SLOOOOOOOOOOOOoooooooooooowest freaking language ever invented.
No, that would be either Wierd or a Funge. But you're talking about languages that have some prayer of becoming mainstream, I imagine. My biggest beef with Ruby is its conditional expression. Seriously, any language in which the number zero is *true* deserves a slap in the face. Second-biggest beef: Everyday code snippets, those used as examples of its expressiveness and power even, use crazy symbols that mean nothing to the outside observer. I had to dig to figure out what the @ symbols were doing, and the pipes around the block argument list aren't exactly intuitive. Third-biggest beef: The === operator, which I first encountered as identity in PHP, is some sort of tripped-out range or loose-equality thing, and automatically called by the case statement. I don't even want to touch the thing, particularly since it feels backwards. On the other hand, I wouldn't object to using Ruby for an established project, if there were plenty of money involved.
Perl. I like the fact that Perl is everywhere. You can't swing a dead cat by the tail without hitting into a Perl interpreter. I like that Perl is mature. One word, CPAN. All of this is great, but I DON'T like the whole, "there's more than one way to do it" deal.
I learned Perl for my first job, and it's still where I turn when I have some text processing that's too big for a shell script with grep and sed, but small enough to handle within a few hundred lines of code. That said, I refuse to use it for anything major, simply because I've looked at some of my old scripts and went "Huh?" Hint: If it uses more than one CPAN package, it's too big. I also don't like that it has been non-portable: I've had scripts work on one system, but not on another, particularly if they do anything with threads. This was brought to the fore by a recent project, in which I was using Perl as a text interface to an asynchronous network protocol. That required both input and output loops, which I put in different threads. Then I switched to a different flavor of Linux, on the same machine even, and the script refused to run because Perl had been compiled differently. It also refuses to run on Windows. You mentioned that you've had experience with it, particularly related to shell scripting. As long as you're comfortable with regular expressions, I don't imagine you really need to dig deeper.
Python. Python is the front runner for me.
I learned Python on a project related to the above Perl script, and absolutely fell in love. My project implements a server for an environment that used a published network protocol, but for which the reference and only extant server was a Windows binary. (The fact that an Erlang server was released as open source before I released mine is completely irrelevant.) I love the way it reads so easily, so much like pseudocode. The syntactical whitespace helps with this. So does the fact that a type can be used as a function, and the fact that a function can be passed around and stored like any other type of data. I love the way it makes development quick. I had something up and running within a few days, and a fairly complex system complete and verified within a few months. The introspection and docstring conventions have helped tremendously. I love the testing frameworks. I started out with docstring test cases, then when I saw how well they worked, and needed a bit more power to run groups of serious test cases, moved up to the unittest package shipped with Python. It is marvelous to be able to poke into a class's guts and make it use harnesses when necessary. Granted, this has been my only real experience with unit tests, but it has been wonderful to know immedieately when my changes have caused undesired side effects. I love the way it lets me be as object-oriented as I want to. The bulk of my project uses objects and classes that talk to each other, get stored and passed around, and converted into strings or lists of integers as necessary. However, I have a set of utility functions that don't need to be in a class, just living in their own file. I have also found myself using metaclasses to make certain things easier. I love the fact that you don't need getters and setters. Just referring to the variable itself is much cleaner. For the cases where they're actually useful, properties make it easy to call a function on access, without changing any of the accessing code. For example, I found a case where startup was being slowed down by unnecessary file reads; in that case, it was most convenient to have a property read the file and compute the requested variable the first time, then store the result as itself so future accesses would avoid calling the property function. An available job opportunity has convinced me to start using PHP again, and every week I find something new to miss about Python. The consistency of argument order, the distinction between list and dict, the ease of string multiplication, the list goes on...
Please advice.
<nitpick>I think you mean "advise" here.</nitpick> At any rate, I hope I've made my position clear. - Eric /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
