Hacker News Reader

Comment by nine_k | Hacker News Reader

The example is simple and expressive, it's relatively easy to understand even if you don't known the language. It gives you the idea of the expressive power.

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.

View on HN

"Relatively easy to understand even if you don't know the language" <- We have empirically verified this by showing code samples of quicksort side-by-side in Java, Scala, Clojure, and Eta to ~100 programmers who had no experience with functional programming at an exhibition. Eta won, followed closely by Scala (people just love their curly braces!). One person liked Clojure because of "it looked like English" and no one liked Java. For this reason, we have posted it on the landing page. We have made no claims that it's the most performant nor that it's the fully correct quicksort (accounting for uniques) - the whole point was to highlight the expressiveness.

I'm curious, though, if this is really applicable. There are two problems, to me.

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

I agree that it's not a good implementation, as I said it's for illustrative purposes. You also don't implement the "Hello World!" program ever in real life, yet every programming language intro starts with that. Relative to that, a sorting algorithm is a lot more instructive. I think if I changed the name of 'quicksort' to 'sortUniqueList' that would clear things up.

Hmm... fair. I am criticizing something without a suggestion.

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

2048 was just convenient. It just so happens that there was an existing Haskell project that used the native GLTK library. I just swapped that out with JavaFX and it worked. If I were to write a book on Eta, I would certainly use a simpler game! I personally learned to code as a child by playing with examples and developing a game, so I can bet your kids are going to grasp programming fast. The human brain learns naturally from examples as opposed to theory.

If I understand you correctly, you basically verified this for Haskell (which you call Eta), since there are no visible differences with Haskell yet.

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.

Check out the FAQ: http://eta-lang.org/docs/html/faq.html. For the record, I love Haskell as a language and even after solving the tooling and documentation problems, it doesn't solve the integration problem. The JVM is widely used and being on top of it makes it easy to integrate into existing systems. You can certainly reuse code between Eta and Haskell given the number of extensions that are in common.

Well, I didn't find the answer to my question in the FAQ. I see where you want to differ from GHC, but I don't see where you want to differ from Haskell standard.

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.

How Eta's going to differ from the standard is not clear for me either. It's dependent on a lot of factors, such as how GHC decides to evolve and how that affects the usability of the language. The whole point of the name change was to have the choice of not accepting the new features if we felt they weren't ready yet for wide consumption. GHC is a playground for PL research, and SPJ has made that clear on many accounts. It's great for research, but scary for industry adopters. We are focused on industry more than research.

So what it looks like you want to remain compatible with the Haskell 2010 standard, with some conservative extension choices. Unless a new standard of Haskell appears that you choose to disagree with, why not just accept that what you're doing is compiler of standard Haskell? I don't see why abiding to compliance with standard Haskell should be scary for industry adopters, on the contrary.

SPJ and others acknowledged that the adoption by industry had changed the way of developping Haskell, though, making playground moves less likely if they hurt existing features.

I think that's smart.

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.

> full of half-discarded research projects, dependency on offshoot libraries, and a ton of tribal culture.

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" [0].

That aside, I completely agree with the spirit of your comment.

[0] http://www.aosabook.org/en/ghc.html

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

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.

I'm not sure familiarity means anything useful, but I guess it helps being being a popular language.

It was actually not familiarity. We specifically asked people "Which code sample looks readable to you?" People just love concise code. Less cognitive burden.

The fact these people were picked at a conference is already very strong confirmation bias.

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.

Pick 100 random programmers in 1970 and most of them would be more comfortable with GOTO-based programming, for variety of reasons, including performance.

"Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain, ~150 years ago)"

> "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.

Indeed.

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.

Not that I'm objecting! I'm commenting. Sometimes stating the obvious helps trigger that "pause and reflect" thing.

1. So it's a language optimized for the kind of programmers who go to conferences, nothing wrong with that.

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.

I'm sorry this isn't at all easy to understand if you don't know the language. For example what is $ in this context how does <- work, how does the where clause work precisely and why is it required before the assignments? Is the colon required to separate arguments?

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.

"Great in theory, terrible in practice" is a good summary of pure functional programming, in my experience :-)

I'd love to hear about your experience and ways I can build Eta to make that experience better. Feel free to shoot me an email.

Reply on news.ycombinator.com