16 ms·

Reflecting on Haskell in 2017

330 points by setra 9y ago

MBCook 9y ago
> Writing Haskell is almost trivial in practice. You just start with the magic fifty line {-# LANGUAGE ... #-} incantation to fast-forward to 2017, [...] This was my biggest frustration with Haskell the last time I used it, I find it sad that it doesn’t seem like they’re trying to fix it.
- _sdegutis 9y ago
  Yep. Here's an interesting list of extensions as of a couple years ago: https://www.reddit.com/r/haskell/comments/2z248l/language_extensions/ https://www.reddit.com/r/haskell/comments/2z248l/language_ex... ... But that many extensions being pretty much necessary had definitely wore me down and turned me away from Haskell.
  - nerdponx 9y ago
    What's the point of adding "optional" extensions, versus just incorporating them as features in later compiler versions?
    - erik_seaberg 9y ago
      You might want to know which code is relying on an extension that's found to be a Bad Idea(tm) and rolled back or seriously changed.
    - gizmo686 9y ago
      Mostly politics. It is a lot easier to add opt-in features than get consensus to change the language. Opt in extensions also allow you to avoid worrying about the longtail of backwards compatability.
    - aetherspawn 9y ago
      Because sometimes you have to explore a space to figure out if it’s any good. No point arbitrarily adding stuff to the language if it doesn’t turn out to be that useful. That’s how you end up with situations like ‘null’. Some of these extensions are nuts, too. They can make the type system behave in ways where it basically has to multivariate solve or do things that are overly clever. You probably don’t want that most of the time..
    - mrkgnao 9y ago
      Some extensions are considered bad ideas later, e.g. -XImplicitParams. Some extensions can make existing code fail to compile, e.g. -XOverloadedStrings. Some extensions are fairly specialised and their use can cause error messages that are confusing if you don't know what the extension does, e.g. -XAllowAmbiguousTypes. Some extensions can cause certain pathological pieces of code to suddenly start behaving weirdly, e.g. if you turn on -XApplicativeDo for a type whose Applicative instance isn't lawful, but whose Monad instance is. Of course, many, many extensions could be enabled by default without making the UX worse or restricting the set of allowed programs at all: a large section of Haskell users is likely in favour of enabling syntactic conveniences like LambdaCase or MultiWayIf, or automatic code-generation utilities like DeriveFoldable, DeriveTraversable, and so on. That's what Haskell Prime is for, I suppose.
      - marcosdumay 9y ago
        And lets not forget about UndecidableInstances and its ilk, that enable amazing pieces of functionality if used well, but incredibly dangerous if you are not careful
        whateveracct 9y ago
        UndecidableInstances is actually not bad. I turn it on all the time and don't feel scared when I do. Worst-case, I write some bad instances and the compiler fails due to the recursion limit. IncoherentInstances is the one that really has no place since it can make code unsound.
- tathougies 9y ago
  You can set all the flags in your cabal file. How is this not a fix? This is like specifying your compiler version. We have a fairly hefty haskell code base at work, and we never use LANGUAGE pragmas anywhere.
  - tree_of_item 9y ago
    Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) doesn't strike me as a fix. Why are there so many extensions in the first place?
    - MBCook 9y ago
      Honestly this bugs me too. I don’t really see why the community doesn’t just decide the GHC really IS Haskell. I’m aware there are other compilers but basically everyone uses GHC. So all these things that have to be turned on because they’re not “compatible“ with all the other compilers that no one else uses just add complexity for new users (and I suppose current users.)
      - yorwba 9y ago
        But are all those options compatible with each other?
        forkerenok 9y ago
        No, they are not, and some are useless Edit: I guess not useless, but over time rendered as anti-features
        tome 9y ago
        Can you name some extensions that are not compatible with each other. I can't, off the top of my head, and I've been using Haskell for some years. (I don't deny there might be some, but I'm finding it hard to think of any.)
- pjmlp 9y ago
  They were supposed to come out with an update to Haskell 2010, but I think the effort died.
- Tehnix 9y ago
  Haskell prime[0][1] is an effort to consolidate some of these features into "Haskell 2020" - so there is work going on in that regard. Semi-related: I wanted to voice that while it can be tedious to enable extensions, what they do give us is a great way to explore several solution spaces without making the whole ecosystem commit to any in particular. Some become defacto, while some are more controversial and change the actual semantics of the language. The freedom to choose is both a burden and a gift though! [0] https://prime.haskell.org https://prime.haskell.org [1] https://github.com/haskell/rfcs https://github.com/haskell/rfcs
- tome 9y ago
  If that's your biggest frustration then what a language!
- alien_at_work 9y ago
  I disagree with this, I like how it is right now. For certain kinds of code I need things like FlexibleInstances that I absolutely wouldn't want enabled everywhere. As it currently stands in Haskell I can turn it on only in the files that need it and it doesn't leak to the rest of the program. And having them at the top lets me know ahead of time that things I would normally view as syntax errors are in effect for this file. The biggest complaints I see people make about Haskell are language extention lines and imports but for me these are both IDE issues. I'm not aware of many readable languages that end up with lots of imports for any non-trivial code.
harry8 9y ago
I want to see the list of applications written in haskell that are useful and not used for programming a computer. This list has seemed shorter than one might expect in the past given the interest among programmers in the haskell language (this includes my own interest fwiw). A list of applications written in haskell that are used for something that isn't programming a is a useful datapoint that tells us something about the strengths and weaknesses of the language - we can argue about the subtleties of the meaning of that data point but it is useful data. I've got pandoc, xmonad (window manager), git annexe to get things started. Let's get them down.
- baddox 9y ago
  Here’s a list, although it’s marked as obsolete. https://wiki.haskell.org/Haskell_in_practice https://wiki.haskell.org/Haskell_in_practice
  - harry8 9y ago
    34 items on that list. Looking at the content I don't think it's fair to use it as much of a datapoint you'd have to reduce that 34 number down yet it's missing git annexe, xmonad and pandoc which exist and are well used! Also as you point out it notes that it's obsolete. Next to where it notes that the list is obsolete it links here: https://wiki.haskell.org/Libraries_and_tools https://wiki.haskell.org/Libraries_and_tools Which buries applications in libraries and makes it challenging to get the actual list of applications, which is what I want here and is just one useful datapoint (of many). There is definitely a very long list of haskell libraries, many of which are excellent - this is a separate datapoint that can be considered separately or indeed in concert once we have the actual datapoint of the haskell applications that exist, are used and used for something that isn't programming.
- nathell 9y ago
  Darcs?
  - harry8 9y ago
    Yes. Absolutely.
darkkindness 9y ago
As a semi-recent initiate to Haskell, it's really helpful to see such an accessible compilation of important Haskell developments. Although it's easy to find Haskell material to read, it's not as obvious to highlight what's important. Cheers!
- kreetx 9y ago
  For me the main value is getting the interestin publications. This is subjective of course, but way better than a random selection :)
willtim 9y ago
Haskell is definately one to watch for Blockchain. IOHK have released a currency with their codebase largely in Haskell. Both IOHK and Digital Asset have smart contract / modelling languages based on Haskell.
- spopejoy 9y ago
  The author also mentions his company's release Uplink (https://github.com/adjoint-io/uplink https://github.com/adjoint-io/uplink), plus there's the Pact smart contract language (https://github.com/kadena-io/pact https://github.com/kadena-io/pact)
fegu 9y ago
As usual Stephen does a great job. Well worth a thorough read for any Haskell practitioner.
Tehnix 9y ago
For people that have gotten into Haskell, but struggle to get over the intermediate level, I would warmly recommend checking out https://www.fpcomplete.com/haskell-syllabus https://www.fpcomplete.com/haskell-syllabus. As for good tips, I've come to like the ReaderT "design pattern"[0]. For newcomers, I would recommend the Haskell Book[1], which covers everything quite extensively. [0] https://www.fpcomplete.com/blog/2017/06/readert-design-pattern https://www.fpcomplete.com/blog/2017/06/readert-design-patte... [1] http://haskellbook.com http://haskellbook.com
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
haskdev 9y ago
> Not so surprisingly most people have migrated to Stack Justice prevailed despite the futile attempts by the Haskell Committee to prevent Stack becoming popular!
jzb_ 9y ago
The back-end of www.chordify.net has been completely written in Haskell, using cloud-haskell to keep the service scalable.
devit 9y ago
My impression of Haskell is that the main issue is that laziness is simply wrong, since it causes space leaks that are hard to reason about, and seems generally less efficient than eagerness; furthermore, it seems rarely beneficial, so it seems more appropriate to explicitly request laziness rather than the opposite. The next problem is that complete immutability is also wrong, because controlled mutable aliasing with linear types (like the system available in Rust) is what you really want since it's more general, efficient and expressive (allows mutable data structures), and complete immutability is just a special case of controlled mutable aliasing. The third problem of Haskell is the weird syntax, that doesn't follow the common C/Java/JS or Python syntaxes for no good reason, making it hard to read and learn the language. And if one were to change these things in Haskell, the result would essentially be Rust (or more precisely, a future version of Rust once all the missing abstractions like HKT, specialization, etc. are added), so I think that's what one should use instead.
- d3ckard 9y ago
  Totally disagree and as of now I only dabbled in Haskell (though it's first on my to-do list). 1. Immutability works when everything is immutable. Otherwise you're never sure and you lose benefits. 2. Syntax is a non issue. Honestly, I stopped caring a long time ago about how language looks. You get used to it in the first month. 3. Laziness is disputable. While it can be a optimization problem, it also allows for more generic description of ideas.
  - devit 9y ago
    In Rust, if you have an & or Rc/Arc, you know that it's immutable, except for parts contained in Cell/RefCell/Atomic/Mutex. If you have an &mut or owned mut variable, then you know that you can only mutate it through that name. If you have a non-mut owned variable, then you know that only the Cell/RefCell/Atomic/Mutex parts can be mutated, and only through that name. If a Rust program doesn't contain the words "mut", "unsafe", "Cell", "RefCell", "Mutex" or "Atomic[...]", then everything in it is immutable. That gives the same guarantees as Haskell's immutability where desired, but it allows to actually make use of CPU capabilities like writing to memory, and express basic operations like assigning a value to a position in an array. Or in other words, what you really want is a system that lets you mutate something as long as you are the only one with a reference to it, and then make it immutable and give it around, while also allowing you to "get it back" exclusively either with static checks (via lifetimes) or dynamic reference count checks. Haskell's pure immutability system, while safe unlike Java's, is just a very restricted version of such a system, that is not powerful enough to write safe programs that are as efficient as C programs (since you can't modify memory), or express imperative code even when they are safe.
xvilka 9y ago
I wonder, what happened with Luna[1] language project? Seems dead, no updates, no emails on the mailing list I subscribed. [1] https://luna-lang.org https://luna-lang.org
greatNespresso 9y ago
Talking about recent stuff, it looks like Cardano rely on Haskell for their PoS protocol implementation : https://github.com/input-output-hk/cardano-sl https://github.com/input-output-hk/cardano-sl
moocowtruck 9y ago
Facebook Duckling https://github.com/facebook/duckling https://github.com/facebook/duckling rewritten from clojure, used to power smart products at facebook
akinsketch 9y ago
Habito [0], a mortgage broker based in London, has its back end written in Haskell. [0] https://www.habito.com/ https://www.habito.com/
mjhoy 9y ago
I'm particularly excited about the prospect of linear types; not so much for helping with space/GC efficiency (which is good of course) but for modeling state transitions and ensuring that, for instance, some intermediate state must get consumed once and only once. It's one of the bugs I often run into when writing Haskell code.
- kccqzy 9y ago
  The linear type hype is a bit overblown. As one skeptical GHC developer has said, there’s not a single concrete example of how linear types would help real-life code. Haskell already has great facilities to handle state transition; linear types isn’t needed to ensure “some intermediate state must get consumed once and only once.”
  - drb226 9y ago
    "linear types isn’t needed to ensure “some intermediate state must get consumed once and only once.”" If you don't use linear types to ensure this, then you're probably not ensuring it, and it just comes down to "hopefully the programmer eyeballed it correctly and read the docs."
    - kccqzy 9y ago
      More than 20 years ago people solved the token-that-must-be-consumed-once problem with the IO monad. Just a secret token that gets threaded everywhere. The monadic bind is just great syntactic sugar. Also more than 20 years ago people figured out a way to keep separate tokens completely independent and forbid them from interacting with each other. That’s the phantom `s` type variable in ST. Nowadays we have so many more complicated solutions (not all of them worthwhile!) giving you choice how you want to make sure an intermediate state is consumed once. Why not implement a state machine at the type variable using DataKinds, TypeFamilies et al? Or you know, for the case of ensuring file handles/database connections get closed correctly, use monadic regions: http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf http://okmij.org/ftp/Computation/resource-aware-prog/region-... (disclaimer: I haven’t read this paper or used this approach myself but I heard it’s a good technique) But more importantly, even if introducing linear types can make what’s currently barely doable in Haskell easily doable, maybe even replacing five language extensions with one, does it have a good power-to-weight ratio? I’m not convinced. Is the kind of mistakes prevented by this language extension often made by typical Haskell programmers? My answer is no.
js8 9y ago
He writes: "Most large Haskell projects (GHC, Stack, Agda, Cabal, Idris, etc) no longer use Haddock for documentation." So, what do they use? How do I get (I mean, build in stack) my useful documentation? (Actually I appreciate any tips how to build documentation for off-line use.)
- sjakobi 9y ago
  I'm not sure what that statement was based on. The stack project certainly still uses haddock to document its code. At least some of the projects he cites also use readthedocs for user guides etc. > How do I get (I mean, build in stack) my useful documentation? Try stack haddock --open <packagename>
topogios 9y ago
A quick few: The backend, https://github.com/kirel/detexify-hs-backend https://github.com/kirel/detexify-hs-backend, for Detexify, http://detexify.kirelabs.org/classify.html http://detexify.kirelabs.org/classify.html. Parts of BazQux Reader, a commercial feedreader, https://bazqux.com https://bazqux.com Nikki and the Robots, a platformer, https://github.com/nikki-and-the-robots/nikki https://github.com/nikki-and-the-robots/nikki

330 points by setra 9y ago

> Writing Haskell is almost trivial in practice. You just start with the magic fifty line {-# LANGUAGE ... #-} incantation to fast-forward to 2017, [...] This was my biggest frustration with Haskell the last time I used it, I find it sad that it doesn’t seem like they’re trying to fix it.

_sdegutis 9y ago
Yep. Here's an interesting list of extensions as of a couple years ago: https://www.reddit.com/r/haskell/comments/2z248l/language_extensions/ https://www.reddit.com/r/haskell/comments/2z248l/language_ex... ... But that many extensions being pretty much necessary had definitely wore me down and turned me away from Haskell.
- nerdponx 9y ago
  What's the point of adding "optional" extensions, versus just incorporating them as features in later compiler versions?
  - erik_seaberg 9y ago
    You might want to know which code is relying on an extension that's found to be a Bad Idea(tm) and rolled back or seriously changed.
  - gizmo686 9y ago
    Mostly politics. It is a lot easier to add opt-in features than get consensus to change the language. Opt in extensions also allow you to avoid worrying about the longtail of backwards compatability.
  - aetherspawn 9y ago
    Because sometimes you have to explore a space to figure out if it’s any good. No point arbitrarily adding stuff to the language if it doesn’t turn out to be that useful. That’s how you end up with situations like ‘null’. Some of these extensions are nuts, too. They can make the type system behave in ways where it basically has to multivariate solve or do things that are overly clever. You probably don’t want that most of the time..
  - mrkgnao 9y ago
    Some extensions are considered bad ideas later, e.g. -XImplicitParams. Some extensions can make existing code fail to compile, e.g. -XOverloadedStrings. Some extensions are fairly specialised and their use can cause error messages that are confusing if you don't know what the extension does, e.g. -XAllowAmbiguousTypes. Some extensions can cause certain pathological pieces of code to suddenly start behaving weirdly, e.g. if you turn on -XApplicativeDo for a type whose Applicative instance isn't lawful, but whose Monad instance is. Of course, many, many extensions could be enabled by default without making the UX worse or restricting the set of allowed programs at all: a large section of Haskell users is likely in favour of enabling syntactic conveniences like LambdaCase or MultiWayIf, or automatic code-generation utilities like DeriveFoldable, DeriveTraversable, and so on. That's what Haskell Prime is for, I suppose.
    - marcosdumay 9y ago
      And lets not forget about UndecidableInstances and its ilk, that enable amazing pieces of functionality if used well, but incredibly dangerous if you are not careful
      - whateveracct 9y ago
        UndecidableInstances is actually not bad. I turn it on all the time and don't feel scared when I do. Worst-case, I write some bad instances and the compiler fails due to the recursion limit. IncoherentInstances is the one that really has no place since it can make code unsound.
tathougies 9y ago
You can set all the flags in your cabal file. How is this not a fix? This is like specifying your compiler version. We have a fairly hefty haskell code base at work, and we never use LANGUAGE pragmas anywhere.
- tree_of_item 9y ago
  Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) doesn't strike me as a fix. Why are there so many extensions in the first place?
  - MBCook 9y ago
    Honestly this bugs me too. I don’t really see why the community doesn’t just decide the GHC really IS Haskell. I’m aware there are other compilers but basically everyone uses GHC. So all these things that have to be turned on because they’re not “compatible“ with all the other compilers that no one else uses just add complexity for new users (and I suppose current users.)
    - yorwba 9y ago
      But are all those options compatible with each other?
      - forkerenok 9y ago
        No, they are not, and some are useless Edit: I guess not useless, but over time rendered as anti-features
        tome 9y ago
        Can you name some extensions that are not compatible with each other. I can't, off the top of my head, and I've been using Haskell for some years. (I don't deny there might be some, but I'm finding it hard to think of any.)
pjmlp 9y ago
They were supposed to come out with an update to Haskell 2010, but I think the effort died.
Tehnix 9y ago
Haskell prime[0][1] is an effort to consolidate some of these features into "Haskell 2020" - so there is work going on in that regard. Semi-related: I wanted to voice that while it can be tedious to enable extensions, what they do give us is a great way to explore several solution spaces without making the whole ecosystem commit to any in particular. Some become defacto, while some are more controversial and change the actual semantics of the language. The freedom to choose is both a burden and a gift though! [0] https://prime.haskell.org https://prime.haskell.org [1] https://github.com/haskell/rfcs https://github.com/haskell/rfcs
tome 9y ago
If that's your biggest frustration then what a language!
alien_at_work 9y ago
I disagree with this, I like how it is right now. For certain kinds of code I need things like FlexibleInstances that I absolutely wouldn't want enabled everywhere. As it currently stands in Haskell I can turn it on only in the files that need it and it doesn't leak to the rest of the program. And having them at the top lets me know ahead of time that things I would normally view as syntax errors are in effect for this file. The biggest complaints I see people make about Haskell are language extention lines and imports but for me these are both IDE issues. I'm not aware of many readable languages that end up with lots of imports for any non-trivial code.

harry8 9y ago

I want to see the list of applications written in haskell that are useful and not used for programming a computer. This list has seemed shorter than one might expect in the past given the interest among programmers in the haskell language (this includes my own interest fwiw). A list of applications written in haskell that are used for something that isn't programming a is a useful datapoint that tells us something about the strengths and weaknesses of the language - we can argue about the subtleties of the meaning of that data point but it is useful data. I've got pandoc, xmonad (window manager), git annexe to get things started. Let's get them down.

baddox 9y ago
Here’s a list, although it’s marked as obsolete. https://wiki.haskell.org/Haskell_in_practice https://wiki.haskell.org/Haskell_in_practice
- harry8 9y ago
  34 items on that list. Looking at the content I don't think it's fair to use it as much of a datapoint you'd have to reduce that 34 number down yet it's missing git annexe, xmonad and pandoc which exist and are well used! Also as you point out it notes that it's obsolete. Next to where it notes that the list is obsolete it links here: https://wiki.haskell.org/Libraries_and_tools https://wiki.haskell.org/Libraries_and_tools Which buries applications in libraries and makes it challenging to get the actual list of applications, which is what I want here and is just one useful datapoint (of many). There is definitely a very long list of haskell libraries, many of which are excellent - this is a separate datapoint that can be considered separately or indeed in concert once we have the actual datapoint of the haskell applications that exist, are used and used for something that isn't programming.
nathell 9y ago
Darcs?
- harry8 9y ago
  Yes. Absolutely.

darkkindness 9y ago

As a semi-recent initiate to Haskell, it's really helpful to see such an accessible compilation of important Haskell developments. Although it's easy to find Haskell material to read, it's not as obvious to highlight what's important. Cheers!

kreetx 9y ago
For me the main value is getting the interestin publications. This is subjective of course, but way better than a random selection :)

willtim 9y ago

Haskell is definately one to watch for Blockchain. IOHK have released a currency with their codebase largely in Haskell. Both IOHK and Digital Asset have smart contract / modelling languages based on Haskell.

spopejoy 9y ago
The author also mentions his company's release Uplink (https://github.com/adjoint-io/uplink https://github.com/adjoint-io/uplink), plus there's the Pact smart contract language (https://github.com/kadena-io/pact https://github.com/kadena-io/pact)

fegu 9y ago

As usual Stephen does a great job. Well worth a thorough read for any Haskell practitioner.

Tehnix 9y ago

For people that have gotten into Haskell, but struggle to get over the intermediate level, I would warmly recommend checking out https://www.fpcomplete.com/haskell-syllabus https://www.fpcomplete.com/haskell-syllabus. As for good tips, I've come to like the ReaderT "design pattern"[0]. For newcomers, I would recommend the Haskell Book[1], which covers everything quite extensively. [0] https://www.fpcomplete.com/blog/2017/06/readert-design-pattern https://www.fpcomplete.com/blog/2017/06/readert-design-patte... [1] http://haskellbook.com http://haskellbook.com

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

haskdev 9y ago

> Not so surprisingly most people have migrated to Stack Justice prevailed despite the futile attempts by the Haskell Committee to prevent Stack becoming popular!

jzb_ 9y ago

The back-end of www.chordify.net has been completely written in Haskell, using cloud-haskell to keep the service scalable.

devit 9y ago

My impression of Haskell is that the main issue is that laziness is simply wrong, since it causes space leaks that are hard to reason about, and seems generally less efficient than eagerness; furthermore, it seems rarely beneficial, so it seems more appropriate to explicitly request laziness rather than the opposite. The next problem is that complete immutability is also wrong, because controlled mutable aliasing with linear types (like the system available in Rust) is what you really want since it's more general, efficient and expressive (allows mutable data structures), and complete immutability is just a special case of controlled mutable aliasing. The third problem of Haskell is the weird syntax, that doesn't follow the common C/Java/JS or Python syntaxes for no good reason, making it hard to read and learn the language. And if one were to change these things in Haskell, the result would essentially be Rust (or more precisely, a future version of Rust once all the missing abstractions like HKT, specialization, etc. are added), so I think that's what one should use instead.

d3ckard 9y ago
Totally disagree and as of now I only dabbled in Haskell (though it's first on my to-do list). 1. Immutability works when everything is immutable. Otherwise you're never sure and you lose benefits. 2. Syntax is a non issue. Honestly, I stopped caring a long time ago about how language looks. You get used to it in the first month. 3. Laziness is disputable. While it can be a optimization problem, it also allows for more generic description of ideas.
- devit 9y ago
  In Rust, if you have an & or Rc/Arc, you know that it's immutable, except for parts contained in Cell/RefCell/Atomic/Mutex. If you have an &mut or owned mut variable, then you know that you can only mutate it through that name. If you have a non-mut owned variable, then you know that only the Cell/RefCell/Atomic/Mutex parts can be mutated, and only through that name. If a Rust program doesn't contain the words "mut", "unsafe", "Cell", "RefCell", "Mutex" or "Atomic[...]", then everything in it is immutable. That gives the same guarantees as Haskell's immutability where desired, but it allows to actually make use of CPU capabilities like writing to memory, and express basic operations like assigning a value to a position in an array. Or in other words, what you really want is a system that lets you mutate something as long as you are the only one with a reference to it, and then make it immutable and give it around, while also allowing you to "get it back" exclusively either with static checks (via lifetimes) or dynamic reference count checks. Haskell's pure immutability system, while safe unlike Java's, is just a very restricted version of such a system, that is not powerful enough to write safe programs that are as efficient as C programs (since you can't modify memory), or express imperative code even when they are safe.

xvilka 9y ago

I wonder, what happened with Luna[1] language project? Seems dead, no updates, no emails on the mailing list I subscribed. [1] https://luna-lang.org https://luna-lang.org

greatNespresso 9y ago

Talking about recent stuff, it looks like Cardano rely on Haskell for their PoS protocol implementation : https://github.com/input-output-hk/cardano-sl https://github.com/input-output-hk/cardano-sl

moocowtruck 9y ago

Facebook Duckling https://github.com/facebook/duckling https://github.com/facebook/duckling rewritten from clojure, used to power smart products at facebook

akinsketch 9y ago

Habito [0], a mortgage broker based in London, has its back end written in Haskell. [0] https://www.habito.com/ https://www.habito.com/

mjhoy 9y ago

I'm particularly excited about the prospect of linear types; not so much for helping with space/GC efficiency (which is good of course) but for modeling state transitions and ensuring that, for instance, some intermediate state must get consumed once and only once. It's one of the bugs I often run into when writing Haskell code.

kccqzy 9y ago
The linear type hype is a bit overblown. As one skeptical GHC developer has said, there’s not a single concrete example of how linear types would help real-life code. Haskell already has great facilities to handle state transition; linear types isn’t needed to ensure “some intermediate state must get consumed once and only once.”
- drb226 9y ago
  "linear types isn’t needed to ensure “some intermediate state must get consumed once and only once.”" If you don't use linear types to ensure this, then you're probably not ensuring it, and it just comes down to "hopefully the programmer eyeballed it correctly and read the docs."
  - kccqzy 9y ago
    More than 20 years ago people solved the token-that-must-be-consumed-once problem with the IO monad. Just a secret token that gets threaded everywhere. The monadic bind is just great syntactic sugar. Also more than 20 years ago people figured out a way to keep separate tokens completely independent and forbid them from interacting with each other. That’s the phantom `s` type variable in ST. Nowadays we have so many more complicated solutions (not all of them worthwhile!) giving you choice how you want to make sure an intermediate state is consumed once. Why not implement a state machine at the type variable using DataKinds, TypeFamilies et al? Or you know, for the case of ensuring file handles/database connections get closed correctly, use monadic regions: http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf http://okmij.org/ftp/Computation/resource-aware-prog/region-... (disclaimer: I haven’t read this paper or used this approach myself but I heard it’s a good technique) But more importantly, even if introducing linear types can make what’s currently barely doable in Haskell easily doable, maybe even replacing five language extensions with one, does it have a good power-to-weight ratio? I’m not convinced. Is the kind of mistakes prevented by this language extension often made by typical Haskell programmers? My answer is no.

js8 9y ago

He writes: "Most large Haskell projects (GHC, Stack, Agda, Cabal, Idris, etc) no longer use Haddock for documentation." So, what do they use? How do I get (I mean, build in stack) my useful documentation? (Actually I appreciate any tips how to build documentation for off-line use.)

sjakobi 9y ago
I'm not sure what that statement was based on. The stack project certainly still uses haddock to document its code. At least some of the projects he cites also use readthedocs for user guides etc. > How do I get (I mean, build in stack) my useful documentation? Try stack haddock --open <packagename>

topogios 9y ago

A quick few: The backend, https://github.com/kirel/detexify-hs-backend https://github.com/kirel/detexify-hs-backend, for Detexify, http://detexify.kirelabs.org/classify.html http://detexify.kirelabs.org/classify.html. Parts of BazQux Reader, a commercial feedreader, https://bazqux.com https://bazqux.com Nikki and the Robots, a platformer, https://github.com/nikki-and-the-robots/nikki https://github.com/nikki-and-the-robots/nikki