Porting Perl to Python
Linked by Thom Holwerda on Fri 10th Sep 2010 14:59 UTC
General Development Python programmers shouldn't get too smug. While many people agree that Python is designed in a way that makes it a highly readable language, there can still be problems with legacy, untested Python code too. Porting legacy Perl to Python can be a daunting task. In this article, learn some of the theory behind dealing with legacy code, including what not to do.
E-mail Print r 0   60 Comment(s) http://osne.ws/icv
Thread beginning with comment 440449
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

Problem is, a language that allows "-" in variable naming can't do the most basic mathematics who need this minus sign, except by bringing a very exotic syntax like Lisp's ;)

Myself, I think that the camel case vs underscore argument is highly a matter of taste. In my code, type names use camel case and variable names use underscores, because I like to differentiate those at first sight (especially when I dive in some code left alone for some months) and a starting capital is not enough for me ;) .

Reply Parent Score: 2

frytvm Member since:
2009-11-11

You can support a-long-variable-name easily if you require spaces around the subtraction operator (which many people put there anyway, for readability reasons). Dylan did this, and I think perl six is doing something like this, too.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

You can support a-long-variable-name easily if you require spaces around the subtraction operator (which many people put there anyway, for readability reasons). Dylan did this, and I think perl six is doing something like this, too.

Right. I personally think this gets a bit too intrusive in the coding style area, but there is room for everyone's taste in the programming language world, and anyway you indeed proved that this is doable ;)

Edited 2010-09-11 17:09 UTC

Reply Parent Score: 2

modmans2ndcoming Member since:
2005-11-09

that is why postfix evaluation rocks!

Reply Parent Score: 2

Neolander Member since:
2010-03-08

that is why postfix evaluation rocks!

Well, I've seen a language entirely based on postfix notation : SysRPL, used to code fast applications on HP calculators.

My experience was that it was horrible, after years of Pascal, Python, and C(++), to even try to understand it. One seem to be able to get comfortable with it in the long run, but I couldn't get that far. It just looked too much like a glorified rebranding of Assembly with its stack-based way of thinking...

Edited 2010-09-12 14:10 UTC

Reply Parent Score: 2

google_ninja Member since:
2006-02-05

I think most newer languages do it that way, and I agree, thats how I roll too ;)

wrt it being a matter of taste, I slightly disagree. Camel case doesn't scale up as well, passed about three words it gets very hard to read. Wide casing doesn't have that problem, but it means additional characters. You could say that you shouldn't really be going passed 3 words anyways in variable or function names, but I find there are times when inspiration totally fails me, and I end up writing a five word function because I can't think of a more succinct way to write it.

In a world where everything could be expressed clearly in two words or less, I think camel case would make more sense. But especially when you take into account that its main bastion of use is in java, the land of enterprisey code like AbstractFoobarFactoryAdapters, I have learned to really downright hate it.

Reply Parent Score: 2