RSS Feed

The Joel on Software Discussion Group (CLOSED)

i am willing to learn a new programming language. due to the vast credit they're receiving from programmers, i'm hesitating between perl and python. i tend to favor languages that dont deal with low level stuff too much ( C does), languages that offer goood IDE, lot of documentation on internet ...  which one should i learn ???

Learn them both, they are different from each other enough that you will not confuse the two. It takes me some time to switch my gears between C# and Java because they are so alike. While it takes me no time to switch between Python and C# or Java and VB.

It is easy to pick up a language itself, you should be able to do it quickly. The hard part comes in mastering the nuances of the language and especially the APIs of the most used libraries.

perl is a funny looking beast, you will curse it's syntax at first, but if you can get past that you may learn to love it. It is reidiculously powerful and versatile, and the modules available for free are so many it's just silly.

Definitely Python if I had to choose.  Ask yourself which language would you rather maintain the code of which was written by other programmers.  Perl will make you vomit whenever you have to debug or modify other people's code.

but perl is perhaps more powerful in terms of regular expressions support + more adapatable to programs that are small in size. isn't it ?

Why not learn Ruby? It was inspired by both Perl and Python.

maybe ruby is being ruled out cause its still in the niche programming market; there is definnitely less content on ruby then the other 2 languages

I think you should learn Python, go to http://www.diveintopython.org and start learning.

Why? Perl is only useful if you plain to repair old code written in perl, but it is very difficult to read a perl code somebody else has written so what is perl good for now a day??

People often talk about regular expressions as if regular expressions have been invented with perl...

Personally I've chosen to be proficient in perl rather than python, first.  My reasoning is in the power of the language, which is what inspires the "but do you want to support it" caveats, the closeness of Perl and regular expressions (it seems like to really leverage perl well you've *got* to know how to use regex well =~), and the perl community which seems to consist of really good, productive, off-beat people.

I've dabbled with Python, and I'll probably attempt to do meaningful things with it after I've mastered Perl.

In my experience it's easier to do OO stuff in Python than Perl. It's easier to do text processing in Perl than Python.

Perl = D10 Cat which you can keep in your pocket
Python = ???

I have had to pick up and work with other people's code in perl, and it has not been that bad. Maybe I was just lucky ...

Easier to do one liners in Perl
Much easier to writefull applications in Python.
If you do want to build apps look at wxPython. Very MFC like gui library for python.

if you want to write stuff you used to do in awk and sed, learn perl

if you want to write maintainable applications in an OO style, learn python

I second John Topley to take a look at Ruby, especially the Ruby on Rails if you haven't looked at it. They are doing some very cool stuff over there, and I think they'll break the niche status very quickly (they already have in my book)

However, having looked over Perl and Python - Perl is an amazing language. The ways people can twist and turn it still make me shake my head. But it's darn good at what it is meant for.

I've played with Python a little bit, and personally prefer Ruby.

"Why? Perl is only useful if you plain to repair old code written in perl, but it is very difficult to read a perl code somebody else has written so what is perl good for now a day??"

On the contrary, my current job, my last job, skip one, and the one before that, those three were all perl programming positions.  The first one was parsing logs and writing reports, the second was a huge e-commerce system that processes millions each year, and my current job is at a biotech company - we write software that interfaces with DNA sequencing machines and manages their data.

Perl definitely wasn't originally designed to be object-oriented, and if you have a problem with some silly syntax, stay away, but the power of perl more than makes up for it's problems in my opinion.

People write crappy spagetti code in all languages.  Perl makes it easier than most.  On the other hand, perl also makes it easier than most to write clear, concise code that gets the job done with a minimum of effort.  CPAN also provides about a zillion free modules that will do anything under the sun (almost...).

> Why not learn Ruby? It was inspired by both Perl and Python.

According to Eric Levenez (http://www.levenez.com/lang/) Ruby was a convergence of Perl, Python, Eiffel, Samlltalk and CLU (a Pascal derivative). Print out the timeline chart. The relationships between the various languages is very instructive.

"People write crappy spagetti code in all languages."

True.  It's a question of what proportion of programmers in a language write crappy spaghetti code.  I've seen more crappy spaghetti perl than I've seen crappy spaghetti Java or even C++, and let me tell you, I've seen a LOT of crappy spaghetti C++.

"On the other hand, perl also makes it easier than most to write clear, concise code that gets the job done with a minimum of effort."

So it is often claimed.  If I ever actually get to set eyes on any of this "clear, concise code", I may even come to believe it.

Right now, my response to this assertion is "if perl makes it easier than most, then why the hell doesn't anyone DO IT?"

As it is, it seems the smartest perl hackers spend all their time deliberately trying to think up cleverer and cleverer ways of obfuscating their code.  Contrast this with languages like Haskell, Ruby, or Python, where the time and effort goes into making code clearer, and see if you can work out why perl has such a bad reputation...

and what kind of tools/IDE do u use when writing perl

Like most open source language, I have yet to find a good comprehensive IDE.  The best I've found is UltraEdit for windows, which has a good perl syntax highlighter.  Even then I've found some regexes screw up the highlighting.

Dont listen to the perl naysayers.  Perl looks like line noise when you first learn it, but it grows on you until it becomes your favorite language.  There is just something *right* about how it feels and works.  The amount of bad code is a reflection of how large the community of perl developers is.  There are plenty of good perl programmers out there writing easy to maintain, scalable code running on __very__ large systems.

+1 for Cory's post.

We also use Ultraedit for all our Perl development.  I'd also recommend ActiveState's Perl Development Kit for a nice graphical debugger, it doesn't always work quite right, but it's a lot easier than the debugger that ships with the distribution.

And he's spot on when he says that Perl feels *right*.  I'd amplify that by saying it feels *natural*.

That said, it's not a very strict language (how many parameters does that function take anyway?), and I've yet to figure out half the code posted by obfuscating Perl geniuses.  But, it doesn't take long before you're comfortable reading the ASCII soup that is typical Perl code.

In my shop we use both C++ and Perl (along with a few other languages).  C++ is elegant in it's own way, and well suited for what we use it for, but given half a chance, the developers would do everything in Perl if they could.

I can't compare it to Python, having never used it myself, but Perl is a terrific language well worth the effort in learning.  And it is very easy to write large-scale software as long as you insist on rigorous development practices.

Perl is a great language. I used it for several years.

But personally, my programming philosophy is more in line with that of Python.

The perl community believes strongly that there should be "more than one way to do things". So, the following all mean the same thing in perl:

if ($condition) { doSomething(); }
doSomething() if ($condition);
unless (!$condition) { doSomething(); }
doSomething() unless (!$condition);

Some people really like all those different way of saying the same thing. For some people (like me), it would be preferable to have only *one* way of expressing a conditional statement. The extra syntax is just sugar. And there is such a thing as too much sugar.

Perl also strongly supports the notion of *implicit* variables and actions. For example, check out this code:

foreach my $element (@array) {
  doSomething($element);
}

This code iterates through the items in an array, allowing you to do something with each element.

But the same code can be expressed without ever explicitly using the $element variable, like this:

foreach (@array) {
  doSomething($_);
}

The $_ is the "implicit" scalar variable. Its value changes depending on the surrounding context of the code. While iterating through an array, the implicit scalar contains the current element from the array.

Perl also considers parentheses to be optional, and during a foreach (or for) loop, you can actually avoid even invoking the implicit variable directly, so the following code will do the same thing:

foreach (@array) {
  doSomething;
}

Personally, I don't like those types of implicit constructs, so I don't use them in my code. But there are many many concepts in perl that derive from the the notion of implicit data and implicit action. If that kind of thing is appealing to you, then you'll probably like perl.

Here's a little poem about python (you can find it by invoking they interactive python interpreter and then typing "import this"):

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I too love Perl and love the fact that I'm in a great community of great and eccentric programmers.

Anything that you can do in C/C++ or Java can be done in Perl.  It's a great language.

Perl has CPAN, which is a massive, massive advantage for most programming tasks. The main knock against it is that it is not fashionable among certain programmers because many beginners use it (and write ugly, hard to  maintain code, as beginners tend to do) or because it is not "pure" OO.

These people tend to use python, whose strengths include pure (and to a certain degree genuinely superior) OO and more enforced consistency (which can also be considered a weakness). I have no idea why it has not evolved something like CPAN in its 15-year history.

>There should be one-- and preferably only one --obvious way
>to do it.

This might be the fork in the road, eh?  For those that like the power and flexibility, this element of language design is the attraction.

Just as in regular communication, having various ways to say things makes a massive difference in the end.

This is just anecdotal evidence from javascript with formatting but it applies to variations in Perl: I used to think it cut and dry that oen would want to format and indent every statement of javascript I was responsible for, e.g.
if(foo){
  doThis();
  doThat();
}

But nowadays I spend a lot of time writing javascript on the server side and streaming it down.  So I write:

string jsClick =
"var x = 35;" +
"if(foo){" +
"doThis();" +
"doThat();" +
"}";

Which ends up as:
var x = 35;if(foo){doThis();doThat();}

Because it's formatted in my server block, I don't care about what it looks like when the browser gets it.  There's a flexibility that comes with that.  Formatting is a trivial thing, but what about with expression? 

Having more than one way to do it is, in my opinion, a blessing, not a curse.

Having programmed in Perl for years and years, I have to chime in on the major knock against it, namely that is is "write only".

The reason for this stems from two things:

First is the heavy use of punctuation.  Upon learning the language this makes the language more clear to the reader where it was so harsh to the person learning it.

The main persistent reason people thing Perl is awful is that a whole lot of Perl that has to be maintained wasn't written by programmers.  It was written by administrators who had a script that became a program that became a monstrosity.  Perl was/is the language of choice for one-off scripts but these have a tendancy to grow.

I consider it a testament to Perl's success that these scripts turn into mission critical programs even though they were created by someone who was not a full time programmer.  I've often thought that Perl is to Unix whas VB is to windows.

I certainly agree the OO syntax is cumbersome, but you can take it or leave it when writing your own stuff.

As to whether to learn Python or Perl, I'd go by what you plan on using.  Perl is at home on Unix and can make hard things easy when operating in an environment where "everything is a file".  Python is definitely a more elegant language that I've made good use of with some 3D programs (where an object hierarchy is important).

Go for Ruby, it sits somewhere inbetween the two.

I don't use/need an IDE with perl (or php, or python... bleh).  I do all of my coding with vim.  When I was on windows a long, long time ago, I used and really liked EditPlus (I would use it on linux if it was available).

I keep reading that perl is more powerful; in what sense is perl more powerful? LISP and ML have abstractions that python doesn't have - that's power. I've only been using perl for about a month, but it seems to mostly have more ways of writing the same abstraction.

The learning perl and learning perl objects books would make a big deal about it when there was a shortcut that saves a few characters, saying something like "every character counts", but typing speed isn't even close to being a limiting factor for me. The number of things I can keep in my head at once is a limiting factor though, and a lot of those shortcuts have some implicit variables which force me to remember more stuff. No doubt that won't be as much of a problem once I become really proficient with perl, but those shortcuts make the learning curve steeper and have no advantages that I can see.

Here is the dirty secret of perl programming:

If the code you are reading has implicit variables in it, you can safely assume the person who wrote it isn't a good programmer.  I'd say, much like guys driving giant H2 Hummers, they do it to compensate for their lack of other things, in this case programming skill.

I have been perl programming for YEARS and I have yet to see a programmer I respect use an implicit variable EVER.  There is simply no excuse beyond short-term lazyness to use one.

Also, in my opinion the O'Reilly "Bible of Perl Programming" series is vastly overrated*.  They are poorly written, hard to follow rubbish.  Sadly I have yet to find a good perl reference I like.

* That said, the O'Reilly perl books like _Practical mod_perl_ are very well done.

wow, cory, I like you. I have tended to go for named vars over implicit stuff mostly, and sometimes been told "that's not the perl way". I say screw the perl way - write good code.

I'm working on a private project that is basically a website, has a multi-lang cms system that is home grown (because I couldn't find what I wanted out there) - I've also been checking out ROR and associated stuff - but I'm still not convinced that I want to change from what I've started. Perl just gives me too much power to do what I want, how I want - and fast. And the library support is amazing.

IDE tools? I'm playing around with eclipse (because I was already using it for some other stuff), but mostly, your fav editor + unix command line does everything, and well.

One tip, if you get into Perl - don't sleep on the debugger. It's easy to debug perl using print statements here and there, and many people do that liberally - but the debugger under unix command line is a great, fast, powerful tool. And it starts up in about 0.02 seconds.

re Perl books - get the O Reilly "Pocket Perl Reference". It's the best book. When you need a lot of words, you can hit the web. What you need is a ref to the many and powerful features of the language, and a concise one. The PPR is it.

I think I could fall in love with RoR. I'm actually doing my next project in it.

While I'll sorely miss the gooey perl goodness, it's hard to argue with how quickly you can shove your first couple iterations out the door using rails.

it's interesting, but I'm not yet convinced. I need to play with it more. I definitely gets crud stuff in place very quickly, and it looks powerful. But I have a lot of stuff that is not crud. I need to take a long hard look at the globalise plugin too to see if I like the approach. I've pretty much figured how I want the data organised for being able to write a static webpage, pull it in, and then make it available to a translator online, and I already have a lot of stuff in place for that, but it needs to go one step further.  I'm trying to find a nice little project that I can use as an excuse to get up to speed on ruby. What I see so far of the language looks pretty cool. I could live with it.

What does this Perl code do:

i2%4*&)()*)*)();*{<#,#%^}%^&^*^^%%$!@$%%&
%^^%$,if^$&,&*+^|^&^&%&-^&*((*!$_$$)^)^%##/##@;776659@
((&^$$##$%^25=5&&%[$#]+$%^&*&%0%$$##$%^**^%$;32+
z%,.[]:'"|'|\

Answer: I have no idea. It's just a random hammering of keys.  But if I run it as a Perl script, it will do SOMETHING useful!

it might even construct an argument ...

"If the code you are reading has implicit variables in it, you can safely assume the person who wrote it isn't a good programmer. "

absolute rubbish. if a language has idioms, one may as well use them. perl programmers who use implicit variables simply aren't concerned about you, the maintenance programmer. they've already solved the interesting bits. your job is to deal with the boring stuff and whinge about programming style whilst they move on to the next interesting problem.

Cory, Here is some perl code which is more clear with implict vars. What do you think?

# on error print the current line
while (<>)
{
  /error/ && print $_;
}

# on error print the current line
while ($line = <STDIN>)
{
  if ($line =~ /error/)
  {
      print $line;
  }
}

Sorry I didn't respond to you sooner $_, I was busy doing finishing off my 200 pages of documentation and UML diagrams so they could be rubber stamped at the approval deparment.  We have to start coding next quarter, after all.

As for the while statement,

I'd do something like:

while(my $line = <STDIN>)
{
  print $line if ($line =~ /error/);
}

Same amount of space but my eyes aren't bleeding.

PS: You sure that isn't K, Mr. Norman?  I think I see the bit right in the middle it's talking to the NASDAQ.  Oh yes, if you look really close, at the end is the model for the database.  Try THAT with your pathetic Java's and Pythons you heathens!

I love that if at the end of the line trick. 

unless also works.

print "Neat' unless ....

python of course. Actually ruby would be a good choice. Don't base your decisions on web frameworks like rails or django.

perl....just say "No!"

"If the code you are reading has implicit variables in it, you can safely assume the person who wrote it isn't a good programmer. "

Cory, explain to me how to use map or grep without using an implicit variable or, conversely, make an airtight argument that no good programmer will ever use map or grep. In my experience both of these functions are huge wins.

It's a fair point about map and grep. But even so the gratuitous use of $_ in big foreach blocks doesn't help readability. If it's a big complex function a my $widget is akinder to the reader.

But skipping all that stuff saves time if you're just patching together a one-off hack to mess with some text files or something.

Horses, courses.

You should both be fired for that Perl code.  The correct answer is grep error.

Which is more readable:


while(<STDIN>){
    print if /error/;
}

or

while(my $line = <STDIN>)
{
    print $line if ($line =~ /error/);
}

???

Personally I would just do

print grep /error/ <STDIN>;

but I can see how this would be confusing if you don't know grep. Any Perl programmer with about three years experience should know grep, though.

That said I do prefer named loop vars for all but the most simple foreach or while loop. You just picked a bad example, Cory ;->

Finally, for one of the other commenters, pls note that <> != <STDIN>. The former will slurp any command line arguments in preference to STDIN.

SOmeone asked "and what kind of tools/IDE do u use when writing perl"

I use the EPIC plugin for Eclipse: http://e-p-i-c.sourceforge.net/

I do believe that Perl would benefits from having better, more modern tools available- it would be great to have 3 or 4 refactoring IDEs availabel for Perl.
I wrote an article about this issue, which was published on Perl.com: http://perl.com/pub/a/2005/08/25/tools.html