
Lisp is Poetry and Most Programmers Want Prose (2006) - ananthrk
http://blogs.adventnet.com/svembu/2006/01/19/lisp-is-poetry-and-most-programmers-want-prose/
======
CodeMage
Fascinating. This post illustrates precisely what -- in my opinion -- is the
attitude that makes someone a Blub programmer. That's what Paul Graham was
originally talking about: people who learn and develop their skills as
programmers up to a certain point and then say "That's enough, I'm
comfortable."

Don't get me wrong, you can get to be a _damn good_ Blub programmer. You can
also work at an international company, headquartered in US, without being
skilled enough at English to appreciate Shakespeare's work; or, for that
matter, loathe it, since you need the same level of proficiency.

I do believe that you'll never get to enjoy English to the fullest, if you
don't explore its poetic reaches. In words of Wilhelm von Humboldt:

 _The diversity of languages is not a diversity of signs and sounds but a
diversity of views of the world._

I believe that the same applies to programming languages. Yes, you can be
really good with just Java. But just by learning C# on the side, you can gain
valuable insights without stepping too far from your comfort zone. Learning
Lisp, Self, Python and Factor, to name a few, will give you whole new
worldviews, make you think differently. You don't really need that stuff to
make software (or money). But it can make you a hell of a lot better at it
and, more importantly, it can make you enjoy it more.

~~~
gtani
Most of the devs I encounter recently are at least curious about different
families of language

\- ruby or python (GTD lang's)

\- java, C and derivatives

\- concurrent/FP: ocaml, clojure, scala, haskell, clean, erlang, F#

\- lisp/scheme, dylan

\- smalltalk, factor, Ioke, forth,

Fortunately, you can spend all weekend reading about languages:

\- hacker news; reddit; infoq.com; artima.com; theServerside.com and .net;
Lambda the Ultimate

~~~
JadeNB
> smalltalk, factor, Ioke, forth,

This is an unexpected grouping; the design philosophies of Factor and Forth
seem quite different from those of Smalltalk, which in turn I think is only
one of the points of inspiration for Ioke. Is there some deeper similarity
that you're pointing out here?

~~~
igrekel
Not to mention how close are Smalltalk and Ruby.

------
funcall
"LISP is worth learning for a different reason — the profound enlightenment
experience you will have when you finally get it. That experience will make
you a better programmer for the rest of your days, even if you never actually
use LISP itself a lot." -- Eric Raymond (How to become a Hacker).

I wonder what percentage of people who "get Lisp" manage to stay happy working
in other languages.

~~~
Raphael_Amiard
Well a lot i would say.

Peter norvig for starters ? I would say me if i mattered ;)

~~~
funcall
I'll accept your own experience, and am happy for you. As for how Mr. Norvig's
coping -- let's wait for him to post his own.

I could see a language designer (say someone like Guy Steele) who has made
major contributions in Lisp happily moving on to his or her next research
interest, pursuing a completely new design. Those of us stuck in the "real
world" of trying to make a living with our software skills are a different
matter.

In my experience, once having worked with Lisp I found it extremely difficult
to switch to programming in Java. I spent a lot of time trying to make Java
look like Lisp, which in my opinion made my code more readable, but to other
programmers I worked with - not so much. My point is, Lisp can be a mind
altering experience, much like LSD (I suppose). Some have the ability to
compartmentalize the experience and move on with other pursuits and some are
forever hooked on the "forbitten" fruit.

~~~
kenjackson
I think it depends on your trajectory. I did BASIC then 6502 assembly language
then C. Then a few other languages before spending considerable time in
Lisp/Scheme, and then Haskell.

Much like the author of the posting, I find some elegance in Lisp, but I've
never been comfortable with it. While I can code anything I've ever felt the
need to do with it, it would rarely be my first choice language. And
especially with respect to performance -- I find myself having to spend a lot
more time at the whiteboard ensuring that what I'm doing isn't too
computationally expensive with Lisp. I just don't have nearly the same sense
of cost with it.

------
gruseom
What a case of assuming your conclusion. If Lisp is poetry, and poetry is
beautiful-but-archaic-language-completely-divorced-from-ordinary-human-
communication, well then obviously Lisp is for a tiny minority who like to
speak Elizabethan; meanwhile the much larger population of _practical_ people
will simply prefer to _get things done_ in vernacular.

It's nonsense, of course. If Lisp weren't good for getting things done, I for
one wouldn't bother with it. But having assumed his conclusion in the first
three words of the second paragraph, the author need offer no argument, and
doesn't. In fact he doesn't even mention Lisp after that.

------
j_baker
Say what you will about pg's writing. But he's been involved in the funding of
_plenty_ of startups that didn't write Lisp code. I think you should pay
attention to where his money is going before you read too much into his
essays.

------
plinkplonk
"I am much more impressed by the genius of the finished product rather than
the expressive beauty of its implementation. "

Sridhar's whole argument hinges on this dichotomy between choosing great tools
and having a great finished product.

It is a false dichotomy - In some situations you don't have to choose one to
the exclusion of the other. You can have both, especially in startups (PG
specifically mentions startups in his essay, as a context to where powerful
languages would be effective). Use AND instead of XOR and this post falls
apart.

If you start with the intention of building a finished product with "genius",
it might help to look for the best tools to build that genius product with,
which would _also_ give you expressive beauty (and effectiveness). Again AND,
not XOR. Sure you could end up with a beautiful creation using crude tools,
but why would you want to _if_ you have a choice of tools??

Extremist positions about a largely artificial choice between great tools and
great end-product aren't very convincing. I don't buy this argument anymore
than I buy the "I am cooler than you because I write in lisp and you write in
C" argument.

From Sridhar's post

 _"I bet that the vast majority of the world’s programmers, want an “easy”
language, not a highly expressive, poetic language Contrast this view with
Paul Graham’s Hackers & Painters."_

Interesting rhetorical device(again) but there isn't as much of a conflict
between their views. There isn't a conflict between "easy" and "poetic". The
same language can be used to produce works which are either, neither or both,
with all sorts of intermediate positions and shading.

From Pg's essay

 _"Part of what software has to do is explain itself. So to write good
software you have to understand how little users understand. They're going to
walk up to the software with no preparation, and it had better do what they
guess it will, because they're not going to read the manual. The best system
I've ever seen in this respect was the original Macintosh, in 1985. It did
what software almost never does: it just worked. [6]

Source code, too, should explain itself. If I could get people to remember
just one quote about programming, it would be the one at the beginning of
Structure and Interpretation of Computer Programs.

Programs should be written for people to read, and only incidentally for
machines to execute.

You need to have empathy not just for your users, but for your readers. It's
in your interest, because you'll be one of them. Many a hacker has written a
program only to find on returning to it six months later that he has no idea
how it works. I know several people who've sworn off Perl after such
experiences."_

Software should make sense to both users _and_ other programmers? Oh horror,
PG does seem to be focusing on the end result after all.

Now PG _also_ seems to imply that _in some contexts_ (startups with a few
skilled hackers competing with larger companies with not so killed hackers,
say) choosing powerful languages (or generally "running upstairs") would get
you to the desired endpoint faster/with less resources etc. Debating that
point is fine. Mischaracterizing it isn't.

The problem again seems to be the artificial divide between "simple and easy"
vs "poetic "(and by implication NOT simple and easy). The only real argument
offered for this dichotomy seems to be based on his personal experience in
learning two languages. One learning experience seems to have focused on
learning with simple sentences and the the other on learning via/with
classical poetry.

If the two languages (and teaching styles) were interchanged, so if you learn
English by/with analysing Tudor poetry and Tamil by learning conversational
and practically useful sentences, I suspect you would find the latter easier.

That doesn't say much about which language is intrinsically better for a given
purpose in a given context.

English can be taught simply or in a complicated manner. So can Tamil. You can
read/write complex, layered poetry in both, which are nearly untranslatable
into the other. You can write simple , clear prose in both.

 _"After all, if you are doing wireless communications systems simulation [as
I was] or writing a web word processor [as we are], what matters is the
particular domain, and the language in which it is developed is not the most
important issue. "_

But _no one_ (least of all PG) ever claimed it was the _most_ important issue,
taking precedence _over_ domain. But it is _an_ important issue.

A programmer who didn't care _at all_ about his tools and didn't have clear
preferences, not only about programming languages, but also about other tools
like Editors, Version Control Systems etc is hardly a professional. A
preference need not be absolute and fanatic. Use AND when you can and XOR only
when you have to.

A web word processor can be written with Clojure or Python (say) and
JavaScript or with (say) PHP and JavaScript.[1]

Given that choice, I'd expect good developers to _tend_ to one choice over the
other _if_ they had the choice (Once you have a large enough base of legacy
code/a large enough company, often you don't have that choice).

My nutshell reaction: Bleh what a terrible post. It hardly holds together in
any logical fashion or says anything insightful.

[1](Here I am using the same rhetorical device of setting up two arbitrary
extremes and forcing a choice - Domain XOR Powerful languages, Clojure XOR
PHP. In the real world you could used Clojure, JavaScript _and_ some PHP, or
none of these etc, but then how would we argue about irrelevancies? ;-)) .

~~~
cageface
_It is a false dichotomy._

Perhaps, but in practice communities centered around more esoteric languages
seem to spend more time working on elegant hacks and self-referential tools
than on producing working, useful products. I met a lot of very smart hackers
when I was still seriously doing Common Lisp coding but none of them could
show me anything actually _useful_ they'd done with it, although they had a
lot of very clever tricks up their sleeves.

For example, package management in Common Lisp was a mess. There were three or
four completely incompatible systems in use and none of them were really
polished enough to depend on. I was astonished at how quickly the Ruby
community implemented and rallied around a single, simple, usable package
manager, because I'd previously just assumed it was a hard problem to solve.

------
jgg
This is getting stupid. People program real, working things in Lisp. People
program real, working things in languages that aren't Lisp.

 _Grow up_.

