Eta – A powerful language for building scalable systems on the JVM

First, this is not a good implementation of quicksort. Second, it is not often that people will be implementing quicksort.

Why make another language anyway, if your experiment shows that Haskell is readable? You're saying that the problem with Haskell adoption are lack of tooling and documentation, which can surely be resolved without having to design another language. In fact, I don't think bad language design hindered adoption of any language ever (examples: COBOL, APL, MUMPS, BASIC, PHP, Javascript).

I wish you wouldn't break compatibility with Haskell, ever. I think it would make both languages stronger (if they were just one), since everybody could just reuse code. I don't see a reason for having another language just to fix minor syntactic problems.

Edit: I think what I am not clear about is where exactly do you intend to break the compatibility with Haskell and how do you think that action will help adoption of your language.

Pick 100 random (really random) programmers and I'm betting a lot more of them will feel more comfortable with the imperative version over all the others.

It's not how people should choose a language, but I'd wager it plays a non-trivial part even if only from laziness alone.

We have to remember we aren't marketing to perfect* developers but more to the average if an aim is mass adoption.

*Perfect as in follows general programming best practices. Following best practices is not always best. Not trying to make a value judgment here.

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))

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.

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.

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.

This is where the ease of refactoring with static typing comes into play. An argument could be made that static typing facilitates writing code that has a lot of coupling between components.

Dynamic typing forces you to break things up into independent components much more aggressively. I think that it's a very good thing. Low coupling allows for higher code reuse, and reduced mental overhead when reasoning about code.

If you look at the Clojure ecosystem, most of it consists of small focused libraries that solve a particular problem.

Conversely, projects are structured using small independent modules that implement a particular piece of functionality. These modules can be tested at the API level.

When I make any changes, I run the API tests and if those pass, then I know that the modules does what it's supposed to. Now we also have Spec that makes it even easier to express constraints and document intent of the code.

I've never found the need to do TDD or have unit tests when working with Clojure. When I'm developing new functionality, I use the REPL, and I know exactly what my code is doing at any time.

Once the functionality is implemented and the code is doing what I need, I turn the REPL session into tests at that point.

On the other hand, in a strict language with a laziness monad, the difference between, say, `foo -> bar` and `foo lazy -> bar` (ML syntax) is as clear as daylight. The types tell you what's going on.