
Lisp as an Alternative to Java - llambda
http://norvig.com/java-lisp.html
======
discreteevent
The following are taken from: <http://news.ycombinator.com/item?id=1803351>

\----norvig 449 days ago------

Peter Norvig here. [....] In terms of programming-in-the-large, at Google and
elsewhere, I think that language choice is not as important as all the other
choices: if you have the right overall architecture, the right team of
programmers, the right development process that allows for rapid development
with continuous improvement, then many languages will work for you; if you
don't have those things you're in trouble regardless of your language choice.

\----edw519 448 days ago----

[....] Someone should write a program that automatically posts this paragraph
[Norvig's] at the top of every language war thread. I think they should write
that program in php :-)

\----poet 449 days ago-----

An approximation of some of Norvig's recent thoughts (Feb 2010): "(1) It just
turned out that when Google was started, the core programmers were C++
programmers and they were very effective. Part of it is a little bit of
culture. (2) Early Lisp programmers (Erann Gat) at Google actually noticed
that other programmers were equally or more productive. It has more to do with
the programmer; we're getting to the point where language choice is less
important (as opposed to 20 years ago). (3) Lisp is optimized for a single
programmer or a small group of programmers doing exploratory work... If I want
to make a change in a weekend I'd rather do it in Lisp than anything else, but
by the time you get up to hundreds of programers making changes are not a
language problem but a social one. (4) Libraries." Paraphrased from:
<http://www.youtube.com/watch?v=hE7k0_9k0VA#t=03m20s>.

~~~
raganwald
Yes, but given A = people, B = architecture, and C = language (and ignoring
process for brevity’s sake), the two honking giant caveats are these:

Just because A > B > C does not mean that C does not contribute to the result
and can be dismissed. C may be less important than A, but that doesn’t mean
it’s unimportant.

Specifically, assuming you have a _sane_ process for hiring people and a sane
process for choosing a language (e.g. we are not talking about the gap between
“I CAN HAZ CODES” programmers and Norvig, nor are we talking about the gap
between Brainfuck and Lisp), the contribution of A to the result is not so
many orders of magnitude greater than C that you can ignore C.

And:

A > B > C. Fine. But are these independent variables? No, we know that the
language affects (for better or worse) your ability to attract and retain
certain developers. So A and C are not independent. Likewise, certain
architectures are just plain hell to implement with certain languages, so B
and C are not independent.

Solving for the maximal result of A, B, and C does not mean choosing A first,
then B, and then C. It means choosing the best combination of all three at
once.

Update: Nothing I’ve said here disagrees with Norvig, caveats are warnings not
to oversimplify, not suggestions the advice is incorrect. Also,
<http://paulgraham.com/pypar.html>

~~~
discreteevent
I agree entirely. Its a balance, that's why I referenced the qoute from
Norvig. Not to show that language has no importance at all but that even in
this very particular case the author has a broader point of view than is
represented in the article. Anyway even though I don't really miss C++ I was
thinking the other day of all the code that I wrote in it when I had no choice
but to use it. I got a lot of work done, and it wasn't a mess either. I would
say that in my case anyway I tend to think that the language matters more than
it does and this (in my case again) is a source of procrastination. So
Norvig's qoute is like a kick in the backside for me (focus on what matters)
and that's a good thing.

------
mark_l_watson
This is an old article but still relevant, especially since Clojure allows co-
mingling Java and Clojure (Lisp) code. I find Clojure especially useful on my
own projects because there are no problems finding developers or getting
customer approval for using a very nice, but niche language.

I still like (J)Ruby a _lot_ but the runtime performance of Clojure is better
and the two languages seem, to me, to be equally "agile" - both are a pleasure
to code in.

~~~
jasonjackson
You've found it easy to hire people with existing Clojure experience? That
surprises me, great news though.

~~~
dpritchett
He is saying that he uses Clojure for personal projects because those are the
projects where he doesn't have to recruit for or justify his choice of a niche
language.

~~~
mark_l_watson
Thanks, that is exactly what I meant.

------
jdludlow
_the directions said to code as you would professionally_

I'm curious to know if anyone wrote test cases for their code. I didn't see
any here, but maybe they are in a separate file or weren't allowed to be
submitted to the study.

~~~
dextorious
Test cases were not that fashionable back in the day.

Surprisingly, people still got work done.

~~~
mjb
> Test cases were not that fashionable back in the day. Surprisingly, people
> still got work done.

Reinforced concrete did not exist back in the day. Surprisingly, some people
still got work done.

It's tempting to be dismissive of modern development practices (TDD, for
example) using the argument that a lot of great software was written before it
existed. If the icons of the past could write Unix without TDD, why do we need
it to build a CRUD app? This is an extremely poor argument against improving
development practices.

People were getting building done before reinforced concrete, doing particle
physics before synchrotrons, and designing mechanical devices before CAD.
Since we have had these things, however, each of these fields has advanced
significantly due to their use. It would certainly be possible to design the
complex solid forms of something like an iPad without CAD, but it would be
much more difficult and expensive. It's the same way with development
practices. Modern development approaches, in many cases, significantly reduce
the cost and risk of software development.

~~~
tomjen3
Don't confuse writing unit-tests with TDD. TDD requires unit-tests, unit-tests
do not require TDD.

And unit-tests don't require writing unit-tests for everything.

------
pearle
Is this an older article or something recent? A 1999 paper is referenced but
the article itself does not seem to have a date.

~~~
geebee
Yeah, and Java is referred to as "3-4 times slower than C++", which makes me
think it's probably from the late 90s or early 00s.

That said, most of the arguments for Java around improved speed _might_ apply
to any language that runs on the JVM, though someone else might want to chime
in here (I'm a little out of my depth trying to talk about how Lisp, Ruby, etc
are implemented on the JVM).

~~~
tomjen3
Unfortunately the JVM is optimized for Java, rather than for computer
languages in general. This is a problem because you can't just say execute
function 'foo' on object bar, you have to look up the type of bar to find foo
and then execute it.

Clojure gets around this by having all its functions implement a standard
interface, and Java 7 has sorta seen the light (still no closures, but they
can kind be emulated).

JRuby just suffers.

~~~
ShardPhoenix
Invokedynamic in Java 7 (<http://jcp.org/en/jsr/detail?id=292>) seems to have
fixed this: <http://ruby-lang.org.ru/post/5533.html>

------
aninteger
It's 2012. There is an alternative to Java. It's called C#

~~~
rbanffy
C# and Java are very close. I wouldn't be surprised if the numbers - LoC,
performance and time-to-develop - were very similar to the Java ones. The
article states the Lisp code is significantly smaller and development was much
faster. I don't see how C# could approach Lisp even adjusting for the fact
it's Peter Norvig writing it.

~~~
scarmig
Well, "very close" might be an exaggeration. C# has lazy evaluation,
generators, LINQ, generics, and functions as first class citizens, while Java
has... none of those. Or what amounts to none of those.

Overall C# ends up being a much more expressive language. Though obviously C#
and Java are closer than C# and Lisp.

------
bborud
I can imagine that Lisp without the shitty attitude would be great. The shitty
attitude that elegance and purity is so much more important than actually
being able to talk to the environment a program runs in.

~~~
rayiner
Elegance and purity are the last thing Common Lisper's care about. Common Lisp
is a by-committee spec, after all. If you're going to characterize the "shitty
attitude" around Lisp, it's much more about the language being pragmatically
well-designed. Dynamic, but not unmanageably so like Ruby. Tasteful API design
unlike Java. Performance much closer to Java than to scripting languages. Etc.

~~~
lispm
The original Common Lisp was more like a community work. It led to an
understanding about the language in early 1983. A book about the language was
then published in 1984: CLtL1.

The work on the ANSI CL standard started then in 1986 using the ANSI
standardization process. An intermediate language description (not a work of
ANSI) was published as CLtL2. The ANSI CL standard then still took a few years
more work to finalize and publish a standard document.

