As crazy as it sounds, I could imagine myself making such a claim, but only because of Clojure's position as a dialect of lisp.

The reason I think I could make a claim is because of lisp's dedication to simplicity -- technically most general-purpose languages are equivalent, but lisps stand apart for me because they generally focus on giving the programmer the tools to build what they want and nothing else. As a result of this, lisps are generally (if not always): multi-paradigm, DSL-friendly, etc.

This is getting long, but the basic point is, I could see lisp being an end-all be-all of programming languages, because it gives the programmer the right tools, and I can almost always easily envision going from lisp -> some other language (ex. haskell) than I can going from some other language (ex. haskell) -> lisp. You could also of course say similar things about assembly or other languages that give the programmer even less, but lisp strikes what I think is the best balance I've seen for giving just enough power, without requiring too much in return from the user, specifically talking about language ergonomics (leaving out implementation details like garbage collection, etc).

Yeah, no one does that.

There's a reason other languages exist and Lisp hasn't simply supplanted them. If I want a HM-style strictly typed, lazily evaluated programming language, I'm not going to build it myself on top of lisp. I'm going to find a language that suits my preferences and simply use it.

Besides, you could make the same claim about any programming language. "Hey, C is the ultimate language because I could use it to build a compiler for the language I actually want!" Correct in theory. Meaningless in practice.

As for being multi-paradigm, balance between functionality and simplicity, etc, those are all personal preference. A Haskeller could equally say they like an opinionated language that gives them a rich set of tools to build correct programs more easily. These are factless value-judgements. Which is why HN sees new programming language announcements every other week...

What you're saying is true, but there's not that much you can say about languages that ISN'T personal preference, in the end. What I'd really like to hear is from someone that's enjoyed lisps, AND other languages, and feels that another language would be the one on which to make this claim (the claim that a language was the "end-all-be-all" of programming languages).

You mentioned not building it yourself on top of lisp, but that wasn't my point. My point is that if I DID have to build it myself, I would choose lisp as the language to amend, not that it makes sense that everything is built on lisp. That's what makes me think of it as a possible end-all-be-all language for me, and what makes me think I could make that claim about it. I can't think another language that is as expressive, flexible, yet as simple as lisp.

My point was that, knowing and liking languages other than lisp, Lisp is the only language that I could consider making such a claim about. A haskeller COULD easily say they like an opinionated language, and that would totally be their choice, and they'd be right, for them. I simply offered my opinion why I could imagine myself making that claim.

I agree, which is why I said your original comment (that these guys need to prove their language is somehow better than Clojure, because Clojure is, in your opinion, the "best" language on the JVM) was a bit vacuous. ;)

Incidentally, I will say I'm enormously pleased that Clojure has seen some non-trivial success, and I'm happy you've found a language that you seem to enjoy so much. Lisps have a lot to offer the world, and it's nice to see a mainstream, Lisp-derived language running on a modern platform like the JVM!

I happen to feel the same way about projects like this one that are bringing ML-derived languages to the JVM (incidentally, I also happen to be an F# fan on the CLR for the same reason).

And the fact that you could happily use both for different parts of a problem domain in the same project makes me happier still!

Indeed, why would you; Mark Tarver already built something like that, calling it Qi.

> Yeah, no one does that.

You just don't know about it because these languages typically look like Lisp on a superficial level. Those who don't know the second thing about Lisp can't see what has been done, just symbols or parentheses. Nothing visually says "I am lazily evaluated and typed" or whatever.

Many Lispers don't want to build the language they want, simply because that language is Lisp.

So if someone is going to sell me on a better JVM language, they need to at least give me a pro/con list vs Clojure. While HN might disagree, the market (people who work in companies that live for revenue, not VC) will agree in my interest for that comparison.

So let's say I have a function that needs :name and :addr and it adds a new field calls :name+addr. Now in most (all?) statically typed languages I would have to say that this function takes a "name and addr" and returns "name, addr, and name+addr". So I have a type conversion, right? If the time comes that I need to modify these types, I have to do some sort of refactor.

In Clojure we'd just take a hash map and add a new k/v pair to the hash map we get. Any hash map will work, as long as it has the proper entries, and we'll just add a new entry to that. So if the time comes that I want to call this function with a "company" instead of a "person", it just works, as long as I have the proper keys. And to help check this sort of stuff we do have spec (https://clojure.org/about/spec).

TL;DR -- my belief having programed in both static and dynamic languages is that deep refactoring is primarily driven by the inflexibility of static types.

Clojure and Haskell are two almost completely different beasts. Thanks to clojure's simplicity (as a dialect of lisp), it could BECOME haskell if you wrote the DSLs for it, but the reverse is much harder, I would think.

Eta is not looking to convince clojurists to use haskell on the jvm instead of clojure, it's (most likely, I don't maintain the project) to enable those who want to use haskell but want to also use the JVM to do so.

Regardless of whether Haskell is a better choice for your project or clojure is, the eta team (or any other team for that matter) is under no obligation to find that out for you, or even to make your search any easier. That's your job -- if clojure still fits your needs and doesn't have any glaring issues, absolutely use it.

I think the statement is almost axiomatic. Lisp is multi-paradigm, by way of simplicity/choices not being made for you. Haskell is decidedly functional (which is something I love about it). Making a more specific thing into a less specific thing (while possible in this case), seems like a more difficult task than molding the clay that is LISP to look like haskell.

Clojurescript is just wonderful. I'm not even sure a Haskell-like language that compiles to JavaScript (Elm, PureScript, GHCJS) with really good tooling can beat it, though I haven't tried. Would be an interesting experiment to do a comparison by writing the same app in all the languages.

Just compare:

    foo.bar(baz)

    (.bar foo baz)

Sure CommonLisp has a ton of parens, but thats CL and it has its own set of issues.

One more example:

    Runnable foo = new Runnable() {
      Object run(Object bar)
      {
        return bar;
      }

    }

    (reify Runnable
      (run [bar]
        bar))