
Python as an Alternative to Lisp or Java, Peter Norvig revisited - DrJosiah
http://dr-josiah.blogspot.com/2010/12/python-as-alternative-to-lisp-or-java.html
======
SpikeGronim
To me, it's not interesting at all to ask who can write a 100-1,000 line
program faster in which language. The real interesting question is how
efficient developers are once you're talking about a 100,000 - 1,000,000 line
program that has been in development for years. Solving small problems is
relatively easy.

~~~
samratjp
Even at that scale, python code readability trumps over almost every other
language out there. Compulsory indentation and there's only one way to do this
mentality keeps everyone on the same page.

So, yeah, that's probably why Google uses python extensively.

~~~
enneff
I work at Google and we don't have that much Python in our codebase. There are
some outlying cases that use it (like the YouTube front end), and it _is_ one
of our official languages, but the vast majority of Google code is C++, Java,
and JavaScript, with Python a trailing 4th place. Python is just not that
suitable for large-scale software development.

Readability means different things at different scales. Reading Python "in the
small" is easy; it's looks like pseudocode. Once you start writing larger
programs, between the 5k and 10k mark, the looseness of Python starts to
become a burden. It can be very difficult to look at a piece of Python code in
a large project and know exactly what it does. Dynamic typing means that a
whole class of serious programming errors go unnoticed until runtime - and
often only for a specific, uncommon input.

("Compulsory indentation" ?! Whomever works on a large project with others and
doesn't format their code to the standard of the project should be taken out
and shot. I'm only half-joking. Indentation has almost nothing to do with
readability, though. It's just common sense.)

(I'm surprised to hear you say "there's only one way to do this" with regard
to Python, as in my experience there are always several ways of doing
anything, and it's not uncommon to see different/competing approaches used in
a single project.)

I'm biased, but Go is a great choice for large-scale software development. It
has the brevity of a scripting language, but being statically typed and
compiled Go can be more reliable and efficient. It's also smaller and more
consistent than any mainstream language. Because of this, you can typically
look at a piece of Go code from any project and understand what's going on.
This is because it's difficult to abuse Go in the same way you see done in the
other four languages I've mentioned, and that is truly valuable at scale.

~~~
sigzero
"Indentation has almost nothing to do with readability, though. It's just
common sense."

Um...it has EVERYTHING to do with readability. That is WHY it is just common
sense.

~~~
dwc
Wonderfully indented code is not always readable. Readable code is always
indented well.

------
6ren
HN comment by Norvig on Lisp vs. Python
<http://news.ycombinator.com/item?id=1803815>

------
smackay
It is surprising that in 2010 we are still talking about efficiency in terms
of lines of code whether the absolute number to express a problem or in the
speed that these lines can be created. I realise that this is a proxy for the
ability of a language to succinctly express a problem however it ignores all
the major factors that determine how effective a piece of code is over its
lifetime.

The ability of language X to solve a problem depends on:

1\. The expressiveness of the syntax to capture algorithmic complexity. 2\.
The availability of tools to support the creation of the code. 3\. The ability
of the typical programmer, conversant in the language, to write the code. 4\.
The costs involved in maintaining the code over its lifetime.

Rendering all these dimensions into a single metric seems simplistic at best,
undermining the argument as to which set of tools and technologies are
deserving of more attention and ultimately plays into the hands of the people
who wish to render programmers and programming into pure commodities.

------
Stormbringer
I wonder if another, equally valid, way of looking at the lines of code vs
time is that if two programmers using different languages both complete the
task in roughly the same amount of time, but one uses only half the total
lines of code... that implies _not_ that that programmer is better, but that
each of their lines of code took roughly twice as long to produce.

One of the things I used to do when working in large teams was wander around
and look to see if anyone was having trouble debugging. Sometimes you'd find
someone who'd been stuck on a bug for several days. So what I'd do was I'd sit
down with them, and start putting in all the 'fluff' like indenting their
code, splitting lines with multiple variable declarations each onto their own
line etc. Essentially putting in all the 'long cuts' that they'd taken 'short
cuts' around in order to 'speed up' the programming.

Often either they or I would see the problem immediately.

These days of course there are tools that do the auto-formatting, but I still
try to optimise for readability, simplicity and elegance in my code.

Back to the lines of code as a metric issue (tm) in that scenario where it
takes 2x as long to write a line in language X, and that line does twice as
much, it is probably at least twice as complex as the 'more verbose'
language... and I think this implies that it will be harder to debug and
maintain later on. So arbitrarily complex languages are optimal for some
internet 'toss off' (one off, toss away) competition, but not necessarily
optimal for long term efforts.

Some of these languages that allow you to redefine the language itself on the
fly allow you to do 'cool stuff' (tm) but tend to attract people who think
they are much cleverer than they actually are. I think it is a regional
variation, but all the Ruby fans in my city scare me. The thought of what
would happen if I'd spent days or weeks on a bug only to find out it was
caused by someone else 'tweaking' one of the core classes and not bothering to
tell anyone else... _twitch_

~~~
kbd
I question your assumption that if something is done in 1/2 the lines of code
then each line of code is twice as complex. You're equivocating on "complex".
Each line may be "more complex" in the sense "does more", but not necessarily
more complex as in "harder to understand" (and therefore more prone to bugs).

Code in a more productive (i.e. higher level) language is concise because it
__hides __extra complexity you don't need to think about at the time, and is
therefore __simpler __, not more complex (in the second sense).

~~~
DrJosiah
A perfect example of this is setting up iteration in Python vs. C++.

In Python: for obj in seq: ...

In C++: std::base_class<template_type>::iterator obj; for (obj=seq.begin();
obj != seq.end(); seq++) {...}

The reduction in lines for Python doesn't make it more complicated, it makes
it cleaner and easier to express ideas.

------
philwelch
Norvig:

 _It took me about 2 hours (compared to a range of 2 to 8.5 hours for the
other Lisp programmers in the study, 3 to 25 for C/C++ and 4 to 63 for Java)
and I ended up with 45 non-comment non-blank lines (compared with a range of
51 to 182 for Lisp, and 107 to 614 for the other languages)._

Seems like the programmer, not the language, is the biggest determinant. If
you have the Java programmer who wrote it in 4 hours, and the Lisp programmer
who wrote it in 8.5 hours, you're better off writing it in Java!

If you want to write concise programs quickly, using the same language Peter
Norvig uses might help, but being as good as Peter Norvig helps more.

~~~
wh-uws
Yeah I really believe this is mostly about the programmer.

It takes a different type of programmer to even want to venture to learn lisp
in the first place.

------
jackfoxy
This is the kind of article that should more frequently come to the attention
of enterprise management. There really is an inverse relationship between the
expressiveness of a language and the number of bugs created. (That is, I am
taking at face value the studies which claim a more or less linear
relationship between lines of code and bugs, regardless of language.)

~~~
aharrison
I have heard this before many times, and I tried to find a study that would
defend that assertion one weekend and failed miserably. If you have a citation
for one of those studies I would be in your debt.

~~~
jackfoxy
Found this [http://amartester.blogspot.com/2007/04/bugs-per-lines-of-
cod...](http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html).
Thanks for calling me on that, I was just repeating the popular assertion.

------
jamesaguilar
I wonder how short a good Java programmer's solution would be compared to the
J Random Java Programmers used in the study so long ago.

~~~
DrJosiah
I also wondered that.

~~~
apl
Seven lines, of course. It's _obviously_ in the standard library.

~~~
jhuni
That is why these SLOC measurements are stupid. If you find the right library
or module, perhaps from CPAN, that can change everything.

------
davidhollander
For the most EXTREME algorithmic compression of information to number of lines
in Python (with few to 0 intermediate values stored), I've found it hard to
beat using nested function definitions with abstracted shared logic called by
running the vars() builtin as the parameter list. Basically ship the current
scope elsewhere to finish processing to ensure no logic is repeated.

I tend to not use separate URL mappers in controllers but have nested
functions that define both logic and layout simultaneously. (Basically a tree
structure of function definitions where the ending subpage elements are leaf
nodes, and nodes render wrapper base templates on post traversal unless it was
an ajax request). I can post some code if this doesn't make sense. Obviously
not defining new variables nor using classes is extremely unpythonic and could
pose difficulties for group work... minimum number of lines while fun isn't
everything!

------
bkz
This version clocked in at 1:35, gave up on the "professional code"
requirement though :) Need to sleep.

<https://gist.github.com/752455>

------
dilap
Anyone try the puzzle? The following does not occur in the sample output, but
I don't understand why:

/78698/37395746288: Koch 8 Sud Hab Tirol

What did I miss in the rules?

~~~
ay
Violates this requirement: "If and only if at a particular point no word at
all from the dictionary can be inserted, a single digit from the phone number
can be copied to the encoding instead."

The number you mention allows to get into the branch with the 'Koch o"d' - so
no digit can be selected.

~~~
dilap
Aha! Yep, that was the problem. Thanks!

(I was reading the requirement as "If at a particular point no sequence of
words from the dictionary can be inserted to complete the number, a single
digit can be inserted" -- which still makes a lot more sense to me than the
actual requirement!)

Sadly, no programming language could have helped me with this bug. :)

<https://gist.github.com/752506>

~~~
DrJosiah
Don't feel bad, I hit the same bug myself. :)

------
apetresc
I saw Martin Odersky use this exact problem in a talk he was giving about
Scala. It came out to about 10 lines.

------
technomancy
<http://p.hagelb.org/csb.gif>

~~~
xorglorb
Hacker News is not 4chan, and as such, do not reply "Cool Story Bro", unless
you are replying to your brother that you thought the story he gave you was
popular.

~~~
barnaby
I upvoted you and downvoted him because I really don't want HN to degrade into
Reddit/Digg/4Chan/etc. I come here specifically because it's _not_ one of
those, and has a good signal-to-noise ratio (e.g. relevant conversations not
overrun by silly memes)

~~~
Apocryphon
What about Metafilter?

