Hacker News Reader

Comment by lisper | Hacker News Reader

One of the things that has made me old (52) and crotchety is that I learned Lisp very early in my career. That gave me the ability to see that 99% of "new" technologies were really just poor re-inventions of (parts of) Lisp. Even today, Common Lisp -- despite (or, as some would argue, because of) the fact that it hasn't been officially updated in decades is still not only a viable language but one of the best choices for many applications. But no one knows it because it's not the shiny new thing, and even young people still can't seem to get their heads around the fact that the parens are a feature, not a bug. And that makes me grumpy sometimes.

The good part was that I was able to build a very successful career while not having to suffer nearly as much pain as many of my contemporaries. The bad part is that now it's hard to find people to collaborate with. :-(

View on HN

Even today, Common Lisp is still one of the best choices for many applications.

Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things.

Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or Azure or Google Web Services language, it's not used for Linux Kernel, Windows, Oracle, *BSD, SQL databases, No-SQL databases, it's not used where Erlang is, it's not the research language Haskell is, it's not the fun esolang or the long-tail COBOL, it's not the new compiles-to-JavaScript, it's not the back of 3D games or VR engines, it's not behind Amazon's shop or used where Go is. It's not talked about in StackOverflow's most popular languages surveys, or most profitable languages for devs to learn, or most desired by employers. It's not an educational language like it once was.

Yet it's "one of the best choices".

I simply don't believe it. Any perceived advantages it has, in practise must be a wash.

Too much fun to program in. Lisp makes it remarkably easy to extend the language into just what you want it to be...which means that Lisp programmers tend to spend most of their time extending the language into just what they want it to be rather than solving the problem. (Indeed, this is often touted as one of the benefits of Lisp...once you have a suitably well-adapted DSL, the problem solution follows naturally.)

Meanwhile, the Java or Go programmer is thinking "this is boring and ugly. Let me finish this problem as quickly as I can so I can go home." So they finish the problem as quickly as they can, and then it's done, and it ships. And people have an incentive to use it rather than tinker with it because nobody really wants to peek under the hood, and the people who do peek under the hood tend to be really dedicated and care a lot about the problem domain because why else would you put up with the language?

This one I can believe.

Then why don't people build amazing and popular things with it?

The reason is because "best" can have more than one meaning. Languages are usually only "best" at one thing, not for all things. In the case of many languages that people consider to be "best", they've been optimised for the development process (making it nice to write code in) rather than speed (C) or security (Ada) or a specific niche (R) or maintainability (not sure) or customisability (LISP). They're designed to make writing code more straightforward. Languages that are optimised to be easy to code with are the languages that tend to bubble up to the top when it comes to popularity contests because the more people who can access the language the more popular it's going to be.

There is an argument that Ruby is mostly LISP, so it could be said that lots of people use it very happily everyday.

> There is an argument that Ruby is mostly LISP, so it could be said that lots of people use it very happily everyday.

How is that? I thought Lisp's "killer app" was its extremely powerful macroing system. Does Ruby have an equivalent?

It has class level declarations which do the same thing.

I would go with that, in the sense that "here's a box of parts" is the most customisable way to solve a problem - yet not the best way for most people.

Except, even people doing exploratory stuff apparently aren't using Common-LISP.

Let me point to Slava from RethinkDB, who wrote blogs about how amazing LISP is and then went to found a new-software startup written in C++. Peter Norvig, AI researcher, who moved from LISP to Python.

And even your mention of Ruby - "Common LISP is the best langauge", then why is Ruby even needed? Why aren't those people happily using Common LISP? Simply because it wasn't actually any better, and was in fact worse than Ruby in whatever metrics.

A few notes:

* Google actively develops one of the Lisp compilers. Google Flights powers Orbitz, Kayak, etc. That's Lisp.

* There are several Lisp compilers in active open source development.

* There's a graph database written in Lisp called AllegroCache. It's good enough to support a business (Franz) for more than a decade.

* Another company (LispWorks) also exists and has a large portfolio of clients.

* Lisp has been used to make entire operating systems. Ones of the past, and ones of now. (Of course, an OS needs a community. But where are real OS's with GUIs in other languages?)

* Lisp has been successfully used in my own career for embedded systems to control satellite acquisition systems to, most recently, quantum computing. (At real companies.)

Just because there's not this huge buzz around Lisp doesn't mean no one is using it.

I don't even code in Lisp, but I knew the Google Flights engine would come up, because it seems to be just about the only "serious" application ever written in Lisp. And it wasn't built by Google, but their acquisition ITA, which hails from Boston and MIT's Scheme reality distortion field. (And even MIT has stopped teaching SICP in Scheme...)

Emacs, ViaWeb, Macsyma, the DS1 Remote Agent, much of the autonomous navigation software for the Mars Rover before the Pathfinder mission... And I have built a number of small-scale web applications in Common Lisp. I'm running one of them in production right now.

And Yahoo! paid 49 million dollars of stock to throw the LISP in the trash and use something else instead.

It wasn't even worth them spending 1 million dollars - 2% of that price - on training people.

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=s...

Right. And that decision was surely one of the reasons Yahoo is the runaway success it is today.

Are AutoDesk still using it?

It might be that it really is a big secret, and people are quietly using it and gaining advantages from it.

If that were the case, I would still expect to see lots of gushing blogs of leaks from inside hush-hush companies and people desperate to learn LISP posting "how do I replace strings in files in Common LISP" on programming forums, and "I learned LISP and doubled my salary" on Twitter.

Yet what you really see is Steve Yegge and "my EMACS code at Amazon was replaced with Java years ago" and "Facebook working on a new JavaScript thing" and "Microsoft working on a new JavaScript thing" and "Apple working on Swift" and "Fog Creek compile VBScript to PHP" and "rPi comes with Mathematica and Python" and so on and so on.

I wasn't saying that no one is using it. I was saying "if it was the best - as claimed - then there would be a buzz around Common LISP, because huge numbers of people would be using it".

Your points about your career are pretty interesting.

Lisp is old and it's unlikely that you see hype anytime soon. But you can see that Lisp derived languages like Clojure can generate minor hypes. Other new languages may even contain substantial pieces of Lisp influence. Examples would be Julia or R.

Generally the industry has problems reusing old/existing technology. See for example the Javascript domain, where new frameworks for web development pop up every week and the lifespan of frameworks is measured in months.

Instead of using/enhancing existing tools, there is a constant pressure to develop new stuff. Or take Apple with Swift. Instead of using Scala, Standard ML, OCAML, F# or Haskell, they developed a new statically-typed functional language.

It's the NIH syndrome at work. Everywhere. But it's also that tools are complex to learn, so people start new with simpler tools, they grow over time and after some time they are replaced with other stuff. If something gets updated in some incompatible ways, it already causes problems: some users are lost, some users will only use the old stuff, some only the latest stuff and some will try to use multiple versions. See Python.

Full Common Lisp is just too complex for most developers, but it has a life in many specialised and niche applications: CAD, some AI tools, music, robots (like the Roomba), planning/scheduling (crews, telescopes, ...), Expert Systems, verification of software and hardware, some maths stuff, ...

Since Lisp is only left being taught at a few universities, there are not many people able to develop with it. Even when it was taught, it was often only used to teach concepts like recursion and not programming. The younger Lisp programmers found it by themselves.

'Industry' sometimes often has no interest to diversify their programming tools. Many enterprise software shops currently (still) use Java: standardised, broad industry support, ... You won't successfully propose to them to use Lisp, even if the application would be better in some way. For example if the project fails, it certainly wasn't Java fault, because all the others are using it too. If you would use Lisp and the project would fail, it would be Lisp's problem: not enough people, little architecture experience, tools not broad enough, integration story too weak etc... Even it would be successful and in production, there would be a lot of pressure to rewrite it in some industry standard in the next product iteration.

> "if it was the best - as claimed - then there would be a buzz around Common LISP, because huge numbers of people would be using it"

There is no general 'best'. It's all relative to a domain, community, demands, legacy, fashion/hype, ...

Lisp is not more dead than usual. Yesterday there was a donation effort started for the Quicklisp library manager and it's now at $16606.37 .

Very good list of some issues that lead to "the new hotness" all the time. I had not thought of some of these; it's not totally brain-dead fanboyism.

One issue that (good) bosses have is that they cannot allow their business to be held hostage by one person. If that person quits (or dies), they have to be able to replace them. Esolangs are a hard sell on that basis alone, no matter how fit for use they may be.

I'd forgotten Clojure (and others!) - yes, Lisp is more popular than "things named Lisp". And, arguably, Clojure is popular enough these days that the argument in the previous paragraph doesn't really apply to it any longer. (Whether bosses know that is a separate issue.)

Then there's the claim by Guy Steele that, in creating Java, he dragged a bunch of C++ programmers "halfway to Common Lisp". (Lisp purists might concede some fraction considerably less than half...) Paul Graham says that the Lisp feature set is slowly taking over programming languages. Lisp may die but still conquer, or mostly conquer.

What Java mostly got from Lisp was parts of memory model and the managed memory, not so much on the language side. Smalltalk got that from Lisp too. Ruby also (the Ruby developer studied the Emacs Lisp implementation). Microsoft's CLR also. Actually parts of the early Microsoft .net CLR GC were written in Lisp and automatically translated to C.

But Java could not do a lot of things a typical Lisp implementation can do, sometimes with a good reason for that.

  * runtime compilation
  * loading of code (-> custom class loader)
  * garbage collection of code is sometimes difficult
  * saving/starting of memory dumps
  * fast startup times
  * tail call optimization
  * updating changed objects
  * calling error system -> Java has a terminating error system

For most of these problems some 'solutions' have been developed. On the language level the Java community experimented with some original Lisp stuff, too. But not much was added to the language, but at least they got lambda expressions (1958 in Lisp) and a first kind of multiple inheritance of code (around 1980 in Lisp via Flavors). Java soon will have a standard shell for incremental use ( https://blogs.oracle.com/java/jshell-and-repl-in-java-9 ) - that was around 1960 in Lisp. Now imagine when Macros will be added...

But generally knowing Lisp does not help you much with Java, since the language's OOP model is very different from the typical OOP in Lisp (see CLOS+MOP).

> But where are real OS's with GUIs in other languages?

There's this thing called Windows you may have heard of...

And, out of curiosity, what OS are you referring to?

> Just because there's not this huge buzz around Lisp doesn't mean no one is using it.

jodrellblank's claim was not that absolutely nobody is using it. The claim was, compared to how wonderful Lisp advocates claim the language is, relatively nobody is using it. If you compare the amount of software written in Lisp to the total amount of software written, and compare that to how wonderful Lisp is claimed to be, jodrellblank has a real point. And citing a handful (or several handfuls) of counter-examples does not refute the point at all.

Sure, in practice people's beliefs about languages can become self-fulfilling prophecies. And the thing about self-fulfilling prophecies is that they are actually true. For example, Javascript is tremendously useful even thought it is a horrible language from a technical point of view, it's just that the sheer weight of people using it because everyone else is using it results in enough infrastructure that you can get useful things done in in Javascript despite its (lack of) technical merits, not because of them.

And when JavaScript was becoming a thing, where was the better alternative written in LISP and the community of people who like better software supporting it?

Nowhere, that's where. Like in approximately all problem domains, whatever perceived benefits LISP has, doesn't seem to make it all that desirable.

You are writing this comment in the lisp-based software. Yeah, I know, Hacker news is a simple software and could have been written in anything else, but, somehow, the author, who I've heard is very smart, thought that Lisp is the best pick.

And his secret to winning big was "write lisp software, have it bought out by another company who will rewrite it in a different language to make it popular and useful".

Really, if PG's "LISP, how to win big" was as compelling and important as he tried to state in that essay, every ycombinator company would be using LISP for their secret advantage over other companies.

Applicants would choose LISP because it's "better", LISP-based applications would be preferred because the applicants have an advantage, existing companies would be encouraged to LISP because it would help them do more for less employee numbers and YC would become a LISPy community of alumni.

I have no proof that this is not happening right now, but would you bet on it happening right now in secret?

Your logic assumes that young founders/developers are very proficient in many languages (including lisp) and they have perfect information for choosing. In reality, they use whatever crap they picked up hacking in high school. On top of that, the tools are only a part of the ingredients. However bad your platform is, at least it works, while most of the screw-up is hidden in business decisions - that's why every startup incubator's job is to help the youngsters not screw up business-wise. Tech is normally something up to the founders, most of whom have never heard of lisp.

>Nobody uses it, but it's the best choice, both can't be true

Sure it can. It is possible for both to be true, as long as developers don't pick languages rationally, which they probably don't.

There are a few biases at play. One is that people are only exposed to a subset of the languages that exist, which are those that are either used in industry, or are making the rounds in news. Another bias is that we like to pick languages based on familiarity. For example most of my college courses used imperative languages: Python, C++, and Java. From that experience I am quicker at thinking in terms of for loops than folds and maps. So when I try a language like Haskell or LISPs I think "That's neat!" but when faced with a deadline I switch back to something closer to my first languages.

It could be that I am the only one that thinks like this, and everyone else sits down and spends equal time on every language in existence, but I doubt it.

In any case at one point LISPs were popular, so why did they lose all of their momentum?

I also doubt it. But LISP dates back to 1958.

JavaScript is from 1995.

"I chose the language which exists" doesn't apply to the people in 1994 who could have had /thirty-five years/ of LISP experience (potentially) and yet still chose to write another language, in another language. And when Brendan Eich was in college around 1981, the tutors there could have had /twenty years/ of LISP experience, but weren't there to convince him that it was amazing.

Same with literally any language dating post-LISP, and I note that that covers most languages which are popular today.

"Programmers don't pick rationally" is fine on the small scale, but accross the entire industry, even among people who do love exploring programming languages, even among young entrepreneurial risk takers, even among companies in tough markets angling for any and every edge they can get over their competitors, in decade after decade, over problem domain after problem domain after problem domain, there is this empty howling wasteland of happy and productive people using not-LISP, writing world-conquering systems that do just-fine-thanks and the claimed benefits of LISP just don't seem to be making any noticable dent in anything.

Therefore, they are over-hyped.

You are overlooking a crucial fact: very often people who want to use Lisp are not allowed to by their management precisely because "no one uses it" and so the experiment never gets done.

I was the lead engineer on the first release of AdWords. I wanted to write it in Lisp, but I was not allowed to, being forced against my strenuous objections to to it in Java. So now AdWords is a Java success story rather than the Lisp success story it might have been not because Java is better (it certainly wasn't -- it was a disaster) but because my boss issued an edict.

This has happened to me many times in my career. The one time I was actually allowed to use Lisp in a project that I did not have direct control over (the DS1 remote agent) it was an overwhelming technical success. In fact, management tried and failed to get the software rewritten in C++, so this was actually a controlled experiment.

If that were the (only) issue, we ought to see Lisp used more in startups than in established businesses, because in startups, you don't have some manager who doesn't know Lisp and is managing to minimize is perceived (not necessarily actual) technical risk.

But in fact I'm not sure that we see more Lisp use in startups, either. That could be because they aren't taught it in school. (Many startup founders haven't had the chance to pick it up on the job. For that matter, many programmers haven't had the chance to pick it up on the job.)

On the controlled experiment: Why was that? I mean, it has to be possible to rewrite anything in C++ (Turing complete, and all that - but possibly at the price of Greenspun's Tenth Law). Was it because the people who tried didn't know anything about Lisp? (Were they working from the source, or from the spec, or from the program documentation?) Were they just not as good programmers as the Lisp programmers (and don't say "if they were as good, they would have been using Lisp" - that wasn't their assignment). Did they have less time, less resources? Why didn't/couldn't they do it?

It's all a viscous cycle going back to AI winter in the late 80's: DARPA stopped funding AI work, which meant that funding for Lisp work dried up, which meant that fewer people used it, which meant that fewer people learned it. Now, 30 years later, hardly anyone uses it, at least not directly. But it keeps getting re-invented again and again. You can't avoid re-inventing Lisp because it's part of the fundamental physics of computing. That is my frustration. People say that Lisp sucks, and then they proceed to re-invent it badly not even being aware that that is what they are doing.

As to why the re-implementation of the Remote Agent (it wasn't the whole thing BTW, just the planner) in C++ failed, it was a combination of factors. This was twenty years ago (holy cow!) and C++ compilers were nowhere near as mature then as they are now. There was only one compiler available for the flight hardware, and it was pretty unstable. But mainly it was Greenspun's tenth: the application did a lot of dynamic allocation (it was an AI search algorithms) which is something C++ is particularly not well suited for. They essentially had to re-implement Lisp in C++, and that was hard. Of course it would have been possible given more time, but we didn't have more time. The Lisp code was working, so that's what we flew.

Supposing the AI winter never happened, what is your perception of where Lisp would be now? Dominant? Large niche? Small niche, but larger than present?

I have no idea, and it doesn't really matter because we can't go back. I really don't want to dwell on the past, except insofar as we can learn lessons that inform the future. The point I really want to make is that Lisp is still a viable option today (Common Lisp and Clojure in particular) and I would like to see people give it a fair shake going forward.

I agree that claims for Blub (for any value of "Blub") are too often over-hyped. But don't make stuff up in the course of justifying your reasonable point against hype.

I met John McCarthy in 1977. In college, a professor (Ruth Davis, I think; SCU EECS department) brought in someone who taught Friedman's "The Little LISPer". By the time I got to Netscape, I had read SICP. I knew enough about LISP to be dangerous.

But as I've said many times, and Netscape principals have confirmed, the reason JS isn't Scheme is because Netscape did the Java deal with Sun by the time I hired on (after I was recruited with "come and do Scheme in the browser"), and that meant the "sidekick language" had to "look like Java".

There was no "chose to write". Netscape management gave the MILLJ order; Netscape source was C (mostly), JS ("Mocha") was supposed to go server-side via "LiveWire" as well as embed in Navigator, and I was a C hacker. These are the reasons for the new language and its first implementation language.

But don't make stuff up in the course of justifying your reasonable point against hype

Where's the fun in that? ;) No, but really - I apologize for claiming there wasn't enough general LISP enthusiasm around when you were at college to affect you, and for not actually looking into the history of JS before making statements about how/why it happened.

JS design being partly a pre-made business decision - that's something I really should have known by now.

Please. You pick a lowest-common-denominator language like Java or Golang so that you have a large pool of cheap, semi-sentient code monkeys to hire from.

If you choose LISP, you're actually going to have to expend a little bit of effort on identifying, recruiting, and retaining actually competent people. That's a problem when you're looking to put butts-in-seats (as is the case in my industry: defense).

That just pushes the problem back a couple of decades. Common-LISP is from 1984, GoLang is from 2007.

In twenty years, Common-LISP with all the advantage it supposedly has couldn't make anything that a 'code monkey' could use? Why not? Is it awful at writing tools?

Or is it that the alledged advantages of Common-LISP don't really make any difference in reality because they are over-hyped or even non-existent?

Note that I'm not saying "why did they pick one language over another", I'm saying "Common LISP can be the best tool for the job - yet they waited twenty years to use a 'worse' tool to implement a 'worse' tool". That doesn't make sense.

> Nobody uses it

This application is written in 7+ million lines of Common Lisp

https://www.ptc.com/cad/elements-direct/modeling

https://www.youtube.com/watch?v=mJGytRaNvec

The video shows how Eterna uses 'PTC Creo Elements/Direct' to develop their watches. There are many other clients of that in various domains.

Also:

https://www.youtube.com/watch?v=4rD0zmA-Trc

Good cite.

(Although the fact that some people can make successful Common LISP software could just be that those people are exceptional enough to make successful software in any language, it doesn't bolster the claim that 'Common LISP is one of the best choices for many applications' very strongly).

Inmarsat uses a Lisp application (G2) to monitor their satellites and to provide a high level overview of the status of all Inmarsat services in real-time.

http://www.inmarsat.com

If you would run a Cement plant, an oil pipeline or a coal terminal in South Africa, then you might also be using G2 to control and diagnose technical processes in real-time.

The product used, written in Lisp:

http://www.gensym.com/wp-content/uploads/Gensym-l-G2.pdf

> And that makes me grumpy sometimes.

If you will excuse a moment of cheekiness...

Could be that you have cause and effect backwards here: because you are grumpy you are dismissing 99% of other language developers' work as rubbish. Could be that it's less than 99% and you are overlooking some great ideas.

That's not cheeky, it's a perfectly fair question. Yes, that is certainly possible. And there have been a few cool new ideas that have come along that are not easily subsumed by CL, like Haskell's type system. It's easy to implement Hindley-Milner, but actually using that information to inform the compiler, plus adding laziness as a core language feature, is much harder. But I think the jury is still very much out on whether or not Haskell is really a net win.

But the most popular language on github at the moment is Javascript, and there is no question that it is simply a very badly designed Lisp with C syntax. This is not intended to disparage Brendan Eich. He had a week to design and implement something, and under those constraints he did a pretty amazing job. But I can't help but imagine how different the world would be if he had used Scheme as a starting point.

Was there something in particular that you had in mind that you think I may have missed?

But I can't help but imagine how different the world would be if he had used Scheme as a starting point.

I've heard that he did in fact use Scheme, but the suits insisted on the whole curly-brackets-and-semicolons thing so they could call it Javascript and piggyback on Sun's marketing efforts.

To be fair, he only took some of the semi-colons.

He took an option on the semi-colons.

My take is that Language X usually has major deficiencies compared with Language Y for domain Z, for many values of X or Y: Lisp, Scheme, Smalltalk, Forth, Erlang, Haskell, assembler, C, etc.

Confirmation bias makes it easy to bind those variables to values that make one's own favorite language obviously the best and everybody else's infuriatingly, irrationally terrible. If unchecked then this leads to wildly false conclusions, such as that languages fit into a hierarchy of powerfulness ("Blub Paradox.")

Tangentially: I am working with LuaJIT these days and this feels really exciting to me. The compiler is a new kind of beast and possibly the beginning of a large Lisp-like family tree. Feels very "MACLISP" to me - exciting!

What do you see as Common Lisp's "major deficiencies"? (Pick your favorite value for Z.)

This isn't a challenge, I'm genuinely interested in your answer.

that should be pretty obvious: lack of library support.

there is the famous example of the reddit founders, who believed pg's lisp story, and built the first version of their site with it. it went so badly for them that they had to start over again in python.

... but i bet you are going to have a very plausible-sounding reason why it didn't work for them.

I have no idea why Lisp didn't work for Reddit. But Common Lisp has exceptionally good library coverage today, and with Quicklisp, getting access to it is virtually seamless.

okay, maybe i betrayed my biases there too much, but, i agree with everybody else: if lisp was such a great secret weapon, there would be a hell of a lot more visible success stories by now, other than just pg's original viaweb implementation, and some flight routing software.

plenty of other tech has come from up nothing in the last few decades, to wide adoption, and big successes. the fact that lisp hasn't is, in my mind, prima facie evidence that it is not nearly as great as its proponents claim.

> there would be a hell of a lot more visible success stories by now, other than just pg's original viaweb implementation, and some flight routing software.

There are, but you are ignoring them, you simply did not do any research or it is simply hidden.

The success of Common Lisp today is relatively small, but a careful reader could find a few interesting applications of it like the scheduling system for the Hubble Space Telescope, the design software for the Boeing 747 (and other aircrafts), the software for the Roomba, the software for DWAVE's quantum computer, the crew scheduling software for the London subway, chip design verification software at Intel (and other chip companies), ...

There are some old application platforms which survived. For example Cyc, an attempt to provide common sense AI to computers, is under continuous development since the mid 80s. The company Cycorp has 50+ employees, is very secretive and you need to guess who pays for it. Customers are among others the United States Department of Defense, DARPA, NSA, and CIA. They are using it for various applications.

Note also that prototyping software was for a long time an application area for Lisp. Have relatively small teams develop a prototype and make it a product once the idea is validated. Example: Patrick Dussud wrote the core of the first Microsoft CLR (.Net Common Language Runtime) garbage collector in Lisp. The code was then automatically translated to C (IIRC) and enhanced from there after some time. Lisp now is no longer used and the GC has a lot of new features, but the first working versions came from that Lisp code.

> if lisp was such a great secret weapon, there would be a hell of a lot more visible success stories by now

Not necessarily. There are other possible explanations of Lisp's relative lack of commercial success, not least of which is the fact that a widespread belief that "there must be something wrong with it because no one uses it" can become (and I think has become) a self-fulfilling prophecy.

But another important factor is that the Lisp community seems to attract people who are really good at tech but really bad at business. I think if someone (or, more likely, some pair of co-founders) could bridge that gap they could still kick some serious ass.

Just a data point: I founded a Lisp startup together with a bunch of experienced Lisp hacker buddies from the SBCL community. Sadly and reluctantly, we found Lisp awkward and ended up rewriting everything in C, and then never looked back.

These days I am developing such software with LuaJIT and that is working much better for me than either C or Lisp.

One thing I learned along the way is that many tales of Lisp heroism are actually anti-paradigms. Once upon a time when I read about ITA Software rewriting CONS to better suit their application I thought it was impressive; now I see it as a farcical workaround for having chosen an ill-suited runtime system and sticking with it (and generally an indictment of Lisp not providing a practical performance model for the heap.)

Lispers are too expert at spinning bugs as features. "It's insanely complex, every line could be an interaction with undefined behavior or a race condition or an unexpected heap allocation" becomes "suitable only in the hands of trained specialists, like a chef's knife or a surgeon's scalpel or a Jedi's light saber."

I feel like we need to have a shared "our emperor didn't have any clothes" moment with regards to Paul Graham's essays.

(I say this as somebody who does love Lisp and will probably do a lot more Lisp work in the future but only on a project that is a peculiarly good fit.)

(Funny feeling of being a Lisp hacker searching for catharsis in the Hacker News comments section... :-))

Don't search, go do something cool,what all people will talk about!

I prefer not to. I think it would be more productive as a private thought experiment: what would you expect a Smalltalk hacker curse about if you forced them to use Common Lisp? a Haskell hacker? a Rust hacker? I think they would miss some really valuable things, and that you could easily miss the value of those things if you took them out of their original context (e.g. considering only whether Lisp would be improved by adopting those specific features.)

Some functional languages make certain behaviors implicit, such as partial evaluation and laziness. However, these work better if they are explicit. They work better because one of the two is severely confusing when implicit and the other potentially performs badly.

  C:\Users\kaz>txr
  This is the TXR Lisp interactive listener of TXR 162.
  Use the :quit command or type Ctrl-D on empty line to exit.
  1> (defstruct integers ()
       val next
       (:postinit (me)
         (set me.next (lnew integers val (succ me.val))))
       (:method print (me stream pretty-p)
         (format stream "#<integers ~a ...>" me.val)))
  #<struct-type integers>
  2> (lnew integers val 0)
  #<integers 0 ...>
  3> *2.next
  #<integers 1 ...>
  4> *2.next.next
  #<integers 2 ...>
  5> *2.next.next.next
  #<integers 3 ...>

Why would I want implicit laziness everywhere? The best of all worlds is to have expressions reduced to their values eagerly before a function call takes place.

When I don't want an expression evaluated in (what looks like) a function call, I can, firstly, make that a macro.

If I really want lazy semantics, I can have a decent vocabulary of lazy constructs that fit into the eager language. For instance for making objects lazily I have lnew, distinct from new.

Implicit laziness everywhere is academically stupid. You're drowning the execution of the code in an ocean of thunks and closures.

The pragmatic approach is best of making a compromise between making everything explicit and visible, yet keeping it syntactically tidy and convenient.

> Why would I want implicit laziness everywhere?

For the same reason you want automatic memory management: so you can fob off the job of figuring out where the thunks should go onto the compiler, just as you fob off the job of figuring out where the calls to malloc and free should go. At least that's the theory. It seems plausible to me. I think it's an open question whether my failure to grok Haskell is due to a problem with Haskell or the ossification of my brain.

Not trying to troll you here...

To what degree do you use Lisp as an FP language? As a pure FP language? The forced purity may make Haskell a very different language.

And, to return to your original complaint: If you dislike new languages, I bet XML drives you straight up the wall...

> To what degree do you use Lisp as an FP language? As a pure FP language?

It depends on what I'm doing, but I generally write in an OO style more than a functional style. Real problems have state.

> If you dislike new languages

I want to be clear that this is just a general observation. I don't dislike new things because they are new, I tend to dislike them because they are generally bad. But they are not all bad. Clojure is cool. WebASM is very cool. The work that has been done on Javascript compilers is nothing short of miraculous (even though the language itself still sucks).

> I bet XML drives you straight up the wall

Kind of, but not really. Yes, I dislike XML because it is nothing but S-expressions with a more complicated syntax. But it doesn't drive me up a wall because when I need to deal with XML I just parse it into S-exprs, do what I need to do, and render the results back into XML.

Pure FP deals with state!

State is something that is best just embraced rather than "dealt with".

An analogy to that is that OO doesn't embrace IO. Yet weirdly enough that makes OO-IO better than older languages that have built in commands to write to disk.

Haskell doesn't have state but you have multiple models to choose from, from simple folds to STM or State or Reader or Writer Monads all of which serve different purposes and do different jobs well.

OOP absolutely embraces I/O. I/O begs to be OOP and makes, hands down, the best use case for illustrating OOP.

What I am getting at is that OOP languages like C++ have no IO commands built in it is all delegated to libraries.

Haskell has no state support built in, it is all delegated to libraries.

So:

C++ has excellent IO support, but the language doesn't embrace IO at all.

Haskell has excellent State support, but the language doesn't embrace State at all.

C++ I/O libraries in fact depend on the sequencing semantics built into the language. If we make two calls to the library, they happen in that order; consequently, the I/O happens in that order. We can do wrong things like:

    f(cout << x, cout << y)

where we don't know whether x is sent to cout first or y.

C++ statements could be added to C++ (e.g. as a compiler extension). They would be straightforward to use; C++ doesn't inherently reject that the way Haskell and its ilk reject sequencing and state.

Haskell doesn't reject sequencing. f = g . h will require h is evaluated first.

h might not be evaluated at all! Consider

    h x = factorial x
    g x = 0

(but I agree that Haskell doesn't reject sequencing).

Yeah the IO monad will, but it isn't generally true of monads. Infant the maybe monad Will cease early on Nothing by design. So it is a brain shift.

> Haskell has excellent State support

Someone who understands where that support is and how to use it should rewrite atrocities like:

https://rosettacode.org/wiki/Assigning_Values_to_an_Array#Ha...

I don't think that's so bad, it's just you are using a function instead of the usual built in indexing operator [0]. Here's something a bit more convenient using Data.Array.Lens[1].

    arr ^. ix 2

vs the original:

    readArray arr 2

Sure, everything non-trivial is Turing-complete. But FP begins as a stateless paradigm and then tacks on state as a sort of a kludge while all the while seeming to be a little embarrassed about it, while OO embraces state from the beginning as part and parcel of the mental model that it endorses. I find the OO model has a better impedance match to my brain and the real world. Reasonable people can (and do!) disagree.

I dislike XML because it's a nested tree of internal nodes and typeless character string leaves.

In XML I have no way to place "255" and "FF" in such a way that XML understands them to be the same object, of integer type.

Sure you do. <base10>255</base10> <base16>FF</base16>

It's not the same. Here is why: the program correctness doesn't depend on when (or even whether!) that automatic memory management happens. Lisp systems have been bootstrapped without having a working garbage collector upfront. Short-lived Lisp images run as processes in a conventional OS might never have a chance to collect garbage.

Laziness has precise semantics which has to unfold properly, or else things don't work.

Delaying evaluation is not the same thing as delaying reclamation. They are opposite in a sense, because we only allow something to be reclaimed when it is "of no value".

Failure to grok Haskell is probably due to the lack of easy accessible literature on it. Plus with so few other people groking it there isn't as much osmosis available.

> Why would I want implicit laziness everywhere?

Modularity; see the stone age paper discussed yesterday: https://news.ycombinator.com/item?id=13129540

> Functional programming languages provide two new kinds of glue - higher-order functions and lazy evaluation. Using these glues one can modularise programs in new and exciting ways, and we’ve shown many examples of this.

> This paper provides further evidence that lazy evaluation is too important to be relegated to second-class citizenship. It is perhaps the most powerful glue functional programmers possess.

The paper claims in its conclusion that it has provided evidence (what is more, "further evidence") yet I can't find any in there.

It argues that you can achieve a certain useful separation between programs together when one produces data for the other.

This can be achieved in a very satisfactory way with explicit streams (i.e. lazy lists). It can be satisfied with delimited closures, coroutines, threads and often with lexical closures. Not to mention Icon-style generators.

Lazy lists can be incorporated into the language so that their cell are first-class objects and substitute for regular eager cells smoothly. (Thank you, OOP).

The paper is actually wrong there, because laziness alone will not provide the kind of separation that g can begin executing, such that f then only executes when an item is required. Not for an arbitrary f! Suppose f traverses a graph structure recursively and yields some interesting items. Lazy eval alone isn't going to allow the f traversal to behave as a coroutine controlled by g, proceeding only as far as g continues to be interested in further items. The author is attributing to lazy evaluation magical powers that it doesn't have.

I'm certain lisper [parent] knows these, indeed may well have worked with PG in the past, but for those who don't, here's some useful linky: http://www.paulgraham.com/lisp.html

Isn't there a good big comnunity in Clojure now?

Depends on what you count as "big". If you look at languages used on github, for example:

http://githut.info

Clojure is doing OK (better than Common Lisp), but not great (worse than Haskell and Emacs lisp).

Not quite as much activity as Scala either. I think the good thing is that functional languages as a whole aren't going anywhere, it's just that the jobs for them are spread very thin over several languages.

Maybe because in Clojure you achieve more with less effort :)

I bet more people are getting paid to do Clojure work on production systems than Haskell or Emacs lisp.

That's a really nice web site. It took me a moment to realize it's showing quarterly data (sadly last updated in 2014), and that the ranking is based on the first metric ("number of active repositories").

Out of curiosity what flavor/dialect of LISP do you recommend? Common or something else?

I like Common Lisp, and Clozure CL in particular, but it doesn't really matter all that much. The cool kids seem to be using Clojure (with a J, not a Z) nowadays. Pick whatever works for you.

"That gave me the ability to see that 99% of "new" technologies were really just poor re-inventions of (parts of) Lisp"

"But no one knows it..."

It'll be really hard to work with a 23 year old with that attitude too.

Reply on news.ycombinator.com