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.
Ironically it says "A powerful language for building scalable systems on the JVM" but this literally doesn't scale as quicksort does.
This is related to the "Genuine Sieve of Eratosthenes", which is also an imperative algorithm and NOT a functional one:
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.
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.
The website is exactly what a programming language website should be. Syntax and features front and center.
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.
Haskell <> JVM with Eta
Scala <> Native with Scala Native
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.
This is the relevant github repository: https://github.com/typelead/eta
And 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...
Java's hunger for memory, combined with Haskell's unpredictability wrt memory allocations due to laziness. What could possibly go wrong.
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.
Looks like they don't acknowledge it on the landing page, but this is probably an implementation of Haskell, or of a dialect of Haskell.
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.
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 ]
There's a bug in the quicksort implementation example (it assumes all values in the list are unique).
Looks similar to Haskell.
Edit: Darn, I'm stupid. It's a port of Haskell to JVM.
That's great news !
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.
Does it come with a debugger of any kind?
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.
I don't really mind if Eta ends diverging from Haskell in the particulars but remains Haskell-like à la Purescript.
I'm curious about how the jvm will behave in regards to laziness and typeclasses (MTL-like libraries, in particular).
How is this "scalable"? What does that mean?
The quicksort example seems oddly named, I would have called it "unique" or "removeDuplicates".
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 - http://typelead.com/contact-us/index.html#our-office
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.
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 eager (not lazy) Haskell?
(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)
Has a gitter and slack but no IRC?
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...
feet2Meters :: Feet -> Meters
feet2Meters (Feet ft) = Meters $ ft * 0.3048
meters2Feet :: Feet -> Meters
meters2Feet (Meters m) = Feet $ m * 0.3048
When you write about this new language, you'll be on the no-fly list soon :)
Seems 99% written in haskell/eta itself, with a little c.
So, the compiler won't run on the JVM... if it did, there could be haskell dev on-the-device for Android...
I'd like to know if the most scalable technique for reasoning about program data works: structural induction!
Is Eta strict or lazy?
This looks really cool. How are the language services coming along? Can we expect something on par with F#'s?
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.
Does anybody knows about syntax highlighting support?
I'd personally just support Frege more instead of reinventing the wheel. https://github.com/Frege/frege
What an unfortunate name.