4 ms·
There is a problem. I know no other language, which manages to have at the same a type system as powerful, abstractions as insightful, as good a support for con
by nikita-volkov 12y ago
There is a problem. I know no other language, which manages to have at the same a type system as powerful, abstractions as insightful, as good a support for concurrency and parallel programming, an ecosystem as rich and which performs as well.
Usable records are just an icing on the cake, but it's the cake that matters.
- eru 12y agoAnother way to solve this problem, is to allow multiple (nested) modules per file. A bit like OCaml. Then standard Haskell-syntax can already handle everything we need.
- tel 12y agoThis would work but run a bit afoul of global instance canonicity.
- evincarofautumn 12y agoHow so? I think they mean as a syntactic feature, not having parameterised modules.
- tel 12y agoWhat happens if you define an instance inside of a nested module? When does it become available?
- dllthomas 12y agoI'd like to just see a per-project uniqueness check on used instances.
- eru 12y agoYes, just a syntactic feature, as transparent sugar standing in for an extra file. (Though I haven't thought the whole thing through more than that.)
- lmm 12y agoThis article sounds a lot like the way that records are implemented for Scala (in Shapeless), which is a language that meets all your other criteria :P. (Not that there aren't good reasons to use Haskell instead of Scala, but Scala has everything on your list)
- nikita-volkov 12y agoActually Scala is the language I moved to Haskell away from. It turned out to be too messy and bloated for my taste. The syntax and the type inference are massively inferior to Haskell. An absolute majority of Scala's advanced features are just copycatted from Haskell (typeclasses, STM, Scalaz, the majority of the Shapeless library that you mentioned). The promoted usage applies it's object-orientation mostly only to encode a modular system (e.g., the cake pattern). A lot of things are simply impossible to achieve due to Scala not being purely functional. So yes, Scala might have an edge over Haskell here and there, but IMO, as of a person who happens to have an extensive experience in Scala, in general it is majorly inferior compared to Haskell.
- RivieraKid 12y agoCeylon is that language.
- mightybyte 12y agoCeylon's type system is based on Java, so no, it is nowhere near as powerful as Haskell's type system. The above post didn't mention it, but I would add purity to his list. Ceylon doesn't have that either.
- RivieraKid 12y agoIt's not, Ceylon's type system is way better than Java's, it's actually the best type system I've seen in a language. I wouldn't say Haskell's is significantly more powerful, if at all. What I like about Ceylon is that it's pragmatic, it's great for functional, objective and imperative programming. One thing that I disliked about Haskell is that it can be a bit cumbersome to do imperative and side-effect programming (which often the most readable and understandable way to write code).
- mightybyte 12y agoHmmm, perhaps my cursory skim of Wikipedia and the Ceylon site led me to wrong conclusions there. I'll defer a more detailed type system comparison to experts in the field. The big difference I see on my second pass is purity. Purity in Haskell is huge IMO. I would argue that purity makes Haskell's type system more powerful because a function's type allows you to know exactly what kinds of side effects it might have, or more importantly, not have. But I suppose one could debate whether that's a type system thing or not. > can be a bit cumbersome to do imperative and side-effect programming On the contrary, I think Haskell is great for imperative programming. It allows you to operate at higher levels of abstraction and create more abstract imperative constructs than most other languages. If you want to mutate things, there is a small cost to construct IORefs, STRefs, and the like, but I think that's actually a good thing because it correctly incentivizes the reduction of side effects. And again, much of this boilerplate can be gotten rid of. See https://github.com/ekmett/lens/blob/master/examples/Pong.hs#L110 https://github.com/ekmett/lens/blob/master/examples/Pong.hs#... for an example of some really nice imperative code made possible by the lens library.