Why do we need this? We've already had Frege (https://github.com/Frege/frege) filling this role for roughly three years now. Seems to me the DRY principal doesn't just apply to personal projects but to public works as well.
I'd hope Eta "just" focuses on compiling GHC's core (not Core) intermediate-representation STG (or C--) into Java bytecode: then, no need to forever catch up re-implementing the ever-evolving language extensions, plus this just gets you all the desugaring / Core-to-Core optimization/simplification roundtrips, custom rewrite-rules, type checking / verification etc pp from GHC. In fact no need for any great checks and verifications, "just" (probably highly intricate in the end) a series of code format transformations.. in theory ;) GHC's various intermediate representations are pretty brilliant and thus I think should be leveraged as much as possible when it comes to new compilation targets and transpilation. Fun fact, seems as of 2002 there was for a while an STG-to-JVM backend.
Now there's issues with this approach too! You'd end up with a massively convoluted set of mappings of Haskell's factory defaults to the JVM's. We're talking the equivalents of `Prelude` module, `base` package, the RTS (garbage collector and much more.. ouch!), and for each and every individual instance deciding where to draw the line between Java's built-ins' semantics and GHC's would be a massive challenge.
What's with GHC's existing LLVM backend, does LLVM not have their own Java byte-code backend(s)? (OTOH, additional major dependencies always kinda bite..)
Eta in fact only deals with STG code -> Java bytecode transformation. I agree that the intermediate transformations are brilliant, so I am very careful about playing around with the frontend bit of the GHC codebase. Eta currently implements almost all of GHC's primitive operations faithfully. I have taken extreme care in preserving semantics. In some obscure cases though, I just gave up since there are no platform-independent ways of implementing certain things (like vectorised instructions).
GHC 8 will take some time. The current position is to prioritize those new extensions which start creeping up in Hackage libraries. There were significant changes to the codebase in 8 and I want to wait until it's stabilized. Eventually, yes.
No, you're right. I just don't want to swap out the frontends right now (again, stability). I'll definitely be cherry picking bug fixes and non-pervasive changes once I get a solid test/benchmark suite setup.
I'm quite disapointed by the decision regarding GHC8, though. Overloaded record labels adresses a problem which the community was quite annoyed with, for instance.
Don't worry. Solving the records problem is a high priority item for Eta. We might solve it in a different way than GHC 8, so that's where the 'dialect' part comes in.
If I were working on this kind of project, I'd just take code-that-compiles-in-GHC (ie. 1000s of samples --- just put up today for Haskell: https://github.com/metaleap/rosetta-haskell-dump ) and automatically verify the outputs-of-my-outputs match the GHC-compiled ones ... regardless of the actual real-world merit of said code samples themselves :)
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.
"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 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.
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.
> 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.
> 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.
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)"
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.
Perhaps it's not surprising that quicksort is very clear in functional languages, since C. A. R. Hoare was inspired to invent it by learning functional programming.
Perhaps it's not surprising that the common advice is to learn functional programming for the insights, since quicksort is not at all quick in its very clear functional programming form.
As Go language shows, even having a name that matches one of the most common English words goes not hurt too much; people will come up with a searchable moniker (like "golang") pretty soon.
For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment.
Basically, this project used to be a fork of the Haskell compiler to support the JVM. Now it's a fork of the Haskell compiler that may or may not be compatible for your use case depending on their opinion of GHC's features.
We maintain quite a bit of compatibility, which is why we have access to the wonderful, but dependency-heavy lens library. See the Eta Playground for an example.
> For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment.
maybe it's for the best? a ghc-is-the-spec approach to developing a haskell implementation seems... well, perhaps convenient, but less hygienic for the overall language. (that said i don't actually know what eta's philosophy here is.)
Eta will still be "Haskell" because they conform to the language spec, even if they don't have all the features of the latest version of GHC (the flagship Haskell compiler).
I agree with the grandparents disappointment somewhat though. At the very least there is still room for someone to build a JVM compatible backend for GHC, since this is no longer a goal of Eta.
I don't think it is necessarily a bad thing if they remain Haskell 2010 compliant and use pragmas for their own extensions. I certainly would like to see features like extensible records and variants; and this is unlikely to happen anytime soon in GHC, as the focus seems to be dependent types.
This is exactly the direction we're going. I'm a big fan of extensible records/variants. We'll be supporting the GHC 8 extensions that are orthogonal to the type system refactoring like Strict, StrictData, etc. pretty much everything other than TypeInType.
I'd say the focus (as always) is on making GHC a better compiler. Join points, levity polymorphism and the new typeable improvements are all in that category. And there's an amazing amount of stuff under the hood in 8.2. Dependent types? 8.6, 8.4 if they're lucky.
Oh, while the landing page doesn't mention Haskell, the documentation does (it says they don't use the name Haskell in an attempt to avoid the "26 years of psychology and perception that was built around the language").
That seems like wishful thinking. Anyone who knows anything about Haskell recognizes it on-sight. Anyone who doesn't will probably find it fairly radically different from what they're used to in a programming language, and not realize that it comes from a deep tradition with lots of community support.
I can sympathize with the reasoning behind the rebranding. "A new language on the JVM (which happens to be Haskell)" has a slightly different spin than "Haskell on the JVM". The latter sounds like it is targeted at Haskellers looking for new runtime choices, whereas the former is quite suggestive of moving Haskell a considerable step closer to the comfort zone of a certain group of non-Haskellers.
Unfortunately, the "(that happens to be Haskell)" part is completely left out on the entry page. This gives a terrible first impression, because it seems like if someone would be trying to bootleg those 26 years that went into Haskell and sell them of as their own achievement. The documentation does a reasonable effort to set this straight, but the aftertaste from the first impression remains.
One language to rule them all. Personally am rooting for both becoming a success, though Eta may have the easier path given that it can piggy back on the JVM, while Scala Native will have to, for example, come up with a plausible GC solution (i.e. matching JVM's world class GC is a tall task to say the least) along with porting myriad Java/Scala libs to native.
These are different beasts. Frege does not do the GHC extensions. Eta seems to reuse much of the GHC's frontend transformations, while Frege is built from the ground up.
What a pity. There are several strict JVM languages, but there aren't enough of them with compound values, i.e., unencumbered by pervasive use of object identities when manipulating compound data.
Laziness by default does not mean you can't have strict primitive types, which Eta does. Moreover, if you ever want to avoid object references in performance-sensitive contexts, you can allocate off-heap memory and work directly with that via the Ptr mechanism (which is backed by DirectByteBuffers). GHC 8 recently got compound values with an extension called UnboxedSums. It would be tricky to implement on the JVM though in Eta, but not impossible.
In a lazy language, a strictness annotation doesn't change the type of the annotated thing - bottom still inhabits that type.
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.
OTOH, most of the things I actually use laziness for in Haskell do not fall into the `foo lazy -> bar` category, because they involve things like floating out IO actions or renaming things, and in fact, changing the type makes them more cumbersome e.g.
if x then error "bad" else thing
to
let z = error "bad" in if x then z else thing
Which isn't a valid transformation in any strict language. This general idea is pervasive in the code I write, where the act of binding something is immaterial to its evaluation. I think we use this style a lot more than we give ourselves credit for in Haskell. You can of course wrap this in a thunk, and some of the usage style can be approximated by a monadic type. But this is all just really cumbersome and annoying to do pervasively. It's the best benefit I get from laziness, to structure code this way. You also end up duplicating a lot of strict-vs-lazy code either way you pick, since "crossing the streams" is generally either forbidden by the type system (in your example) or you need the different implicit characteristics (like in Haskell). It's not really clear to me this is a win overall.
I'm not opposed to strict languages, but IMO, I think if you want a strict language, you're better off just forgoing the whole thing, and using lambdas (thunks) where needed for small delays, and a good macro system to define control structures for everything else rather than trying to shoehorn laziness into your types or whatever. Random thunks you occasionally need aren't really the benefit. Being able to decouple definition from evaluation is.
In any language, not just a lazy one, “let x = v in t” is beta-equivalent to “t[x:=v]”, whenever “v” is a beta-equivalent to a value in the language. Of course, in a call-by-need (or pure call-by-name) language, every term is a value. In a call-by-value language, some terms are not values (and this is a feature).
Yeah and it also allows addressing beyond 2GB. I've been using DirectByteBuffers for the sake of being compatible with Android which I think doesn't give you access to the Unsafe API probably. I'll see if I can add a compiler option to use Unsafe for the JVMs that have it in the future. That'll probably do wonders for performance since Unsafe APIs are intrinsics. Unsafe is currently used in the Eta RTS for atomic CAS operations (which should be compatible in Android) on some of the RTS data types.
I really don't understand the need to squeeze as much functionality as possible out of as few lines as possible, that the code makes no sense no read. How am I supposed to parse the cryptic beginning example which shows the 2048 game being played? It looks like a ton of stuff has just been hidden way, which is fine for the example but likely all falls apart when you try to add something new to the game.
You can, see https://github.com/rahulmutt/eta-2048. The whole point of that example was to demonstrate that you can build nontrivial things with Eta right now. Just have to deal with Java FFI boilerplate which requires some patience without any IDE support.
I'd argue the exact opposite: what we don't need right now is yet another language that most differs from its peers by aesthetics and engineering. If a language doesn't offer you something conceptually new, it might have been better offered as a library.
There is a bug in the code, unless the input is expected to be a set instead of a list.
I believe the right implementation should be something like:
main :: IO ()
main = print $ quicksort [1, 123, 42, 90, 1, 23, 24, 12, 3]
quicksort [] = []
quicksort (x:xs) = quicksort left ++ [x] ++ quicksort right
where left = [ y | y <- xs, y < x ]
right = [ y | y <- xs, y >= x ]
Have you considered replacing the example entirely? A toy program that looks good but is terribly nonperformant is exactly what I'd put up if I wanted to make a Haskell-style language look bad.
Performance of a tiny code sample is not why people select one language over another. If that was the case, no one would be using anything besides assembly or C. Even in other languages, you'll use an abstraction heavy implementation for the benefit of long-term maintenance and code evolution and then performance optimise the bits that can pack a punch. Performance optimisation in any language looks ugly be it C or Haskell.
The benchmarks I've run are extremely promising, and Eta is sometimes competitive to GHC after warmup. GHC's aggressive optimisations with -O2 + Oracle JVM's JIT seem to be a very powerful combination. I have avoided publishing the results because I still need to spend more time looking at the numbers and understand why was so fast in certain cases (check up on any mistakes I've made). I'd rather take the time to report proper benchmarks rather than hype unverified results.
Its amazing that if you put down all the languages that consider themselves powerful and scalable you somehow reach what religion is...everybody thinks their god is the only one, and if one indeed exists all the rest are wrong by default!
Technology is fair and there is a reason why haskell is not used apart from niche or academic projects. If you want to use jvm to deliver functionality for your users just a "boring" technology. No user, never, cared about the programming paradigm.
I hear you, but I don't know that technology is "fair". That's a bit much. I mean, JavaScript just got there first. It's a downright terrible language.
> haskell is not used apart from niche or academic projects
While haskell doesn't have as wide adoption as the top languages, your comment is not true. Even facebook uses haskell for fighting spam.
> If you want to use jvm to deliver functionality for your users just a "boring" technology
You're entitled to your preference, but I assume you'd say the same about about Clojure and Scala then, since, after all, everyone should just be using Java?
You would be correct if we branded it as "the" powerful language, but we used "a" meaning it's one of many for you, the programmer to chose. I have practically found Haskell-like languages to deliver lots of value in business settings and I want to bring those advantages to everyone who would like to take advantage of it, reducing the risk of adoption as much as possible. No user ever cared about the programming paradigm, but I think they would be happy if bugs were fixed faster (or not present in the first place) or if new features were added without breaking existing features.
> No user, never, cared about the programming paradigm.
This is an old straw man. No one is trying to sell the language to users, but rather to developers; and developers look for toolchains that let them deliver features to users.
Hmmm...could get me back into Haskell (cough--mean Eta). I always hated the Haskell environment. A nice to work with port to JVM could inject some life back into that interest. There was Frege, but it just seemed fringe at the time...we'll seem if this has any steam behind it.
i feel like each "new" general-purpose language project is just nipping at the boot-heels of the much bigger problem of constructing large-scale systems that can be fully understood by a few (2-3) people.
VPRI's research has shown that one important method for constructing large-scale systems that can be understood by small teams is to have a pipeline of problem-specific languages that express major portions of the system. they were able to reduce LOC for a typical OS with networking and graphics by 3 or 4 orders of magnitude.
general-purpose languages can't compete with DSLs in terms of expression, and yet we keep inventing them. i think our lack of imagination is starting to show. compilation and language design will need to become much more common-place if we expect to continue scaling up.
a tower of babel in computing is healthy, no matter how much employers want us to be easily-replaceable cogs in an IT machine.
(1) This language has been invented long ago; its name is Haskell. Eta is a JVM backend / target for it.
(2) A good general-purpose language is good at creating pseudo-DSLs, also known as abstractions or APIs. This can include customized syntax, but usually it's not a brilliant idea. DSLs using the common syntax are quite prevalent in Lisp / Scheme / Clojure, or in Ruby. Haskell is reasonably good at creating DSLs, much better than e.g. Java.
I think it might interest you that Haskell-like languages are one of the best languages for programming EDSLs after Lisp-like languages. If I recall correctly, Standard Chartered uses an EDSL written in Haskell that's maintained by ~10 Haskell programmers and the remaining ~90 people program inside of this EDSL for specifying new rules. Similar case for Facebook and their spam filter rules.
every framework we use -- library, language, runtime, operating system, hardware -- makes decisions that constrain what we can express.
languages like haskell, lisp, or ruby may make it easy to create new control structures that blend well with the existing syntax, but new control structures don't help if it's still annoying to write, say, very long lines of free-form text -- a problem that xml handles more gracefully than lisp. syntax makes a difference.
i think it's unlikely we'll win a several-orders-of-magnitude decrease in complexity by confining ourselves to the syntax decisions of one language.
I think general purpose languages have primacy because they have the flexibility to allow the author to create a DSL for the problem domain being addressed. I.e. Bottom up programming.
I agree with this personally, but if you read through VPRI's publications you will find that the vast majority of their DSLs seemed to converge to "functional with some special features (which you could implement in Haskell using monads)". This is especially interesting, since in early publications they started with a number of truly different designs.
The hard part is finding the right abstractions on which to build your large-scale system. When you have those abstractions, you can build a DSL to help you implement your system. Or you can build an API for an existing language. They are two sides of the same coin and I can see arguments for / against either approach.
I think where your criticism is really valid is that they are building tools that they think will help them address the real problem. But it's not clear that they have a real problem yet and that they fully understand it. If they do and Eta is their "DSL" to solve it, then that's great.
I have way too often fallen into the trap of finding (or dreaming about) the right language / IDE / etc. to solve my problem instead of actually working on the problem and gaining a better understanding of it. It's so easy to spend all your time on technical details because it's fun when you really should be worrying about the stuff that pays the bills.
I'm interested in what the trade off between "lazy by default" and "Eager by default, with some great lazy data structures you can use" is?
Often programming language support for streams will feel a little second class, and I'd love to have something as first class seeming as Haskells lazy list - but that's a minority of the time for me.
167 comments
[ 4.0 ms ] story [ 220 ms ] threadAnd this is the blog post from the co-founder of Typelead (the company behind Eta) discussing about it: https://blog.typelead.com/https-blog-typelead-com-introducin...
* https://github.com/typelead/eta/blob/master/docs/source/faq....
* https://github.com/typelead/eta/issues/3
Now there's issues with this approach too! You'd end up with a massively convoluted set of mappings of Haskell's factory defaults to the JVM's. We're talking the equivalents of `Prelude` module, `base` package, the RTS (garbage collector and much more.. ouch!), and for each and every individual instance deciding where to draw the line between Java's built-ins' semantics and GHC's would be a massive challenge.
What's with GHC's existing LLVM backend, does LLVM not have their own Java byte-code backend(s)? (OTOH, additional major dependencies always kinda bite..)
I'm quite disapointed by the decision regarding GHC8, though. Overloaded record labels adresses a problem which the community was quite annoyed with, for instance.
Ironically it says "A powerful language for building scalable systems on the JVM" but this literally doesn't scale as quicksort does.
http://stackoverflow.com/questions/7717691/why-is-the-minima...
https://wiki.haskell.org/Introduction#Quicksort_in_Haskell
This is related to the "Genuine Sieve of Eratosthenes", which is also an imperative algorithm and NOT a functional one:
https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
This brings to mind the slur "Haskell (Lisp) programmers know the value of everything but not the cost".
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.
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.)
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.
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" [0].
That aside, I completely agree with the spirit of your comment.
[0] http://www.aosabook.org/en/ghc.html
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.
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.
Perhaps it's not surprising that the common advice is to learn functional programming for the insights, since quicksort is not at all quick in its very clear functional programming form.
As Go language shows, even having a name that matches one of the most common English words goes not hurt too much; people will come up with a searchable moniker (like "golang") pretty soon.
Basically, this project used to be a fork of the Haskell compiler to support the JVM. Now it's a fork of the Haskell compiler that may or may not be compatible for your use case depending on their opinion of GHC's features.
maybe it's for the best? a ghc-is-the-spec approach to developing a haskell implementation seems... well, perhaps convenient, but less hygienic for the overall language. (that said i don't actually know what eta's philosophy here is.)
I agree with the grandparents disappointment somewhat though. At the very least there is still room for someone to build a JVM compatible backend for GHC, since this is no longer a goal of Eta.
Unfortunately, the "(that happens to be Haskell)" part is completely left out on the entry page. This gives a terrible first impression, because it seems like if someone would be trying to bootleg those 26 years that went into Haskell and sell them of as their own achievement. The documentation does a reasonable effort to set this straight, but the aftertaste from the first impression remains.
Haskell <> JVM with Eta[1]
Scala <> Native with Scala Native[2]
One language to rule them all. Personally am rooting for both becoming a success, though Eta may have the easier path given that it can piggy back on the JVM, while Scala Native will have to, for example, come up with a plausible GC solution (i.e. matching JVM's world class GC is a tall task to say the least) along with porting myriad Java/Scala libs to native.
[1] https://github.com/typelead/eta
[2] https://github.com/scala-native/scala-native
Is Eta strict or lazy?
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.
I'm not opposed to strict languages, but IMO, I think if you want a strict language, you're better off just forgoing the whole thing, and using lambdas (thunks) where needed for small delays, and a good macro system to define control structures for everything else rather than trying to shoehorn laziness into your types or whatever. Random thunks you occasionally need aren't really the benefit. Being able to decouple definition from evaluation is.
Edit: Darn, I'm stupid. It's a port of Haskell to JVM.
I believe the right implementation should be something like:
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.
The stock image on the about-us page threw me off. Great going guys!
We have already been sold on Kotlin... but Eta looks interesting.
I'm curious about how the jvm will behave in regards to laziness and typeclasses (MTL-like libraries, in particular).
Technology is fair and there is a reason why haskell is not used apart from niche or academic projects. If you want to use jvm to deliver functionality for your users just a "boring" technology. No user, never, cared about the programming paradigm.
While haskell doesn't have as wide adoption as the top languages, your comment is not true. Even facebook uses haskell for fighting spam.
> If you want to use jvm to deliver functionality for your users just a "boring" technology
You're entitled to your preference, but I assume you'd say the same about about Clojure and Scala then, since, after all, everyone should just be using Java?
This is an old straw man. No one is trying to sell the language to users, but rather to developers; and developers look for toolchains that let them deliver features to users.
VPRI's research has shown that one important method for constructing large-scale systems that can be understood by small teams is to have a pipeline of problem-specific languages that express major portions of the system. they were able to reduce LOC for a typical OS with networking and graphics by 3 or 4 orders of magnitude.
general-purpose languages can't compete with DSLs in terms of expression, and yet we keep inventing them. i think our lack of imagination is starting to show. compilation and language design will need to become much more common-place if we expect to continue scaling up.
a tower of babel in computing is healthy, no matter how much employers want us to be easily-replaceable cogs in an IT machine.
(2) A good general-purpose language is good at creating pseudo-DSLs, also known as abstractions or APIs. This can include customized syntax, but usually it's not a brilliant idea. DSLs using the common syntax are quite prevalent in Lisp / Scheme / Clojure, or in Ruby. Haskell is reasonably good at creating DSLs, much better than e.g. Java.
languages like haskell, lisp, or ruby may make it easy to create new control structures that blend well with the existing syntax, but new control structures don't help if it's still annoying to write, say, very long lines of free-form text -- a problem that xml handles more gracefully than lisp. syntax makes a difference.
i think it's unlikely we'll win a several-orders-of-magnitude decrease in complexity by confining ourselves to the syntax decisions of one language.
I think where your criticism is really valid is that they are building tools that they think will help them address the real problem. But it's not clear that they have a real problem yet and that they fully understand it. If they do and Eta is their "DSL" to solve it, then that's great.
I have way too often fallen into the trap of finding (or dreaming about) the right language / IDE / etc. to solve my problem instead of actually working on the problem and gaining a better understanding of it. It's so easy to spend all your time on technical details because it's fun when you really should be worrying about the stuff that pays the bills.
Often programming language support for streams will feel a little second class, and I'd love to have something as first class seeming as Haskells lazy list - but that's a minority of the time for me.
Again.