FWIW the demo snippet is a toy and not the real quicksort, which is in-place, rather than copying the list / creating garbage at every step.<p>Ironically it says "A powerful language for building scalable systems on the JVM" but this literally doesn't scale as quicksort does.<p><a href="http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort" rel="nofollow">http://stackoverflow.com/questions/7717691/why-is-the-minima...</a><p><a href="https://wiki.haskell.org/Introduction#Quicksort_in_Haskell" rel="nofollow">https://wiki.haskell.org/Introduction#Quicksort_in_Haskell</a><p>This is related to the "Genuine Sieve of Eratosthenes", which is also an imperative algorithm and NOT a functional one:<p><a href="https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf" rel="nofollow">https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf</a><p>This brings to mind the slur "Haskell (Lisp) programmers know the value of everything but not the cost".
For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment.<p>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.
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.<p>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.<p>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.<p>a tower of babel in computing is <i>healthy</i>, no matter how much employers want us to be easily-replaceable cogs in an IT machine.
Awesome,<p>Haskell <> JVM with Eta[1]<p>Scala <> Native with Scala Native[2]<p>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.<p>[1] <a href="https://github.com/typelead/eta" rel="nofollow">https://github.com/typelead/eta</a><p>[2] <a href="https://github.com/scala-native/scala-native" rel="nofollow">https://github.com/scala-native/scala-native</a>
This is the relevant github repository: <a href="https://github.com/typelead/eta" rel="nofollow">https://github.com/typelead/eta</a><p>And this is the blog post from the co-founder of Typelead (the company behind Eta) discussing about it: <a href="https://blog.typelead.com/https-blog-typelead-com-introducing-typelead-14c4a1bf2df#.7zt3riywq" rel="nofollow">https://blog.typelead.com/https-blog-typelead-com-introducin...</a>
Why do we need this? We've already had Frege (<a href="https://github.com/Frege/frege" rel="nofollow">https://github.com/Frege/frege</a>) 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'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?<p>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.
There is a bug in the code, unless the input is expected to be a set instead of a list.<p>I believe the right implementation should be something like:<p><pre><code> 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 ]</code></pre>
That's great news !<p>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.
I don't really mind if Eta ends diverging from Haskell in the particulars but remains Haskell-like à la Purescript.<p>I'm curious about how the jvm will behave in regards to laziness and typeclasses (MTL-like libraries, in particular).
Does it come with a debugger of any kind?<p>I think this is the biggest gap in the Haskell ecosystem right now. Every time I try to write something in Haskell, I remember I cannot "talk to my program" easily and just give up.
The quicksort example seems oddly named, I would have called it "unique" or "removeDuplicates".<p>If you change one of the inequalities, say ">" to ">=", then it does sort (without removing duplicates). It still wouldn't feel fair to call it "quicksort" because it isn't in place.
Awesome! built in Bangalore - <a href="http://typelead.com/contact-us/index.html#our-office" rel="nofollow">http://typelead.com/contact-us/index.html#our-office</a><p>The stock image on the about-us page threw me off. Great going guys!<p>We have already been sold on Kotlin... but Eta looks interesting.
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.
This makes me wonder again: is there any such language but for people wanting an <i>eager</i> (not lazy) Haskell?<p>(and I don't care for it to be JVM. but I do care for it to be be Haskell... OCaml is not Haskell and has too many weird dark corners imho)
If they had any marketing sense, they would start by telling me why it's better than Clojure. I'm sorry to offend the Scala guys, but if you want to be the best JVM language, you need to improve on Clojure.
One of these must need some division...<p><pre><code> feet2Meters :: Feet -> Meters
feet2Meters (Feet ft) = Meters $ ft * 0.3048
meters2Feet :: Feet -> Meters
meters2Feet (Meters m) = Feet $ m * 0.3048</code></pre>
Seems 99% written in haskell/eta itself, with a little c.<p>So, the compiler won't run on the JVM... if it did, there could be haskell dev on-the-device for Android...
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.
I'd personally just support Frege more instead of reinventing the wheel. <a href="https://github.com/Frege/frege" rel="nofollow">https://github.com/Frege/frege</a>
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!<p>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.