I love seeing new Haskell projects, though I personally would rather just stick with Haskell's clean syntax:<p><pre><code> data Maybe a = Nothing | Just a
</code></pre>
...over this:<p><pre><code> data Maybe<a> {
Nothing,
Just(value: a)
}
</code></pre>
I understand that programmers coming from mainstream languages might feel uncomfortable without all those angle brackets, curly braces, and parentheses (why do C-like languages have so many ways to syntactically group things?), so if this project helps them ease their way into Haskell I totally support it. However, a small part of the joy of Haskell is freeing yourself from the arbitrary syntactic boilerplate that most languages have.
I personally prefer Haskell's syntax. I find myself using JavaScript transpilers like BuckleScript to take me into a typesafe land with ML syntax rather than using a language like TypeScript with Java like syntax.<p>That said, I really appreciate seeing work like this. Haskell is super powerful and it's great to see transpilers like this that are lowering the bar of entry to Haskell to those more familiar with the traditional languages. Nice job!
I dont think a lack of curly braces is whats keeping haskell from taking off. It’s the “I need to go study category theory to be able to read the docs on any useful package” problem and the proliferation of language extensions. Taking some of the ivory tower out of the learning curve will do a lot more than adding some tokens.
Whoa, this is amazing! I find this example much, much easier to read:<p>> For example, where Haskellers would write:<p><pre><code> f = average . filter (> 0) . map normalize
</code></pre>
> in hinc the idiomatic translation would be:<p><pre><code> let f(lst) = lst.map(normalize)
.filter((x) => x > 0)
.average
</code></pre>
These seems like very sane, pragmatic choices considering the massive segment of programmers used to C/Java/JavaScript derived syntax.<p>Now, if the currently top comment about category theory could be addressed, I think we'd have something.
The thing that's always turned me off Haskell is language extensions and the associated fractal fracture of the language. Sorry, I don't want to learn a dozen different styles of a language.<p>PureScript always seemed a little more appealing from that perspective, but doesn't seem to have really caught on (eg; <a href="https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=purescript" rel="nofollow">https://trends.google.com/trends/explore?date=today%205-y&ge...</a>)
As far as functional languages go, F# (and thus OCaml which is the parent language of F#) IMO has the best syntax. The code is actually readable even if you haven't ever written a functional program and everything feels super practical about it.<p>Its a shame that F# doesnt gets the attention it deserves.
I want to like Haskell, but I think lazy evaluation is fundamentally broken. Haskell's facility for optional strict evaluation doesn't really repair the fundamental defect, which leads to memory leaks and unpredictable performance. And certain magic functions are strict anyway, and you just have to know what those are. I just don't see making lazy sequences easy as being worth the cost of making lazy evaluation the syntactic default.<p>Given that Haskell is fundamentally and irreparably broken (IMHO) in this way, it seems like a waste to devote effort to it instead of better functional languages like ML.
To me the biggest advantage of this that it's not whitespace sensitive, which makes it way easier to refactor and automatically indent/format code. Although I'd have preferred something more ML-like.
As a Typescript developer, I really like this! Haskell has always been difficult for me to grok but this syntax makes bridging the gap really intuitive. Bravo!
It's a great attempt, just like ReasonML.<p>Maybe the 'data' could be called 'enum'? I believe Rust/Swift ADT definition use keyword 'enum' and it might make it more familiar to the mainstream.<p>While the 'await' is pretty recognizable, the word itself seems to be too coupled with asynchronous operation too much.
I think there’s a good use case for such a thing: make it as compatible with current Rust syntax as possible, including keyword names. This way you’d make use of people’s familiarity with Rust, and give them “lookalike Lang with better types and a GC”.
Honestly the syntax of Haskell is unnecessarily weird and I think this project is proof that it doesn't have to be. Haskell's syntax has really put me off learning it. I'd even say some parts of the syntax are elitist - they are almost deliberately - and unnecessarily! - hard for beginners but great if you are a language nerd and understand currying, lambda calculus and so on.<p>This is way better, but to be honest I don't think I'll use it because the extra easiness of learning with a sane syntax is probably going to be not worth the extra hassle caused by not learning the syntax that everyone else uses.<p>Still, great job! Now do the git CLI. :-)
Without OO as main paradigm, and without being shoehorned into the JVM, Haskell has no chance to be mainstream. Stop trying to make it mainstream, it will only remove from Haskell what makes Haskell great.
Huh, this is like saying "who needs parsers?" Well, they've been invented for a reason. So after the NoSQL movement, we now have NoParser. I fear we might end up back at assembly or even microcode. Sure it will make life simpler, but it's the wrong kind of simple.
I'm looking forward to playing with this.<p>Coming from a C-style language background, I've always found the syntax of languages such as Haskell and ML to be alien, to the point that I can't get my head into learning one of them, despite their obvious power and utility.<p>I've been looking for some kind of C-style dialect for one of these languages for a long time, so thank you very much for creating this.<p>At the risk of hijacking this thread; is anyone here aware of other projects for Haskell or other languages that achieve a similar goal?