I want to learn a new language...

Eric Wald eswald at brainshell.org
Thu Feb 15 17:17:23 MST 2007


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



More information about the PLUG mailing list