Great examples. Another question that leads to frustration is "can I use my existing code editor for this"? People are turned off when the answer is "no"

What examples force not using an editor? Many have a "natives use this" choice, but few lock you to it.

Some parentheses languages are much easier to use if you're familiar with a structural editor, for example.

All languages are easier that way, though? My kids learning python are best with a ton of hand holding. Affordances that show the structure are huge.

Agreed that seeing structure is important. I mean operating on it at a higher level like https://calva.io/paredit/

This makes sense, but I don't think that is at all required for working in lisp and friends. Just as many refactoring tools are not required to get started. Certainly useful if you get running with them.

So what advantages to comprehension or usability would you like to offer over Elixir? (as it doesn't really focus on type/category theory like most other FP languages)

I'm not an Elixir expert at all, but one important feature I believe is missing: explicit returns.

um, what?

Pretty common in FP languages to have implicit returns. A function HAS to return something. Ideally, a function is just a mapping between one value and another value. Wouldn't make much sense to have explicit returns.

For everything else there are guards, or just a simple if/else block. If everything is an expression (And if you are making an FP lang, almost everything should be.), the last expression will always be returned.

> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages.

What are those reasons, in your view?

It's an unpaid personal open source project.

Thanks! Right now the language's codebase is about 50KLOC. There's an interpreter for fast iteration and a compiler built on LLVM for producing native binaries. I'd like to make more progress on the parallel computing functionality before sharing it more widely.

Thank you! Imagine everything we like about Python, remove some warts, make it functional. It should feel familiar and appealing to a Python programmer.

Based on above it seems you want to test the hypothesis that 'there is a python-like functional language in the space of FP'.

Is there anything ~technical you can share beyond desires and disappointments that leads you to believe this is a reasonable hypothesis?

I've got a working interpreter and compiler for the initial language. I've had a few people take it for a spin and they were able to rapidly learn it and start contributing, despite having expressed frustration in trying FP languages in the past. All anecdotes for now!

Ah, you already have it. Now we're all intrigued! Looking forward to the public release.

I'm pretty deep in on Elixir, but I'd be quite interested to take a look.

Thanks for reporting that — I have no idea how that could be happening. Site is hosted on Blogger so it's a pretty vanilla setup.

Why do you think so many Lisp fans (e.g., Norvig) went on to use Python instead of those ML alternatives?

Norvig is a teacher and author who wants to reach the widest audience possible. So in his case, it was either Java or Python.

Norvig wrote an article or post where he deemed Python to be “an acceptable lisp” (or something like that, I may not have it exactly right).

Hardly a ringing endorsement! Python is certainly succinct and expressive like Lisp (when his alternative is Java). ML was designed to be a better Lisp.

ML wasn't designed as a better Lisp. It was designed as a 'better' (and statically typed) functional programming language for writing proofs in a theorem prover. The theorem prover and then also the first ML version was written in Lisp. That was the motivation for the first version of ML.

I did not mean to imply it was a Lisp. It was designed to solve the same problems as lisp, i.e. symbolic manipulation; and was used to rewrite code originally written in Lisp.

ML was at first a domain specific language for writing/assisting proofs: a) maths-like notation, b) functional, c) statically typed, ...

Lisp did only do b) to some extent. It was and still is common to develop languages as internal or external domain specific languages on top of Lisp. ML was such an example. Often these languages then are/were ported away from Lisp to a specialized (and possibly smaller/more efficient) implementation. Thus Lisp served as a prototyping environment.

I've had a similar experience in a large Python codebase!

100% agree with both of these comments. I'd love to see a resurgence of interest in this area.

What we need are examples of Lisp-style languages leading to big wins. Clojure did that to some extent, but unfortunately in the Common Lisp world successful commercial or technical projects are few and far between.

Our best bet is probably making interesting advances in the open source field, until something takes off, which is largely a factor of luck.

My biggest critique of the Lisp crowd. I mean, look at what gets made in Go, Go is barely 10 years old. Go is a worse Java, not as egregious an example of "worse is better" as Javascript, but still... a backwards step outside of its threading model.

For a language with such raw purported power, it is lacking in databases, operating systems, management software, games, etc. AI used to be it's killer app, but it seems the latest AI revolution isn't functional programming based.

One of the issues is that Lisp makes an individual programmer very powerful. The Paul Graham Lisp essay that gets brought up CONSTANTLY is an example of that. He built an entire ecommerce site by himself, but it was incomprehensible to the people that bought it from him and they rewrote it in some more pedestrian language.

Lisp lends itself to ivory tower constructions of abstractions that are ridiculously powerful to the one person that wrote them: the programmer, but the rest of the world will just end up reinventing their own wheels.

It takes a higher IQ that the person that wrote code to understand it about as well as the original author. But if LISP people are all high IQ, then the people capable of reading other Lisp code is of such high IQ that it falls apart.

I look at people like the Jepsen guy who uses clojure to test about the most difficult thing to test in the world: concurrent distributed systems, and other ultrasmart people and understand that FP is powerful. It also has advantages in true heavy concurrent programming, although FP seems to be squandering this.

I think it goes back to the operating environment. If Lisp machines were the killer apps they seemed, the lisp people need a novel OS + GUI + IDE + REPL computing environment to visually sell themselves, kind of like what smalltalk did back in the day.

I can't express how much I agree with everything you say.

Often, I've wondered if Lisp attracts, due to it power and flexibility, a certain type of "lone hacker" who builds amazing but unscalable ivory towers of abstractions.

One example of this, often mentioned as a success, but which I consider a failure if you take the longer view, is Naughty Dog using Lisp to develop their game engine compiler and such. This was so specialized that their new owner Sony balked and made them use standard tools.

Alternately, you could say that Lisp does exactly what it was meant to do: enable single and small teams of developers to engage in very productive exploratory programming. Carl Hewitt once told me that back in the heyday of Lisp (the 80's) they believed general AI would be solved by small teams of developers. Current AI efforts are the total opposite.

In this alternate interpretation, perhaps Common Lisp is simply not suited for large scale development or collaborations. Either due to language features or personality types. So maybe prototype in CL, then hire a few dozen Java devs to go to market.

I'm not trying to be down on CL. I love it and have been developing my open-source 3D system in it. But man, I can't believe there isn't a single cross-platform GUI toolkit for CL! Or a decent open-source IDE.

I guess we can do our small part and hope for the best.

> What we need are examples of Lisp-style languages leading to big wins.

How about JPL, used to control Mars probes and landers using ANSI lisp?

The most successful and influential CS course to date?

This website?

Lisp successes are out there. But it is harder to learn and understand than imperative languages, so it will never win out over Java and C# and Go and their ilk.

Due to the demand for developers outstripping the supply, we need languages that are safe for developers with wildly varying levels of skill to use - that limit the blast radius of their efforts in the worst case. One of the early design goals of Golang was exactly this - to make it simple for developers of varying skill to work together on code.

This isn't a knock on mediocre developers individually, but it is an unfortunate side effect of our need for so many of them.

The JPL Lisp story is a fun story, and cool application of Lisp over 20 years ago. But it is by no means a Lisp success story. There is a reason no space probe since then has been controlled using Lisp (as far as I know).

Your links didn't come through, so I don't know what web site you are referring to. Maybe Orbitz? That was one success and still continues to be developed in CL by Google AFAIK. One outlier data point perhaps.

As for the 6.001 course at MIT, I took that course back in the day, and was saddened to hear it now is taught in Python.

You are correct that we need languages which have a ready supply of developers. In a commercial setting that fact alone will trump any language features or technology advantage. Java was meant to be the new Cobol and works hard at limiting programmer flexibility so they don't shoot themselves in the foot.

"This website" referred to Hacker News itself, which is written in a Lisp (Arc).

I don't think there's anything remarkable about this website that could be considered a "big win" for Lisp. It's a totally run-of-the-mill dynamic web app that could have been developed more quickly in any web framework such as Rails or Django.

In fact, the hacky way it was implemented in Lisp had some clear downsides. In the early days (I'm probably going to mess up the details but hopefully the gist will come through) there was a notorious failure mode due to the way entities such as stories and comments were stored in memory using closures. These closures obviously had to be cleaned out periodically, and so if you stayed on a page too long and then clicked a link on the page, it would be invalid. You'd have to go back and refresh the page and click the link again. I don't think it's out of bounds to say this website is basically a rehash of the hacks pg came up with in the mid 90s to implement web apps in Lisp for Viaweb. The fact that he got rich off those hacks may have been a selling point for Lisp 20 years ago when he wrote Beating the Averages, but the world has moved on.

I agree that another language that's better for functional programming would make this more compelling. Python has a lot of limitations in this area. I think all of those alternatives you listed (Julia, Clojure, etc) include turn-offs for Python programmers that are deal breakers. So I'm seeking another language that appeals to Python programmers but has more of the attributes that are amenable to functional programming.

IMO, Ruby is a better general purpose "scripting" language like Python that has cleaner and more consistent features - including ones that lend themselves to functional approaches. Outside of web development it doesn't have the same appeal as Python due to the larger Python ecosystem... (many companies think they want to and will do "data science!")

Also, in my experience, Pythonistas tend to be more resistent to paradigm changes. So often I have heard, "Why would you want to do that?", or "This works fine as it is.". Not that I'm a fan of list comprehensions in Python (I think they're awkward and ugly compared to Ruby collection operations), but Python codebases I have had the displeasure of working in had lots of nested loops, mutations everywhere, copy-pasted code, and 30+ line methods. Trying to encourage single-responsibility, composability, less OOP, and more pure functions is like shoveling water uphill.

With both Ruby and Python you do need to be a bit thoughtful about unnecessary collection copies (which you would tend to favor when writing pure functions); but often you have a good sense of how large a volume of data you are handling and where copies will be particularly slow or heavy to do. When necessary, you can have an impure function that mutates input data, and at least in Ruby you can warn callers of the impending mutation by adding the ! to the function name. update_order!(order).