
How knowing Lisp destroyed my programming career (2006) - tinderliker
http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006-04/msg01644.html
======
kabdib
I learned C and LISP pretty much at the same time (back when rocks were young
and you needed a PDP-11 if you wanted to run Unix). Then I went to college and
the first course in the Computer Science major was a "killer" they taught in
Pascal. Okay, so Pascal is a kind of screwed-up C, and I could deal with that.

That "killer" course had a semester-long, multi-phase project that was a kind
of symbolic calculator (with sets and operations on them). It was maybe a
couple hundred lines of LISP . . . so I wrote a LISP interpreter in Pascal
(with a garbage collector, natch), then wrote the meat of the project in LISP,
embedded in the Pascal source. Was the only person in a class of 300 or so who
completed the project that semester, but the professors were not amused with
the approach I took. Can't imagine why :-)

I've never used a functional language in production, but I've stolen LISP
techniques and used them in quite a few products. I never felt frustrated by
the fact that I couldn't use LISP or Scheme or whatever in <product> and had
to use C/C++/Pascal/Java/C# instead, but have seen it happen in other
engineers (notably when the Apple Newton switched from Dylan -- an object-
oriented variant of Scheme -- to C++; there were a bunch of forlorn looking
ex-Scheme hackers wandering the hallways, clutching copies of the C++
Annotated Reference Manual and trying not to cry).

~~~
timbit42
Technically, both Pascal and C are derivatives of Algol. Pascal is a variation
on Algol. C is a screwed-up Algol.

~~~
kabdib
Point taken. Though "call by name" still makes me twitch :-)

------
phoe-krk
_The conclusion was inescapable: the problem wasn 't Perl or C++ or Java, it
was me. I just wasn't a very good programmer any more. Lisp's power had made
me complacent, and the world had passed me by._

Lisp can't help you if you're too smug for your own good.

Disclaimer: I'm a Lisper.

~~~
quintin
Non-English speaker.

What does "smug" mean?

~~~
YeGoblynQueenne
It means "smartass".

~~~
rkangel
Not quite. "Smartass" generally implies you go around showing off your
(perceived) knowledge. "Smug" implies you sit quietly in a corner feeling good
about your (perceived) knowledge.

~~~
Can_Not
Also smug is less specific than knowledge, it's more about thinking you're
better (in some or all ways) or more well achieved. The opposite of humble.

~~~
b2gills
I would say that smugness has almost nothing to do with knowledge, and
everything to do with attitude.

I have seen people being smug that they know nothing about a given subject.

That is smugness is almost exclusively about “thinking you're better…”.

If someone thinks they have more knowledge, or thinks they have achieved more;
it is easier for them to become smug in that belief. People can also become
smug even if they know that neither is true.

------
Francute
The problem wasn't lisp... The problem was he didn't want to leave his comfort
zone.

You can love lisp, Smalltalk, and all those beauty languages, but you should
never stick to a single language. NEVER. Go to another, look it's strenghts,
and if it's a bit weak on some sides, try to use the nice techniques you
learned back to make it better.

To solve any problem, you can use different languages. Of course would be nice
to use the nicest languages, but in some contexts they're not the right tool,
and in others, you should have to consider outside factors like, how many
people will maintain that software. All of them knows how to use the powers of
those nice languages? Also, do you think would be easier to rotate people on
that project using those languages instead of another ones?

Everyone can learn to use some tool, but experience using others may help you
to discover better ways to use new tools.

------
OceansOnPluto
Worked at Google Pre IPO, worked at the Jet Propulsion Lab, became an Angel
Investor, acquired Startups, founder and CEO of Spark Innovation Labs....

....I hope to one day have my career destroyed as badly as this.

~~~
user404d
Maybe he didn't leave his mark as a programmer/engineer the way HE wanted to,
but you definitely have to admire his ability to identify good opportunities.
He laments choosing and then using LISP for so long and in a way seems to
blame the language for adversely affecting his perspective on programming, but
it really seems like it served him well when it was useful. I think the same
intuition that helped him choose LISP for solving problems (because it was a
nice set of tools at the time) probably ended up helping him choose good
professional opportunities, too. If he's frustrated about the way his
perspective changed then I have to agree with the other commenters that he
would need to work on changing that perspective and not remain complacent.

------
submeta
Honestly curious why Lisp has so much admiration and praise on HN. I played
around with Scheme some long time ago, read SICP, learned a lot. And I know
Lisp inspired many programmers like the founder of Ruby. But I would not think
of Lisp when it comes to solving day to day problems. I rather pick Python
because it helps me solve all kinds of problems. There are many more solutions
I can think of (Ruby, Node, Go, even Perl).

~~~
Jach
Your confusion will go away once you recognize that Scheme is not Lisp. For
most purposes, Lisp means Common Lisp, or one of the Lisps that ended up
merging into Common Lisp. That means that Lisp does all of these things and
more, which you might not expect if you've only seen Scheme/SICP:

* Multi-paradigm programming (functional programming in the immutable sense is not dominant, the Lisp OOP system is top class, mutable state can be everywhere)

* Rich looping mechanisms that don't require tail call contortions

* Explicit typing that leads to optimized code and compile time warnings! ([https://news.ycombinator.com/item?id=13389287](https://news.ycombinator.com/item?id=13389287))

* Warnings at compile time (not run time!) about things like undefined functions/vars/wrong args/unused vars ([https://news.ycombinator.com/item?id=14780381](https://news.ycombinator.com/item?id=14780381))

* A pretty good set of libraries et al that (once you set up quicklisp) are just a function call away from trying out ([https://notabug.org/CodyReichert/awesome-cl](https://notabug.org/CodyReichert/awesome-cl))

* (edit: one more since I like it a lot) Out of the box the Lisp system contains features you have to get from IDEs in other languages like breakpoints, tracing, inspection, code location questions like "who calls foo"... of course working with that system via emacs or something is nicer but it's basically all there in the base system ([http://malisper.me/debugging-lisp-part-1-recompilation/](http://malisper.me/debugging-lisp-part-1-recompilation/))

~~~
firepoet
To add to the confusion, this Wikipedia article says that Scheme is "one of
the two main dialects of Lisp."
[https://en.wikipedia.org/wiki/Scheme_(programming_language)](https://en.wikipedia.org/wiki/Scheme_\(programming_language\))

~~~
bjoli
Well, it was true, at least until clojure. Now we've got clojure, common lisp
and scheme.

~~~
kamaal
Lisp user base is so small enough that these categories largely look pointless
to people outside.

For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

~~~
lispm
> For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

Since only CL and Emacs Lisp can and do share actual Lisp code, I call only
them Lisp for practical purposes.

For 'unpractical' purposes - they share no source code but are influenced by
practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.

~~~
kamaal
>>Since only CL and Emacs Lisp can and do share actual Lisp code

But what exactly is 'actual lisp'. I mean what is this strict definition?

Forgive me, I understand calling Scheme and CL as same might feel like saying
Java and C++ as same. But one would be right in saying Java and C++ both come
from a C based paradigm.

On the same lines one could say CL and Scheme come from lisp paradigm. At this
point in time both communities compared to any major language community are so
small that one could refer to both as Lisp.

~~~
lispm
The problem is that both CL and Scheme communities have very little to do with
each other.

For practical purposes Lisp dialects are those directly inheriting back to
Lisp I from McCarthy. You can run programs from 1960 in Common Lisp with very
little changes (unless it uses machine interfaces). To port them to Scheme is
possible. To port them to Logo, Clojure, Javascript or other languages
considered to be dialects in a wider sense mostly means a rewrite.

Thus for me Lisp means the dialects of Lisp and their respective communities
which can share code, libraries, applications by relatively simple ports. For
example Emacs Lisp has Common Lisp enhancements, which are semantically very
similar. ISLISP could be directly integrated into a Common Lisp - Kent Pitman
mentioned that he actually did that to see that they are culturally
compatible.

Languages who don't directly share code are maybe part of an abstract family,
which has no agreed on definition - thus this is for practical purposes
relatively useless.

~~~
flavio81
>The problem is that both CL and Scheme communities have very little to do
with each other.

At first I thought this was absurd, but after some time learning Lisp this was
more obvious.

Scheme and Common Lisp are built around totally different philosophies, and
thus not only the languages diverge, but also the way you program in them.

------
d3ckard
For a while now I've had a feeling that all the comments about lack of
engineers(especially in software) are vastly underestimated. Probably around
10% of us is capable of doing actual software development. The rest writes
plumbing and can handle the project for only as long as abstractions available
through libraries can hold the complexity.

If we assume most of us don't really know what we're doing, that totally
explains language preferences. We don't choose the best tools, we choose the
best tooling. And best tooling is the one which we can comfortably fit in our
minds, so advanced concepts are mostly ignored and the hype wheel constantly
turns. To put it shortly - smart people write better and better tools, so the
rest can handle bigger and bigger projects writing mediocre code.

Of course, as every programmer, I live in constant fear that I am part of the
plumbing crowd waiting to be exposed.

~~~
pjc50
Maintaining a distinction between "actual software development" and "plumbing"
is elitist, even if you're placing yourself on the downside of that comparison
and setting yourself up for imposter syndrome.

You can get an awful lot done by "plumbing". Entire businesses like SAP are
built on it. It can also be mission critical; in SpaceX, is the literal
plumbing of hydraulic fluid and fuel flow unimportant? No.

~~~
d3ckard
I'm not trying to impose that one is more "noble" than the other. As you said
yourself, businesses usually run on plumbing.

I'm trying to understand the industry, as it appears to be(at least to me)
different than what I thought was true. I believe it to be important if we're
going to do better and there is a ton of metrics showing we should do
better(percent of projects failing, percent on projects exceeding budget and
time, percent of projects becoming unmaintainable).

If you could prove that only a handful of people is capable of actually
developing software project pass the stage of 'piggy-backing' on libraries,
that would probably distinctly change the way we develop software. Maybe we
could prevent death marches better. Maybe we could improve our working
environments so nobody has to crunch or have a depressing spaghetti-code
maintenance job.

It doesn't mean in any way that 'plumbers' should/would be treated worse. If
anything, I would expect the opposite.

~~~
vilhelm_s
Indeed, the "plumbing" role is getting more and more important as there are
more reusable software out there, so less need to write it from scratch.

It reminds me of how MIT changed their intro-to-programming course, from the
Scheme-based one to a python based one, because "the SICP curriculum no longer
prepared engineers for what engineering is like today. Sussman said that in
the 80s and 90s, engineers built complex systems by combining simple and well-
understood parts. The goal of SICP was to provide the abstraction language for
reasoning about such systems. [...] programming today is “More like science.
You grab this piece of library and you poke at it. You write programs that
poke it and see what it does. And you say, ‘Can I tweak it to do the thing I
want?'. The analysis-by-synthesis view of SICP — where you build a larger
system out of smaller, simple parts — became irrelevant."
([http://www.posteriorscience.net/?p=206](http://www.posteriorscience.net/?p=206))

Also reminds me of Vernor Vinge's "Zones of Thought" novels, where in the far
future, the starships don't have exactly programmers, but rather a kind of
software archelogists who assemble systems from software components that may
be a thousand years old.

~~~
itronitron
Yes, and virtually all software job postings/interviews are tests for
experience with specific fittings (abstractions/frameworks)

------
garganzol
I came to Lisp (Scheme/Racket) from that another side (C++, Java, Perl) and it
was an enlightening experience.

Now I use Lisp nearly everywhere in a form of a small .NET runtime module.

Lisp is excellent at templating tasks. Just for comparison: StringTemplate for
.NET is a whooping 400 kB of compiled binary code while my implementation of
Lisp is just 35 kB (!). Sure enough, Lisp does the very same thing as
StringTemplate, but in just 1/10 of the code. There is more: Lisp is Turing-
complete while StringTemplate doesn't. I can add a .NET function to Lisp
environment and then call it in my template. I cannot do that with
StringTemplate. I repeat, this is a 35 kB Lisp David vs 400 kB StringTemplate
Goliath.

Isn't Lisp beautiful?

But wait, there is more. Lisp is excellent for natural language processing
because you can intersperse a human text with Lisp. Suppose the first %
character enters into Lisp mode and subsequent % character exits back to text.
The example of Lisp NLP would then look like:

    
    
        "Hello %name%. It is time to do some math. Assume A + B = %(+ a b)%. What is the value of A when B is %b% ?"
    

You then fill Lisp environment with desirable values:

    
    
        env["name"] = "David";
        env["a"] = 15;
        env["b"] = 85;
    

Evaluating aforementioned template will produce the following result:

    
    
        "Hello David. It is time to do some math. Assume A + B = 100. What is the value of A when B is 85 ?"
    

With that tool at hand, you can build a user-configurable quiz system in no
time. Or maybe a configurable Virtual Assistant. Or a chat bot. Or anything
else, you name it.

Lisp is small as the Universe before Big Bang. Nevertheless it provides nearly
endless possibilities when you have a need, a fit and imagination for them.

~~~
zelos
Although that approach to string creation tends to fall apart quickly in non-
English languages: adjectival agreement, plural rules etc.

~~~
garganzol
No, no, it doesn't fall apart! Lisp is Turing-complete. You can do (in
English):

    
    
      "David has %n% apple%(when (> n 1) "s")%."
    

You can move that rule to function etc. You can tweak that for the language
you use in an endless number of ways.

~~~
chii
so you're going to ask your translater to learn Lisp?

~~~
kazinator
No; you just give an example about how to customize the suffix based on the
number, but don't say that it is "programming" or "software development" or
anything like that.

[https://www.gnu.org/gnu/rms-lisp.en.html](https://www.gnu.org/gnu/rms-
lisp.en.html)

 _" Multics Emacs proved to be a great success — programming new editing
commands was so convenient that even the secretaries in his office started
learning how to use it. They used a manual someone had written which showed
how to extend Emacs, but didn't say it was a programming. So the secretaries,
who believed they couldn't do programming, weren't scared off. They read the
manual, discovered they could do useful things and they learned to program._

------
watwut
> knowing Lisp made me all too keenly aware of Java's shortcomings, and I had
> a very hard time not being angry at how stupid it was that I was being
> forced to use it.

I would take this as a the thing to remember from this. When you are too angry
at something, you cant learn it. I have seen the emotional refusal to learn
new inferior thing (or read comments that amounted to the same) many times
already.

It is something to be aware of and avoided.

~~~
incompatible
I'm interested in knowing your secret to finding inferior new things
interesting.

~~~
watwut
Often times it is inferior, because you are acutely missing things it does not
have, but did not yet learned to use things it does have effectively.

So, the secret is to be alone in a room, so you can swear freely. Walk around
when angry and complain to yourself. But always go back and continue using it
and eventually, that phase will pass. After that you will build new set of
habits that work around disadvantages and use advantages.

~~~
LandR
This just seems like being around something awful long enough that you develop
a form of stockholm syndrome.

~~~
watwut
Unless of course your perception that it is "objectively" awful is not
objective at all. The "awful" categorization is oftentimes just your emotional
reaction to not understanding something immediately and not knowing how to use
it effectively.

~~~
watwut
I would add one more thing - even if the technology is objectively awful, it
is worth learning if it serves some practical purpose. Learning something is
not value judgement of its objective quality, it should be in part rational
choice.

------
d--b
This is from 2006 though.

Since then functional programming has picked up a lot of steam again, and I'm
pretty sure having been a lisper for 30 years gets you good jobs. If not in
Lisp, haskell, F#, clojure or whatever...

~~~
jcadam
I don't know. My industry (defense/aerospace contracting) is still infatuated
with Java/C++ and Object-Oriented Design as the universal solution to all
problems. It's like being stuck in the 1990s.

This is the flip-side to age-discrimination - it's much less of a problem in
my industry. Which, as a 37-year-old I find comforting. But when you're stuck
working for 50-something pathologically risk-averse architects who built their
careers on the over-hyped tech of the previous century and refuse to listen to
new ideas, it's quite frustrating. I'm basically waiting for the previous
generation to die/retire so I can have the chance to build software the way I
think it should be built.

I may just leave the field altogether and hack on Lisp in my spare time :)

~~~
oblio
> I'm basically waiting for the previous generation to die/retire so I can
> have the chance to build software the way I think it should be built.

And by the time you'll be able to do that you'll be the 50-something who keeps
using functional programming while the 37-year-olds want to use dilithium
crystal programming :p

~~~
mercer
While you're joking, one thing that appeals to me about my recent dive into
functional programming is that it strikes me as knowledge that is
'fundamental' enough that it'll never disappear or become irrelevant.

~~~
StavrosK
Exactly like OOP!

~~~
jcadam
Though, I'll point out that my problem is not necessarily with OOP, but OOD.
OOP can be quite useful in _some_ situations, such as modeling and simulation
:)

Of course the design of the Java language is predicated around the idea that
OOD is the one true way to design large software systems and thus must be
forced by the language itself, and that is the primary reason I hate it.

------
_mrmnmly
The point of this article can be compared to JavaScript devs fatigue story:

1\. Many JavaScript devs were focused on 'getting job done' in their current
workplaces, where they were using jQuery-related stuff mostly.

2\. After some time they want to change job.

3\. They realize that the js market has changed (or maybe they were aware of
it, but they just didn't care before/didn't have time to take a closer look
before).

4\. They try to keep up and learn tons of stuff to be employable as js/front-
end devs (npm/webpack/js frameworks).

It's just a personal opinion. I was at that point in my life before too (and
realized that it was my personal cause of my js fatigue)

------
peteretep
> I saw people whip things up in Perl in a couple of hours that would have
> taken me days or weeks to do in Lisp.

Perl, my first and only love.

~~~
dozzie
Mine too. Until Erlang, and now Ada. I'm building myself a harem.

~~~
3chelon
That's the second time I've seen Ada mentioned in as many days. Before that, I
did Ada as an undergrad about 1989 and never heard of it again. Is it becoming
a thing again?

~~~
pjmlp
In Europe yes, Ada has been a constant presence at FOSDEM in the last decade
and many universities.

This has taken off since we finally got an open source Ada compiler (GNAT)
without the typical enterprise/military prices.

Also Ada 2012 is quite different from Ada 83.

Then we have this, [https://www.cvedetails.com/vulnerability-
list/opmemc-1/memor...](https://www.cvedetails.com/vulnerability-
list/opmemc-1/memory-corruption.html) increasing exponentially every day
thanks networked computers.

------
Dude2023
A required thought-piece for all JavaScript devs. Enjoy monopoly while it
lasts, but be humble.

~~~
pavlov
Fortunately JavaScript doesn't have the problem described by the OP:

 _" With a secret weapon like Lisp in my arsenal in 1986 I could blow my
competition out of the water with one hand tied behind my back and holding a
martini in the other."_

A present-day JavaScript practitioner will have his left hand busy trying to
figure out what's this week's fashionable way to pass around some data in this
month's fashionable framework and his right hand busy trying to make npm and
Webpack work, leaving no time for martinis or blowing anyone out of the water.

~~~
kalkut
JavaScript is for HN what sex is for highscool : those who talk the most about
it are those who practise it the less.

If JS devs were not able to focus on bringing value they wouldn't be able to
hold jobs, build products nor profitable companies. If JS was so impratical
there would not be so many people choosing it over various alternatives for
building GUIs, games, websites, WebGL/WebVR, back-end services and so on.

If there is a warning in this story, it is a warning to people looking down on
rising languages and frameworks. Those are the people risking to become
irrelevant because of a mix of smugness, gatekeeping and ivory tower syndrome.

This attitude is exactly what lost Ron Garret when C++ and Java happened. This
also prevented him to see (before the very end of his programming career) that
the competition was actually doing just fine with the new tech. You and grand-
parent totally missed the point of this story.

PS: You don't make npm "work"

~~~
pavlov
_JavaScript is for HN what sex is for highscool : those who talk the most
about it are those who practise it the less._

I was using JavaScript professionally in 1999 and still write it almost every
day. Not sure what that makes of your sex analogy: maybe I'm the middle aged
guy who goes "free love used to be much better in my day"?

You probably know what I meant by "make npm work" — dealing with the messy
dependency ecosystem and the less than ideal tooling.

~~~
kalkut
I concede that I know what you meant by "make npm work" but I am sorry to hear
that you have your _left hand busy trying to figure out what 's this week's
fashionable way to pass around some data in this month's fashionable
framework_ and your _right hand busy trying to make npm and Webpack work_.

More than 18 years of it must have been such a chore. I am glad this is not
how either my coworkers or I spend our time using JavaScript professionally.
Maybe I am very lucky, or maybe I just can spot a stereotype when I read one.

More seriously if you still use JavaScript after all those years that very
likely proves the point that you can actually be productive with it.

~~~
pavlov
Yes, you can be productive in JavaScript. But it’s not a magic bullet like
Lisp supposedly was for the OP’s author in 1986.

I find I’m roughly as productive in JavaScript as in C. Webpack feels more
complex than CMake. That’s a rather low bar for productivity.

------
jbreckmckye
Using any language for twenty years straight is going to make you complacent -
but goodness, how many languages would have given you that luxury?

~~~
pavlov
The APL / J / K family of languages seems to be very strong with this effect.
If it fits your problem domain, it's (apparently) so powerful that using
anything else feels like a frustrating waste of time.

~~~
nickpsecurity
Those of you interested in APL/J/K might find Iverson's book Elementary
Algebra interesting where he defines lots of operations in array notation. I
dug up this PDF looking for one that was out of print:

[http://www.softwarepreservation.org/projects/apl/Papers/Elem...](http://www.softwarepreservation.org/projects/apl/Papers/ElementaryAlgebra)

~~~
contingencies
Texts of that era remind us of the brilliance of Knuth.
[http://en.wikipedia.org/wiki/TeX](http://en.wikipedia.org/wiki/TeX)

------
6ak74rfy
On a tangential topic : I am intimidated by how myriad experiences with
programming languages HN commentators on this thread have. I have been in this
industry for about 8 years and am considered an above average developer in my
current company. I have primarily worked with Java, while fiddling with others
here and there. No experience with pure functional languages such as Lisp or
Haskell. Am I missing out some important part of the developer experience?

~~~
surprisetalk
I like to think of each programming language as a separate musical instrument.

If Java is a tuba, then maybe Python is a trumpet. They're two very different
instruments, but they share a lot of the same underlying intuitions. In fact,
I would say that C-style languages are probably equivalent to the collection
of brass instruments. There are major variations from trombones to trumpets to
french-horns, but not as large as you'd think.

So if you've only played tuba, what happens when somebody hands you a violin?
You may understand "music theory" (or computer science) pretty well, but
actually sitting down to learn the violin will give you strange insights that
aren't apparent on brass instruments. For instance, violins' strings are tuned
perfect-fifths apart -- certain scale patterns naturally jump out at you. In
the same way, let's compare Haskell/Idris/R to stringed-instruments. It's easy
to switch between them when you realize that a viola is a cello is an upside-
down bass-guitar. And at a higher level, learning violin and tuba together
will make you better at BOTH instruments! As a bonus, playing music is more
fun when you can antipate the habits and difficulties of your peers'
instruments.

As a side-note, I think Lisp is either a piano or a theremin. I'm not sure
why.

Anyway, I think learning each "family" of languages is a worthy aim for every
engineer. Here are the groups that I personally hope to master over my
lifetime:

    
    
      - Hard         : Assembly
      - C-Like       : C, Java, Python, JS, PHP, etc.
      - Pure Fun     : Haskell, Idris, OCaml, Elm, etc.
      - Distributed  : Erlang, Elixir
      - OO           : Smalltalk
      - Lispy        : Scheme, CL, Clojure
      - Stringy      : BASH, Perl, SNOBOL
      - Code-Golfy   : APL, J, K, AntLang
      - Stacky       : Forth, Joy
      - Data-Driven  : R, Mathematica, Wolfram Language
      - Logic-Driven : Prolog
    

This list is long, but don't let it discourage you! Every family has plenty of
magical ideas that make the next one easier to master.

Best of luck on your journey!

~~~
vgy7ujm
Perl fits into C-Like, Pure Fun and Code-Golfy in addition to Stringy.

~~~
b2gills
In general languages tend to focus on one thing, where Perl tend to focus on
many things. So it is difficult to classify.

In addition almost everything that is easy in Perl 5 is also easy in Perl 6,
but it also makes a wide variety of additional things easy. For example there
is are several meta operators for dealing with lists.

    
    
      (1,2,3) Z+ (10,20,30); # (11, 22, 33)
      [Z+] ( (1,2,3), (10,20,30), (100,200,300) ); # (111, 222, 333)
    
      [Z*] (1,2,3,4,5), ( 10 xx Inf ), ( i xx Inf ); # (0+10i, 0+20i, 0+30i, 0+40i, 0+50i)
    
      ((1,1),(2,2),(3,3)) «+» ((40,50,60),)
      # ((41, 51, 61), (42, 52, 62), (43, 53, 63))
    

So it has a lot in common with data-driven languages.

There are also features which you might expect to see in a distributed
language.

Basically if there is a choice between A and B, Perl tends to choose both.
With Perl 6 doing this to a greater extent than previous Perls.

------
coding123
Unless you truly are a one-man army - one must absolutely be paying attention
to the tiobe index. Even if the worst possible language is on top, its the one
language that can't "destroy your career". It's 10 times more valuable to be
programming the same language in a company than be the one Lisp or D or Erlang
guy that writes side programs that no one will help you maintain - and will
definitely be re-written in Java when you leave.

------
daef
derkeiler.com gets blocked by uMatrix: the domain appears in Dan Pollocks
hosts-file
[http://someonewhocares.org/hosts/](http://someonewhocares.org/hosts/) in the
'ads' section.

~~~
jwilk
The post on Google Groups:

[https://groups.google.com/d/msg/comp.lang.lisp/GMx6gjESVZw/-...](https://groups.google.com/d/msg/comp.lang.lisp/GMx6gjESVZw/-j-YNe4QbGkJ)

------
siddboots
Man. That's a refreshingly humble outlook.

------
tmaly
It reads like a tortoise and the hare story.

I have only minimal exposure to Lisp, Prolog, and ML in a programming
languages concepts class in the mid 90s.

I really enjoyed using Prolog in the class and had an opportunity to use it
professionally twice.

------
Vektorweg
I was a C++ fanboy, before I had to deal with Lisp in college. While Lisp
itself seemed unusual with all the parentheses, it had a few good ideas I
really missed in C++ . That was the point where I looked for languages similar
to Lisp and that lead me to what I'm working today with: Haskell.

------
dmitriid
> Lisp's power had made me complacent, and the world had passed me by.

This is very true, especially now. With all the available tools, and
libraries, and infrastructure tools, and ..., and ..., and ... the choice of a
programming language hardly matters anymore [see caveats below]. What matters
is how comfortable you are working with a particular language and set of
technologies you chose, and if your choices do not impede you.

[caveats]

Of course, you you want to crunch numbers, or work in a memory/CPU-constrained
system, or develop avionics software, then your choice of programming language
matters. But let's be honest: the vast majority of us don't do any of those
things, and you can whip up a geographically-distributed, auto-scaling cat
meme delivery system in any language in a matter of hours.

~~~
lispm
The eco-system largely defines the programming language to use. There are some
ways to escape that and people try to do that all the time with huge costs,
but on the JVM the majority of software is written in Java, on .net it is
written in C# and on iOS it is Objective-c / Swift.

------
zaro
Yeah, I totally agree with the sentiment of the article. While Lisp my have
been cool in the 80s, it's not the 80s anymore and nobody wants to write AST
directly.

No matter how powerful the technique , it's way too low level for the modern
world.

~~~
frou_dh
Pecking out the ASCII tokens and punctuation of mainstream languages isn't a
'high-level' experience either.

Syntax is _way_ down the list of difficult things in the craft of programming,
compared to properly understanding problem domains, internalising techniques
for robustness, etc.

------
nostalgeek
> Sun, 23 Apr 2006

I think it matters since languages like clojure are everywhere, including at
Google.

------
wheresvic1
Oh wow, I was first introduced to Java in my undergrad and somehow I had some
serious issues with the whole OOP stuff.

Thankfully, I took some AI courses, which came with LISP and I was so excited
to use it everywhere.

Unfortunately, however, doing basic I/O, networking (this is around 2006) and
testing was too complicated for me so I dropped it again in favor of C++ in
grad school (performance was also an issue, we needed to crunch a lot of data
fairly quickly).

I would love to go back again and give it a shot - any pointers on the best
way to learn/start?

~~~
zeveb
Practical Common Lisp[0] remains the near-standard text, I believe. It's
amazingly good, and shows how useful it can be to develop one's own syntactic
abstractions with the practical example of an MP3 ID3 parsing system. I can't
recommend it highly enough.

Peter Seibel's second book Coders at Work is also excellent.

0: [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

~~~
wglb
I agree about both. What I liked about Coders at Work are some of the
questions he asked the folks. 1) Do you like/program in C++ 2) Have you read
TAoCP?

Knuth (interviewed last) claimed that he hadn't really read it. And only one
person interviewed did. Oh, also, there seemed to be a general disdain for
IDEs.

------
zaarn
I think the problem there was complacency, as the author mention in their
mail. On the other hand, I totally do recommend that everyone picks up some
tutorial or guide or book on LISP and learns what the fuzz is all about.

Even today, I feel like a lot of people could learn a lot from LISP and
S-Expressions, both of which are powerful constructs.

(Note: I'm not saying you should use LISP productively, it's something you
should learn for the heck of it, not to actually use it)

~~~
baldfat
People really should learn Racket through this book: "How to Design Programs,
Second Edition"
[http://www.ccs.neu.edu/home/matthias/HtDP2e/](http://www.ccs.neu.edu/home/matthias/HtDP2e/)

Dense and very complete into learning a Lisp. The one HUGE benefit is I see
Racket moving into the most modern programming Lisp. Racket really looks like
it has a future.

1) Concurrency and Parallelism (Without pull all your hair out) -
[http://docs.racket-lang.org/reference/concurrency.html](http://docs.racket-
lang.org/reference/concurrency.html)

2) Great Documentation [http://docs.racket-
lang.org/reference/index.html](http://docs.racket-
lang.org/reference/index.html)

3) It will make you a better programmer in other languages

Racket's biggest problem - It's fun to use so everyone has their own solutions
for many common problems.

~~~
sedachv
+1 for HtDP. I think it is also a really valuable book for anyone coming from
JavaScript who wants to actually learn how to do functional and reactive
programming properly.

------
SlowBro
So me being entrepreneurial-minded, I read this as: He was no good for the
common programming languages of the day used by many employers. But if he
would have struck out on his own, he would have crushed the competition who
were writing page after page of code when his own one page would do just fine.

Disclaimer: Not a Lisper

~~~
Jtsummers
Except by the end of the post he finds programmers in those “inferior”
languages (by measure of verbosity which was a main criteria he used to rule
them out for himself) were keeping up with him. And some, like the Perl
coders, were faster than him on some tasks.

~~~
SlowBro
Thank you, I only skimmed the post.

------
neo2006
The biggest issue we are facing as a profession is abstractions. Most of us
are good at abstracting things because this is the way we cope with
complexity. But the moment we need to face that abstraction and need to
understand what is hiding behind it we can reach some limit. A very common
example I noticed with Java developers who use frameworks like spring, they
use spring tooling to cope with code complexity and are able to put together a
functional piece of code in minutes, but as soon as you get them out of the
spring framework and ask them to code without using their toolbox, you can see
difference between a java programmer and a "spring" programmer. One of the
things I like to do in interview is giving people a piece of code in a
language or at least using a library or framework they don't know and see how
they cope with the complexity of it. It can tell which is just learned to use
a tool and which know the basics and can adapt depending on the set of tools
available

~~~
contingencies
_I have struggled with complexity my entire career. One of our key approaches
for managing complexity is to 'walk away' and start fresh. Often new tools or
languages force us to start from scratch which means that developers end up
conflating the benefits of the tool with the benefits of the clean start. The
clean start is what is fundamental. The simplest way of controlling complexity
growth is to build a smaller system with fewer developers._ \- Terry Crowley

An informed perspective: [https://www.quora.com/Programming-is-all-about-
managing-comp...](https://www.quora.com/Programming-is-all-about-managing-
complexity-Do-you-agree-with-that-statement/answer/Keith-Bentley)

------
77pt77
> I really detest the use of the word "training" in relation to professional
> activities. Training is what you do to dogs. What you should be doing with
> people is educating them, not training them. There is a big, big difference

I feels this person's pain.

------
B1FF_PSUVM
> Java and Perl came along (and later, Python).

Perl 1987, Python 1991, Java 1995 (cf. Wikipedia "first appeared" info).

But yeah, the "coming along", i.e. gaining traction, may be said in that
order.

Minor nit, a very level-headed assessment.

------
jackconnor
It wasn't "Knowing Lisp" rather it was "not learning any other languages as
the industry changed", and he still got a developer job at Google. Why is this
here?

------
jng
All of it probably to be taken with a grain of salt.

~~~
alex_duf
any particular reason?

~~~
vidarh
See:
[https://news.ycombinator.com/item?id=16584028](https://news.ycombinator.com/item?id=16584028)

~~~
alex_duf
I'd like my career to be destroyed too please

------
otabdeveloper1
Lisp isn't any more powerful than Javascript. Sorry.

~~~
flavio81
>Lisp isn't any more powerful than Javascript. Sorry.

Would you please elaborate?

------
pvaldes
"Training is what you do to dogs. What you should be doing with people is
educating them, not training them. There is a big, big difference."

big truth...

------
YouAreGreat
Half-seriously—but could it actually be true? Because by using a high level
language most of the time, you will miss the practice it takes to
_effortlessly_ program manually what these languages automate.

Between "GC, full numeric tower, CLOS, incremental development" and especially
the ease of metaprogramming in Lisp, you may eventually lose the ability to
perform the very programming tasks you have automated away for yourself,
whenever you lose access to your own macros.

The true Curse of Lisp would be that Lispers are constantly de-skilling
themselves.

~~~
wglb
Having written a significant number of lines of assembler early in my career,
I am happy to delegate the task of register allocation (an NP-complete
problem) to a compiler. I don't miss that manual task, and don't think the
rest of my career suffers for that.

I also don't particularly miss worrying about malloc/free in my programs, nor
having to write multi-precision floating point arithmetic routines.

------
3chelon
Horses for courses, surely? I've never coded in Lisp except for one undergrad
assignment in the early 90s... but I know it's good for functional, heavily
recursive, algorithmic type problems.

But the world is far messier than that and if, like me, you come from a
systems or real-time programming background then Lisp basically did not exist
and you were using C-based languages (or even assembler) that were close to
the metal so you could code interrupt handlers, asynchronous I/O drivers and
the like. Obviously trying to tackle those kinds of problems from a Lisp-
centric viewpoint would seem slightly crazy, so why bother?

~~~
Jach
Sounds like you coded in Scheme, not Lisp.
([https://news.ycombinator.com/item?id=16584082](https://news.ycombinator.com/item?id=16584082))
Common Lisp was designed for the messy real world, it's a workhorse, even at
the cost of 'prettiness' that Scheme fans like to point out as a benefit for
Scheme. So it's been used (either directly or to output a lower level machine
code) for all sorts of real world things like OSes (see the Lisp Machines),
video games, CAD systems, Mars rovers (subject of this submission), etc...

From the most basic level of syntax, something like
[https://github.com/TeMPOraL/cl-
wiringpi2/blob/master/example...](https://github.com/TeMPOraL/cl-
wiringpi2/blob/master/examples/blink.lisp) doesn't seem that different to me
than the C equivalent I've written for embedded devices.

~~~
3chelon
Yeah, I remember very little about it except a _lot_ of parentheses.
Interesting to hear it is a lot more "real world" than I thought - seems my
understanding is flawed... but equally interesting that I was unaware of it,
having never once encountered it in my entire career.

~~~
kazinator
The average engineer has some dozen things they encountered in their career,
and everything else is something that they haven't encountered once.

Off the top of my head, I've never encountered such tools as: Visual Basic,
PowerShell, VHDL, and IBM 370 assembly language.

~~~
wglb
Ah, but think of what you are missing!

