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.<p>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 :-)<p>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).
<i>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.</i><p>Lisp can't help you if you're too smug for your own good.<p>Disclaimer: I'm a Lisper.
The problem wasn't lisp... The problem was he didn't want to leave his comfort zone.<p>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.<p>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?<p>Everyone can learn to use some tool, but experience using others may help you to discover better ways to use new tools.
Worked at Google Pre IPO, worked at the Jet Propulsion Lab, became an Angel Investor, acquired Startups, founder and CEO of Spark Innovation Labs....<p>....I hope to one day have my career destroyed as badly as this.
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).
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.<p>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.<p>Of course, as every programmer, I live in constant fear that I am part of the plumbing crowd waiting to be exposed.
I came to Lisp (Scheme/Racket) from that another side (C++, Java, Perl) and it was an enlightening experience.<p>Now I use Lisp nearly everywhere in a form of a small .NET runtime module.<p>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.<p>Isn't Lisp beautiful?<p>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:<p><pre><code> "Hello %name%. It is time to do some math. Assume A + B = %(+ a b)%. What is the value of A when B is %b% ?"
</code></pre>
You then fill Lisp environment with desirable values:<p><pre><code> env["name"] = "David";
env["a"] = 15;
env["b"] = 85;
</code></pre>
Evaluating aforementioned template will produce the following result:<p><pre><code> "Hello David. It is time to do some math. Assume A + B = 100. What is the value of A when B is 85 ?"
</code></pre>
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.<p>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.
> 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.<p>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.<p>It is something to be aware of and avoided.
This is from 2006 though.<p>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...
The point of this article can be compared to JavaScript devs fatigue story:<p>1. Many JavaScript devs were focused on 'getting job done' in their current workplaces, where they were using jQuery-related stuff mostly.<p>2. After some time they want to change job.<p>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).<p>4. They try to keep up and learn tons of stuff to be employable as js/front-end devs (npm/webpack/js frameworks).<p>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)
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?
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.
derkeiler.com gets blocked by uMatrix: the domain appears in Dan Pollocks hosts-file <a href="http://someonewhocares.org/hosts/" rel="nofollow">http://someonewhocares.org/hosts/</a> in the 'ads' section.
It reads like a tortoise and the hare story.<p>I have only minimal exposure to Lisp, Prolog, and ML in a programming languages concepts class in the mid 90s.<p>I really enjoyed using Prolog in the class and had an opportunity to use it professionally twice.
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.
> Lisp's power had made me complacent, and the world had passed me by.<p>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.<p>[caveats]<p>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.
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.<p>No matter how powerful the technique , it's way too low level for the modern world.
Oh wow, I was first introduced to Java in my undergrad and somehow I had some serious issues with the whole OOP stuff.<p>Thankfully, I took some AI courses, which came with LISP and I was so excited to use it everywhere.<p>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).<p>I would love to go back again and give it a shot - any pointers on the best way to learn/start?
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.<p>Even today, I feel like a lot of people could learn a lot from LISP and S-Expressions, both of which are powerful constructs.<p>(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)
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.<p>Disclaimer: Not a Lisper
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
> 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<p>I feels this person's pain.
> Java and Perl came along (and later, Python).<p>Perl 1987, Python 1991, Java 1995 (cf. Wikipedia "first appeared" info).<p>But yeah, the "coming along", i.e. gaining traction, may be said in that order.<p>Minor nit, a very level-headed assessment.
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?
"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."<p>big truth...
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 <i>effortlessly</i> program manually what these languages automate.<p>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.<p>The true Curse of Lisp would be that Lispers are constantly de-skilling themselves.
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.<p>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?