I have seen in-place quicksort in Haskell and it is not pretty.
It's not performant, though, and should not be considered a real quicksort implementation. So it's not showing you the cost of this particular abstraction.
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.
It seems to me that the Eta language is basically Haskell 2010 compliant compiler/runtime (correct me if I am wrong) for JVM.
Which actually is great and useful and I really like that about the project. I just think the project shouldn't be called "another language", but rather "Haskell 2010 compiler with some GHC extensions for the JVM". I actually don't even care if you avoid Haskell in the name, as long as you keep the compatibility.
When we say "Haskell" it's difficult to separate it from "GHC's Haskell" which is a much more confusing beast, full of half-discarded research projects, dependency on offshoot libraries, and a ton of tribal culture.
It's sort of like the CLHS and CLisp vs Clojure.
That's a bit harsh. GHC is a pretty old beast and its source isn't as nice as I wish it was (if only imports were qualified and every GHC source file didn't start off with a huge list of imports), but it is hardly as bad as you make it sound. It is pretty darn-well maintained. Heck, it is even one of the examples in "Architecture of Open Source Applications" .
That aside, I completely agree with the spirit of your comment.
I don't know the degree to which you want to make it sound bad. I think it's just the reality of GHC Haskell. There are many language extensions and while at any given year a given set are normal, as time goes on that set changes. But in many cases, we don't get new libraries that switch to new extensions, so we end up supporting a rather large superset of Haskell in ghc over time.
So while yeah, the GHC codebase itself is fine, the culture and the community providing the library ecosystem has made things challenging.
What's more, some of the core concepts haskellers lean on are just... I dunno. Underbaked? I've used a lot of lens libraries and conduit libraries now and they always feel a bit undercooked.
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.
"Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain, ~150 years ago)"
That seems to be exactly what hota_mazi is saying.
Mark Twain's quote is also often misunderstood. It doesn't mean you should never be in the majority, it's about always questioning your choices.
Personally, I go one step further and I always pause and reflect, whether I'm in the majority or not.
2. This goes far above and beyond what most other language designers do, which seems to be "write the kind of language I want to use." Nothing wrong with that, either, but no sense in criticizing the language designers doing more research than most for not doing enough research.
First, this is not a good implementation of quicksort. Second, it is not often that people will be implementing quicksort.
I don't have one and I confess that worries me. In trying to teach my children, I have actually grown away from the "this is what the code looks like" to examples. And I commend the site for doing that. 2048 seems like an odd example, but conciseness is the goal, I'm guessing. Still a fun one. (Snake would be more fun for kids, I'm guessing. But that is just a guess.)
I'm not expecting you to give me a tutorial here in the comments and I'm 100% sure I could read a tutorial and understand in a few minutes but it doesn't seem particularly obvious if you don't know haskell.
Its easy to misread familiar as obvious.