
Why Lisp Will Never Win (2003) - progga
http://perl.plover.com/yak/12views/samples/notes.html#sl-39
======
Confusion
_com.lang.lisp_ isn't "the Lisp community". There may be reasons to suspect
"Lisp will never win", but _comp.lang.lisp_ has nothing to do with them.

Personally, I don't even know what it means for a language to 'win'. I would
be fine with Lisp/Scheme being marginally popular and acceptable when you're
in the company of clever colleagues that could reasonably be expected to grok
Lisp after a short while. Nevertheless it isn't. The reasons why _that_ is
currently the case would go a longer way towards explaining why that may never
be the case.

~~~
Jd
I think the general attitude of lispers is frequently a large turn off. There
is a lot of elitism, but it is often a needy Mensa-like elitism. There is
almost a hidden plea attached "please respect us as the smartest" and the
problem is, of course, that they can't point to any tangible, quantifiable
method for gauging intelligence with respect to a language. I guess PG's
"let's see if anyone is using it in 50 years" is a good measure in some case,
but that implies that lisp as a language is less of a "computer language"
(e.g. a language that is made for making machines do what we humans want them
to) and more of an artform or philosophical/mathematical depiction of some
deeper truth obscured to normal people.

I think this is ultimately always a problem between ultra-smart people who
live in something of an abstracted world that frequently approaches fantasy
and the reality of industry, which generally doesn't care about how pretty
something is unless someone will buy it because it is pretty. That's a pretty
large gap, and, while in my opinion there is no need for arrogance, it is
pretty clear why most of the smartest people in history end up on the former
side of that divide. They want to contemplate some sort of eternal idea which
usually they ascribe beauty to (e.g. Bohr, Einstein, etc.) -- and yet hackers,
unlike theoretical physicists, are halfway between the people probing the
mysteries of the universe and those putting together blueprints for the atom
bomb.

In my opinion that's just life. Einstein hated the bomb and rightly so in my
opinion -- but that doesn't mean that it was any less a necessity for the
Manhattan project to go forward. The sad thing, however, is that lots of
brilliant people trying to navigate this divide end up with a huge chip on
their shoulder. PG talks about this in H&P; the jocks were popular and
(surprise!) the nerds were not. So you go out and get a few million and say,
"ha, screw the jocks." Fine, generally speaking I think that is a good idea,
but let's not turn it into a wanker fest since there are lots of needed
functions in the world that should probably be performed by those who can't
understand Lisp -- and I don't just mean cleaning toilets, I mean politics.

Abstraction, which is really what lisp is about in many ways, is only ever IMO
one pole. You have to zoom out to see the bigger picture and zoom in to
address the minutia. Generally people miss the forest for the trees, so I have
every sympathy for those who stick with the forest and ignore the trees. But
when it comes down to it, someone has to re-write your code in blub to make a
functional product (even true with Viaweb) so have some sympathy for the
little man who has to do a sh't job, probably his mother never gave him fairy
tales to read and he only vaguely knows who Godel, Escher, and Bach are.
That's sad, but that's life and we who are Americans should especially expect
it as an immigrant nation.

Anyways, I'm one who discovered Lisp rather late despite and not because of
the Lisp community as it is usually presented. I think it is beautiful and
esp. I think SICP is a fantastic book to introduce one to computer science
concepts and I think that industry should serve great passions and ideas and
not vice versa. Hell, I even think lisp machines are a great idea and hope
someone builds new ones and they take over the world. But despite all of that,
I would never hang out with "the Lisp community."

Why? I want to build great products. Great products need to scale. If you want
to go to the moon you need a f'ing spaceship and not emacs and an open source
notebook. Spaceships are big. They take a lot of people to run, and they have
to be smart people. One mistake and you are smithereens at Cape Canaveral.

The thing that irks me the most about all of this whining is that America used
to be capable of building automobiles and space shuttles and (omg!) computers.
It was amazing. Now it is hello Taiwan, goodbye America. People talk about
"Rework" and how they can't imagine being in a company with more than ten
people and glorify the life of tribes in third world countries without
contraception or toothpaste (or, in pg's case, the lifestyle of lions on the
African prairie).

I know it may be nuts to say this, but I think we need to build cool stuff for
the sake of building it, and that our tools should be _our_ tools -- not some
magic fairy dust. Use whatever works to solve the problem. Get your hands
dirty. A parentheses is not a hammer if what you've got in front of you is a
nail.

And if what you've got in front of you is a problem bigger and nastier than
that, build a bigger and better tool. There's no problem that can't be solved
if people put aside their differences and work together.

~~~
sedachv
> If you want to go to the moon you need a f'ing spaceship and not emacs and
> an open source notebook. Spaceships are big. They take a lot of people to
> run, and they have to be smart people. One mistake and you are smithereens
> at Cape Canaveral.

The moon is not that far away from orbital flight. These two guys might
disagree with you: <http://www.copenhagensuborbitals.com/>

~~~
nknight
That site indicates they're attempting to launch a human on a suborbital
trajectory. What does that have to do with either orbital flight or going to
the moon?

~~~
rbanffy
If you can get to space, even a suborbital flight, you must have gotten most
of the life support right. If you reach orbit, you got your rocket right. If
you can change orbits, you got manevering right. If you can stay a week in
space, the rest of your life support is OK. All you need now is a second
booster to launch you to the Moon. You can either circle it in a free return
trajectory, or brake an enter orbit.

The orbit part seems the most complicated.

~~~
nknight
Wow. Just wow.

Every single system you name is made up of a large number of complex sub-
systems designed and built to exacting requirements, and any one of them can
still break at any time. Thinking you "got it right" just because it didn't
break one time in one set of circumstances is unbelievably naïve. There's a
reason all man-rated launch systems have redundant backup systems, and even
the fallbacks don't always work right.

By the way, let me know when you get micrometeoroid shielding "right" -- every
space agency on Earth will want to talk to you. You might even win a Nobel
Prize.

You're also completely ignoring navigation. Just because you can fire up a
rocket doesn't mean shit if you're at the wrong point in your orbit, or
pointed in the wrong direction.

You're also failing to distinguish between "I can get THIS rocket into orbit"
and "I can get a rocket big enough to carry people and a useful payload into
orbit and/or to the moon". Think you can just "scale up"? You're wrong.
Effects that were too small to measure before will suddenly kill you.
Materials that could handle the strain of the smaller rocket will crumble
under the increased forces.

Oh, by the way, every time the weight or configuration of your spacecraft
changes, you're gonna have to rework your navigation assumptions.

Might I suggest playing with Orbiter for a while? Once you've done that, spend
a few minutes thinking about the fact that you've just been overwhelmed by a
vastly simplified simulation in which _nothing ever goes wrong_. Now picture
the real world.

Oh, by the way, your heat shield is cracked, but nobody noticed because your
budget didn't allow for more than one guy to inspect it, and he was too drunk.
Have fun getting home.

~~~
rbanffy
The original point is that, once you achieve LEO, a free-return tragectory to
the moon is just a question of delta-v. And not that much - the Soyuz-based
moon roundtrip being offered for US$ 100M is a Soyuz docked with a mini-bus-
sized booster stage.

Micrometeorites? Did Apollo have that? I am not implying it's easy - I'm
implying LEO is the hardest part when it comes to a moon-orbit trip.

And in the case of an unmanned craft, it's easier: you don't have to bother
with life support, atmospheric braking and most of the radiation shielding.

~~~
nknight
Except that wasn't the original point at all. It started with Jd saying:

 _"If you want to go to the moon you need a f'ing spaceship and not emacs and
an open source notebook. Spaceships are big. They take a lot of people to run,
and they have to be smart people. One mistake and you are smithereens at Cape
Canaveral."_

Followed by sedachv saying some guys who are trying to launch humans on _sub_
orbital flights would disagree.

Nothing you've said explains what suborbital flights have to do with going to
the moon. On the contrary, you seem to be admitting they have nothing to do
with going to the moon, so I still have absolutely no idea what sedachv's
point was.

~~~
rbanffy
Well... I maintain that the hardest part of going to the Moon is achieving
Earth orbit. The rest is, comparatively, easy.

But, then, this discussion is completely unrelated to the point regarding
emacs and an open source notebook (whatever that is). In general, Jd's rant
felt confusing. I am not sure how Lisp and spacecraft are related, BTW. He (or
she) implied somehow that you couldn't go to space with something simple and
elegant like Lisp, but I can't be sure.

~~~
Jd
Re: open source notebook see: <http://stallman.org/stallman-computing.html>

I'll make the relation very clear. There is a segment of the Lisp community,
which most certainly includes Paul Graham, that maintains that projects with
large team sizes are bad. There is a certain logic here, as it is hard to
maintain a high average intelligence distributed across a large number of
people. Most true geniuses were loners. Regardless, projects of a certain
scope (i.e. building a space shuttle) require large teams. You simply can't do
it with two guys in a basement.

In a certain sense the computer language employed is irrelevant, except that
the lisp community has never, largely because of the facts that should be
obvious but are apparently not to the introverted "genius" types they pray on,
produced good and extensive enough libraries to be viable for most real world
tasks. In case you didn't notice, for example, it took what, 4 years for
Hacker News to get HTTPS support.

I don't want to rib anyone too badly, because I am a strong supporter of what
YCombinator is doing in general and in the incorporation of lambdas and
closures in newer languages, but I think generally speaking it is clear that
the Lisp culture is not to cooperate but to position one's self as some sort
of genius and thus to create one's own dialect, etc.

I'll give you an example that will probably irritate some people, but is
relevant here. Microsoft Word is, in my opinion, one of the greatest
architectural marvels of modern civilization. The feature set of that single
app is truly extraordinary, and there are all sorts of wonky ways that you can
do lots of tasks that makes millions (and potentially even billions) of
people's lives better every day. I understand that there is a point to
OpenOffice and "fighting the man" and whatever since Microsoft certainly
crushed some competitors in mean ways, but realistically there is nothing in
the world that competes.

Now you might say, oh sure but I can just use vim and use latex for formatting
(or even google docs). And in a certain sense you might be right too, but
sooner or later you will find a feature that is not accessible to you (I
recently noticed that change tracking still absolutely blows in Google Docs
compared to Word).

Why do I bring this up? Well, even if you are right that "the hardest part of
going to the Moon is achieving Earth orbit," you still have to have all of
those other things. You need life support or you dead; this is non-negotiable,
just in the way that mail merge is not negotiable for millions of people at
millions of office worldwide. And if you want life support (or mail merge),
you need to work with the people who design these other systems.

By the way, I'm not saying you need to like any of this. I'm simply saying
that if you want to build something great, you have to at times slog through
the mud. My experience with Lispers is they are frequently afraid to get their
hands dirty. And that doesn't cut it except in a pretty-ditty fantasy castle.

~~~
rbanffy
> Regardless, projects of a certain scope (i.e. building a space shuttle)
> require large teams.

The shuttles are not engineering successes. Most large projects (large as in
"lots of brains required to think about how they are going to work") usually
aren't either. I'll side with pg on this. Humans cannot organize that well and
less ambitious steps are a better approach to solve really big problems.

Languages are tools you use to express and think about problems. There are
problems that are more amenable to be expressed in terms of Lisp and others
that are more suited for C. Or SQL, or Forth.

It may be hard to express mud in Lisp, but I don't think the whole thing is as
bad as you do.

But I have to wonder... Does anyone still use mail merge?

~~~
Jd
What are the shuttles if not engineering successes? PR stunts? How would you
categorize them? There are certainly problems (like providing a good and
functional high-speed rail system) that are not really questions of "genius"
and more practical questions of how to apply already developed technology,
which, given the politics of our day, might require a different type of
"genius" to approach.

It is interesting that you describe language as a tool to think about a
problem. Is it really so? Is it only because you have the language that you
think about the problem in terms of the language?

Humans cannot organize that well? Well, I guess Cape Canaveral in 1969 was
smoke and mirrors -- or what do you mean? I think you probably mean that the
cost of organizing at a large scale like that is not a cost you are personally
(or, collectively in terms of the culture of elites in the West) willing to
bear. I would even suggest that it very well could be in actuality an
unwillingness to bear any sacrifice for the sake of a collective goal.

"Less ambitious steps" for "really big problems." Sounds great. What steps do
you mean and what problems are you possibly hoping to solve? How the private
sector might be able to get someone in space -- an "engineering success" that
was already accomplished approximately 50 years ago, now potentially finally
accomplished by the private sector, so long as individual Russian tycoons are
able to pay for $100M tickets with money stolen from starving peasants.

A brave new world indeed. As for mail merge, I have very little interest in
the common man. I live in Silicon valley and watch the world burn from a
carefully-cultivated distance.

------
overgard
Talking about things as broad and vague as "community" tends to obscure things
more than it helps, in my opinion.

A more useful exercise is to consider the factors that go into people choosing
a language in the first place. I don't think people usually think hard about
how powerful or elegant the language is, at least when they're starting out,
rather they pick it up when they need to solve a specific problem. For
example, here's how I ended up using the languages I've learned in the past:

QBASIC - Because I wanted to make video games when I was a kid, and things
like functions and classes and scopes confused 10 year old me. The idea of
executing a sequence of commands was simple enough to grasp.

C - Because that's what all the "real" programmers used, and I had reached the
limits of what I could do with basic.

VB - Because writing a GUI in C sucks.

Perl - Because that's just what you used for web pages at the time.

Java - Because of college.

C# - Because VB was pretty lame.

Python - Because I needed something better to write small programs in, and the
entirety of perl would regularly fall out of my head because it's too complex.

F# - Because C#'s verbosity gets on my nerves and everyone was all up on
functional programming; but I found the library support in most other
functional languages lacking.

Ruby - Because it's kind of the lingua franca of web startups at the moment.

And on and on. I'd say about half the languages up there are actually pretty
awful, and none of them are as good as LISP, but they did something
specifically useful for me at the time I learned them. I can't really say that
about LISP, because LISP doesn't really have a niche. The reason I ended up
learning LISP (Clojure specifically) was because I wanted to be a better
programmer, but I don't think that's really a strong enough argument for it if
people want it to "win"

~~~
hello_moto
I heard that argument many dozen times regarding certain type of programming
languages can make me a better programmer.

Boy I think I took that advise from the wrong source.

Math can make me a better programmer.

Statistics can make me a better programmer.

Accounting can make me a better programmer.

Biology can make me a better programmer.

Chemistry can make me a better programmer.

Building Macros and DSLs are the new Ivory Tower of software architecture.

~~~
neilk
I must strongly disagree with this. Learning functional programming was one of
the best things I ever did. It gave me a huge advantage when tackling certain
problems, which helps me to this day. At my current workplace people call me
in to help when they have tricky problems because they are aware I have a
different skillset.

I started out in 'scripting' languages, and I can even say that learning Java,
in a group with some very skilled OO gurus, was a mind-expanding experience.

I have even seen it happen, en masse, at a company which was composed of
various language partisans uniting under one roof. After exposure to each
others' ways, I think we all become better programmers for it.

~~~
bunderbunder
I agree, knowing it can be huge. I'd even go so far as to say that at work,
colleagues who know functional programming generally write code that is
noticeably more efficient and maintainable. And on some platforms (.NET since
2006 comes to mind), you simply _have_ to be comfortable with FP to be able to
work effectively.

But on the other hand, the days where one could get away with treating 'LISP'
as a proxy for 'Functional Programming' are long gone. Aside from the hoary
old beasts from the 20th century such as Java, pretty much all the major
languages have first-class procedures and suchlike nowadays. LISP is no longer
distinguished by having good support for functional programming; it's
distinguished by _lacking_ good support for procedural programming.

------
rayiner
"The only thing more amazing than the degree to which the author missed the
point of the exercise here is the degree to which he seems unaware that he
missed the point of the exercise."

No, what was amazing was how stupid the exercise was. The Common Lisp example
was a perfectly reasonable translation of the AWK script, accounting for the
fact that Common Lisp is a general purpose programming language that doesn't
have the luxury of dedicating syntax to text-munging the way AWK does.

Also, the whole concept of Lisp "winning" is silly. Common Lisp isn't making a
comeback. Nobody thinks that. But every day that passes, languages get more
like Lisp. Take, e.g., Xtend. We've got:

LAMBDA: <http://www.eclipse.org/Xtext/xtend/#closures> TYPECASE:
<http://www.eclipse.org/Xtext/xtend/#switchexpression> FORMAT:
<http://www.eclipse.org/Xtext/xtend/#templateexpression> Open methods:
<http://www.eclipse.org/Xtext/xtend/#extensionmethods> Multimethods:
<http://www.eclipse.org/Xtext/xtend/#multipledispatch> Also: Statements as
expressions, etc, implicit return, etc.

~~~
KaeseEs
I think you yourself have missed the point when you say, "Common Lisp is a
general purpose programming language that doesn't have the luxury of
dedicating syntax to text-munging the way AWK does". The whole idea was to
make a dialect that did have that luxury as a gateway to Common Lisp.

~~~
merlincorey
Clearly, AWK is the future winner, since it has implemented Lisp[1][2]!

\----

[1] <https://github.com/darius/awklisp>

[2] <http://awk.info/?AwkLisp>

~~~
finnw
By that rule, Greespun's Tenth Rule
(<http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule>) implies that C has
already won.

------
steve8918
There are several problems with this post.

First off, the concept of a language #winning is a complete waste of time.
Neither AWK nor Lisp is Charlie Sheen.

You use a particular language so that you can solve a problem. Some languages
are better suited to solve certain problems than others. You also use a
language because you like it. Using a language because it's popular, unless
your job requires it, is probably the least sustainable situation.

Secondly, I'm inferring the author wants to spur Lisp's popularity by
promoting new features, but encountered resistance by people on a newsgroup
and gave up. This is pretty weak in my book. In what situation, both social or
professional, would someone NOT encounter resistance to new ideas? To give up
at the first sign of resistance, and call the people who didn't like your idea
"sick" is the hallmark of a whiner.

If you want to do something, just do it. No one is stopping you. Fork the
code. Make a prototype. Demonstrate it. See if you are right and they are
wrong. You don't need the approval of a handful of faceless Usenet posters
before you start a project.

~~~
KaeseEs
You're inferring incorrectly (and seem to be conflating Mr. Dominus with Mr.
da Silva), and also brought Charlie Sheen up for no apparent reason.

Also, there are plenty of good things that come with a language being popular.
The availability of libraries, a community to bounce ideas off and get help
from, etc.

------
regularfry
Two things keep coming up in language discussions. The first is the cry of
"Lisp did it first", whenever a non-lisp language touts a new feature. The
second is this concept of "winning".

If you combine these two ideas, you come to the conclusion that if any other
language is seen to be "winning", it should be simple to port that language's
syntax and stdlib onto a lisp environment - after all, every facility the
other language might need can be provided by the lisp runtime, and reader
macros might be a suitable way to avoid an explicit compilation step,
depending on the language being tackled.

I cannot think of a single case of this happening. Instead, we see precisely
the reverse - clojure is implemented on the JVM, CLR and JS runtimes, and
there are scheme implementations _everywhere_.

What does this mean? It means that it isn't languages which "win" or "lose".
It's plaforms. "Lisp" isn't a platform, therefore it cannot "win". The
question is moot.

~~~
sedachv
Your observation about platforms is spot on IMO. This is something that I want
to work on - making Common Lisp a platform.

Having libraries that provide system programming features and work across a
wide range of implementations is the first step. CL is underspecified in terms
of a lot of systems programming stuff.

The #1 priority in this space is integration with the Unix shell - scripting,
having executables, stdin and out, command-line arguments. Not really any good
libraries that combine all this into one thing that works well everywhere.

The second big thing is packaging and distribution - Quicklisp addresses that
well. Next step beyond making Quicklisp better is a script for Linux that
finds the Common Lisp implementation on your system (and installs one if not
present), and loads whatever software you need - essentially a common
installer for CL applications that bootstraps off of Quicklisp.

About other languages on Common Lisp, there is actually a large number:
<http://www.cliki.net/programming%20language>

A lot of languages have been ported to run on various Scheme (Racket and
Gambit) implementations.

~~~
regularfry
Of the implementations on that list, only three are what I'd call "competitive
imports": the JS, Python and JVM implementations. I'm intrigued as to why
these are not generally considered to be viable first-class alternatives.

------
mjd
It might be worth pointing out, for readers who missed it, that this article
was written in 2003. So instead of asking whether it correctly describes the
situation today, you might find it more useful to ask whether it correctly
described the situation in 2003, and whether things have changed, and if so
how.

------
DougBTX
This is the best lisp version of the syntax I've been able to come up with:

    
    
        (awk (begin (set FS ":")) (cond (== $6 "/sbin/nologin") (print $1)) "/etc/passwd")
    

Any better ideas?

(The awk macro itself is an exercise left for the reader...)

~~~
groovy2shoes
I was just thinking about something like this. The beauty of Lisp stems from
the fact that you can take it as-is (as a general-purpose language) and add
constructs that allow for such domain-specific code. The converse, making awk
more general, would be a much more difficult task.

------
thurn
This observation would work just as well if "C++" or "Java" were substituted
for lisp, so I guess those languages will never "win" either.

~~~
argv_empty
_This observation would work just as well if "C++" or "Java" were substituted
for lisp_

"People aren't using Lisp, so maybe we could make it usable for things AWK is
good at and get people into it that way."

Ok.

"People aren't using Java, so maybe we could make it usable for things AWK is
good at and get people into it that way."

Wait, they're not?

------
mark_l_watson
Not to be rude, but that sounded like the kind of thing that a Perl programmer
would say :-)

I am all for people have gut feeling likes/dislikes for what languages they
personally use, but who cares what programming language, religion, politics,
etc. that other people like?

I have been using Lisp since the early 1980s, and Lisp languages are great for
some kinds of applications and research. Same can be said for many other
languages.

~~~
argv_empty
If more people like and use my language of choice, more people will write
tools and libraries for my language of choice.

------
ihodes
It's not about Lisp winning, it's about the people using Lisp winning. And the
people using Lisp are winning.

~~~
jemfinch
Where?

------
sedachv
The joke is now on Dominus and da Silva - awk runs in Common Lisp:
<http://www.foldr.org/~michaelw/lisp/clawk/>

da Silva does have a completely valid point. CL needs a library to make it
easy to run your favorite implementation with your software as a Unix shell
script. And more reader macros. I use so many my code is starting to look like
Perl. I don't think that's a bad thing. Adding an APL reader macro for array
processing would IMO be a wonderful thing for a lot of the Common Lisp
graphics libraries.

------
2nd_planet
Since when have programming languages ever been about winning? Lisp solves
problems in a certain way the works well in certain cases for some people.
Same case with awk or Perl or Python or whatever. Lisp may not be the language
everyone uses for everything, but I find myself writing code in Clojure,
Scheme, or Emacs Lisp because it makes sense to me. So what if that awk
example is 2.5 lines longer than the actual version? It may be more work for
my fingers but I still get to write it in Lisp.

I'm going to be one of the "stupid argumentative people" that he says are on
comp.lang.lisp (which I had never actually heard of before) and say that Lisp
users don't want Lisp to win. People who understand Lisp, as mentioned in
another comment, that _they_ are going to be the ones winning in the end.
Maybe this person wins with Perl. I don't. Ruby, Clojure, Prolog, and
JavaScript meet my needs so I use them. Languages don't compete for adoption
they solve problems.

~~~
giardini
Prolog?

------
sixbrx
I thought the lisp version was actually a lot more readable than the awk
version. I never really messed with awk much though.

~~~
jonathansizz
So you thought the version written in a language you're familiar with was more
readable than the version written in a language you're not familiar with?

But seriously, take a look at the two examples again. Are you really
suggesting that the Lisp version is easier?

All you have to understand for the Awk example how field variables work, then
you can read the whole thing at a glance. The Lisp version contains custom
macros and is four lines long!

~~~
rayiner
For someone who doesn't know either, but is familiar with programming
generally, which is more readable?

I can guess what 'with-lines-from-file' does, I can guess what 'string-split'
does, i can guess what 'string=' does, etc. The only thing I might not
understand is 'aref'.

With the AWK example, I have no place to start. Symbol-oriented languages,
rather than word-oriented languages, are like that. They tend to be more
concise for things very specialized tasks, like this, but that limits their
generality. Show me a matrix multiplication routine in AWK versus Common Lisp.

~~~
wanorris
It is both strictly correct and irrelevant to the topic at hand that the Lisp
is easier to read. Because that's like saying "Lisp sucks because WTF does
'cddadr' mean anyway?"

AWK is a purpose-built language for splitting lines into fields and doing
stuff with the result, so of course there's not a lot of boilerplate for
splitting lines into fields and doing stuff with the results.

Lisp for doing a lot of fancy work with s-expressions is going to be high
density code that's a lot harder for newcomers to read than verbose, plodding
Java code that is working with a simple LinkedList class or something.

Readability (Edit: to newcomers) just isn't the relevant benchmark here.

~~~
tikhonj
I don't think a linked list in Java is a good example. I took two CS intro
courses in a row last year; the first one used Scheme and the second one
concentrated on data structures and used Java. There were some completely
inexperienced people taking the two courses along with me.

As far as I could tell they had much more difficulty with linked lists and
trees in Java, which made them needlessly complex, than they did in Scheme.
And this is with people who had actually learned about both concepts first in
Scheme, so they had _more_ experience when they came to Java.

~~~
wanorris
Fair point. Perhaps I picked a bad example.

At the same time, if you were writing a bunch of random awk-like one-offs as
part of your normal lisp workflow, you wouldn't write 4 lines of code every
time, right? You sit down and write some functions or macros that condensed it
into something simple that allowed you to easily specify things like a split
token, one or more filter-on fields and values (or better, a filter lambda),
and one or more output fields, I bet. Because it's silly to write several
lines for something you do a lot.

And while you might call it process-file-and-return-matching-results or
something, the interface to the result might not be so different from the line
of awk in the original post.

------
buster
Did someone read the notes on Slide 47 and the message for aliens? Now that
was interesting.. tried to understand them on my own, sort of fun :)

------
gtani
I think the only languages that will ever have won were C, cobol and fortran.
Why do we get"scala is too complex" posts but not "partial differential
equations are too complicated" posts? Anyway I'm just not going to read them
but I will cut MJD slack cause his perl books are terrific.

------
jwr
Try Clojure and see how insanely awesome the community is. 2003 was a long
time ago.

------
phzbOx
I was arguing with a lisper the other day about how lisp' power make it easy
to go overkill and have too much nested lambdas.. while language like Java,
forcing you to use vars, sometime makes the code easier to read.

He then told me to not blame my weakness at reading code on Lisp.

------
kingkilr
That's impressive, both the awk and the lisp versions of that code seem pretty
obfuscated.

~~~
irahul
The awk version looks idiomatic to me. Except that I will take the FS out:

    
    
        awk -F: '$6=="/sbin/nologin" {print $1}' /etc/passwd

~~~
d0mine
There might be off by one error. On my system the following works:

    
    
      awk -F: '$7=="/usr/sbin/nologin" {print $1}' /etc/passwd
    

Or

    
    
      awk -F: '$7 ~ /bin\/nologin$/ {print $1}' /etc/passwd

~~~
irahul
Yes, indeed it should be $7 instead of $6.

I didn't run it when I posted the comment. I just copied it from the article.

------
wildster
In the words of Douglas Crockford, Javascript is Lisp in C's Clothing.
<http://javascript.crockford.com/javascript.html>

~~~
frou_dh
...and it still makes no sense no matter how often it's repeated to flatter
JavaScript.

~~~
tikhonj
I think it does, actually. When I took a Scheme class based on SICP, we
implemented a Scheme interpreter as well as looking at an OOP system using
lambdas.

Writing that interpreter is the first time JavaScript's scoping rules made
sense to me viscerally--they're exactly the same as Scheme's. The OOP system
we used was also really similar to what you can do with JavaScript; it just
used closures to save state. It wasn't exactly the same, but it was similar.

Ultimately, I find that JavaScript is much closer to Scheme than other dynamic
scripting languages I've used like Python and Perl.

~~~
groovy2shoes
JavaScript's scoping rules aren't the same as Scheme's -- variables are scoped
at the function level rather than the block level.

~~~
tikhonj
That's how it works in Scheme too--you only get a new scope if you either have
a lambda or an implicit lambda.

~~~
groovy2shoes
Sure, but in Scheme every block is an implicit lambda. In JavaScript, blocks
are justs sections of code.

------
georgieporgie
I've been working on getting started in Scheme. It hasn't been easy. It seems
like it's entirely married to Emacs, and I really, really don't want to learn
Yet Another Editor. I'm finding the documentation to be very terse and
unhelpful. Tutorials, guides, and documentation all drop terms casually which
mean absolutely nothing to me. The key chording seems nonsensical. So far,
I've spent about one hour learning Lisp, and many hours learning how to
install and use the Scheme interpreter.

(I realize that it probably sounds silly to complain of learning "yet another"
editor, when it's one of the two longest-lived for programming, but really,
Emacs is _extremely_ complex, and all I want to do is work through SICP)

As for the article, his description sounds like comp.lang.* .

~~~
rayiner
<http://racket-lang.org/>

Easy GUI IDE with debugging, etc.

It's annoying to learn another IDE< yes, but Scheme just needs an IDE that
understands how to highlight/indent it properly.

~~~
georgieporgie
Awesome, thanks for that! I was up and running a sample within five minutes.

~~~
spacemanaki
If you're reading SICP you may want to look into this:
<http://www.neilvandyke.org/racket-sicp/>

It's a package to support some code in the book that is some what
implementation specific, drawing graphics for the picture language, for
instance.

------
xyzzyz
Hey, this is cool, using awk you can save a minute for every one-liner you
write. Writing 2 one-liners per day on average, it's only half a year to make
up for a day spent on learning awk!

More seriously, if I wanted to save few minutes per day, I'd rather remove
Facebook account.

