7 ms·

I think I have a radical idea: use a language which solves this problem by design from the beginning. Much simpler.

by pekk 12y ago

cbd1984 12y ago
> use a language which solves this problem by design from the beginning Now you either give up everything else Haskell gives you, or you've created a new language. Do you see how both of those solutions are problems in and of themselves?
- na85 12y ago
  You're presupposing that Haskell is an objectively superior language.
  - cbd1984 12y ago
    > You're presupposing that Haskell is an objectively superior language. No, I'm presupposing that Haskell brings useful things to the table.
  - grayclhn 12y ago
    No, subjectively superior is enough.
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 ago
  Another 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 ago
    This would work but run a bit afoul of global instance canonicity.
    - evincarofautumn 12y ago
      How so? I think they mean as a syntactic feature, not having parameterised modules.
      - tel 12y ago
        What happens if you define an instance inside of a nested module? When does it become available?
        dllthomas 12y ago
        I'd like to just see a per-project uniqueness check on used instances.
      - eru 12y ago
        Yes, 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 ago
  This 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 ago
    Actually 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 ago
  Ceylon is that language.
  - mightybyte 12y ago
    Ceylon'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 ago
      It'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 ago
        Hmmm, 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.
mercurial 12y ago
While the annoyances are real, they are just that: annoyances. If you change language every time a syntactic feature (or lack thereof) irks you, you're never going to get anything done.
- pvdebbe 12y ago
  ...until you change to a lisp.
  - coldtea 12y ago
    In which case you still aren't going to get anything done, but for other reasons (lack of libs, playing with the language instead of doing anything productive, advocating for Lisp instead of doing anything productive, etc).
    - codygman 12y ago
      This can be true, but with discipline you can use superior technologies that may not quite be as popular as Java/C/Javascript/PHP but have all the libs needed for your use case.
    - mercurial 12y ago
      It's not like having your own homegrown dialect of non-idiomatic code is a good thing anyway. On the other hand, the linked library looks more like a working proof of concept for a solution to a longstanding problem, with the goal of eventually merging it into the language.
    - dkarapetyan 12y ago
      What makes you think this is not what happens in other languages? A recent article made a pretty good case for Perl being the most productive language ever but I don't see people ditching their current favorite language for Perl.
      - coldtea 12y ago
        >What makes you think this is not what happens in other languages? Of course it happens in other languages. But I'm certain of two things, a strong predicate and a less strong one: 1) A thing X that happens in all/most languages, doesn't happen to the same deegree in all of them. Of this, I'm 100% certain. 2) Playing with/melding the language instead of being really productive tends to happen in Lisp a lot more (this is a personal observation, based on 1). >A recent article made a pretty good case for Perl being the most productive language ever but I don't see people ditching their current favorite language for Perl. For that to happen (a) the article would have to be correct (b) easy for people to verify that it is so, (c) people should have the tendecy to migrate to what's more productive (instead of what they like, are used to etc). So I don't think the fact that "people don't migrate to Perl" despite "an article about Perl being the most productive language being published" means anything with regards to whether Lisp programmers tend to be non-productive in the real world.
chriswarbo 12y ago
> I think I have a radical idea: use a language which solves this problem by design from the beginning. Much simpler. I completely disagree. It's much simpler to use a language with a few simple, powerful constructs, which can be used to build everything else as libraries.

I think I have a radical idea: use a language which solves this problem by design from the beginning. Much simpler.

by pekk 12y ago

I think I have a radical idea: use a language which solves this problem by design from the beginning. Much simpler.

cbd1984 12y ago

> use a language which solves this problem by design from the beginning Now you either give up everything else Haskell gives you, or you've created a new language. Do you see how both of those solutions are problems in and of themselves?

na85 12y ago
You're presupposing that Haskell is an objectively superior language.
- cbd1984 12y ago
  > You're presupposing that Haskell is an objectively superior language. No, I'm presupposing that Haskell brings useful things to the table.
- grayclhn 12y ago
  No, subjectively superior is enough.

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 ago
Another 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 ago
  This would work but run a bit afoul of global instance canonicity.
  - evincarofautumn 12y ago
    How so? I think they mean as a syntactic feature, not having parameterised modules.
    - tel 12y ago
      What happens if you define an instance inside of a nested module? When does it become available?
      - dllthomas 12y ago
        I'd like to just see a per-project uniqueness check on used instances.
    - eru 12y ago
      Yes, 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 ago
This 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 ago
  Actually 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 ago
Ceylon is that language.
- mightybyte 12y ago
  Ceylon'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 ago
    It'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 ago
      Hmmm, 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.

mercurial 12y ago

While the annoyances are real, they are just that: annoyances. If you change language every time a syntactic feature (or lack thereof) irks you, you're never going to get anything done.

pvdebbe 12y ago
...until you change to a lisp.
- coldtea 12y ago
  In which case you still aren't going to get anything done, but for other reasons (lack of libs, playing with the language instead of doing anything productive, advocating for Lisp instead of doing anything productive, etc).
  - codygman 12y ago
    This can be true, but with discipline you can use superior technologies that may not quite be as popular as Java/C/Javascript/PHP but have all the libs needed for your use case.
  - mercurial 12y ago
    It's not like having your own homegrown dialect of non-idiomatic code is a good thing anyway. On the other hand, the linked library looks more like a working proof of concept for a solution to a longstanding problem, with the goal of eventually merging it into the language.
  - dkarapetyan 12y ago
    What makes you think this is not what happens in other languages? A recent article made a pretty good case for Perl being the most productive language ever but I don't see people ditching their current favorite language for Perl.
    - coldtea 12y ago
      >What makes you think this is not what happens in other languages? Of course it happens in other languages. But I'm certain of two things, a strong predicate and a less strong one: 1) A thing X that happens in all/most languages, doesn't happen to the same deegree in all of them. Of this, I'm 100% certain. 2) Playing with/melding the language instead of being really productive tends to happen in Lisp a lot more (this is a personal observation, based on 1). >A recent article made a pretty good case for Perl being the most productive language ever but I don't see people ditching their current favorite language for Perl. For that to happen (a) the article would have to be correct (b) easy for people to verify that it is so, (c) people should have the tendecy to migrate to what's more productive (instead of what they like, are used to etc). So I don't think the fact that "people don't migrate to Perl" despite "an article about Perl being the most productive language being published" means anything with regards to whether Lisp programmers tend to be non-productive in the real world.

chriswarbo 12y ago

> I think I have a radical idea: use a language which solves this problem by design from the beginning. Much simpler. I completely disagree. It's much simpler to use a language with a few simple, powerful constructs, which can be used to build everything else as libraries.