5 ms·

Isn't the best course of action to rewrite popular components in Haskell, and show that its better? I'm thinking httpd/nginx/jetty, redis/memcached, postgres, a

Isn't the best course of action to rewrite popular components in Haskell, and show that its better? I'm thinking httpd/nginx/jetty, redis/memcached, postgres, and so on. You could even make a text editor. Or a kernel. Or anything, really. I really like functional programming, but Haskell turns me off and without at least one major example of a beautiful, popular solution written in Haskell (and I don't think pandoc counts), I'm not going to make the effort to push through that barrier. Other languages that occupy a similar space ("superior but tragically underused") have these examples. Erlang has...well a lot but Matrix and RabbitMQ come to mind. Clojure has...well it has datomic, but also Jepsen uses it, and heck I've used it and its fine. The real question is, who's fingers itch to write haskell, and can you please pay them $400k to rewrite nginx in it?

dudul 6y ago
So if erlang and clojure are superior but tragically underused in spite of having some big projects/tools to show, how is it helpful for haskell to try to have one as well?
- javajosh 6y ago
  First, I've made no pretense about speaking for Haskell's interests, I am speaking strictly about my own wishes. While I think our interests are aligned, I'll let you be the judge. What would be good for me as a curious developer interested in the language, and who has had a years-long low-level FOMO about it, I would like to be able to wade in and do something with it, like I did with Clojure and Erlang, confident that I could, in the end, make it do stuff (since others had already made it do stuff, first). I do really honestly believe that Haskell needs a "paragon project" like Matrix or Jepsen that has proven itself useful to the world without respect to its Haskellness, and then show that this solution was much easier in Haskell. I keep getting down-voted on this thread, and I expect it to continue. Friends thought I was nuts to give up on Lost after season 1, or The Hobbit after movie 1, or the GoT books after book 3. After years of hearing much talk and seeing no walk, I'm giving up on Haskell. More than that, I'm going to call out anyone talking it up to give specifics because literally everyone I've every spoken to about it gives it a very high regard, but have never, ever written a line of it.
  - alisonkisk 6y ago
    > literally everyone I've every spoken to about it gives it a very high regard, but have never, ever written a line of it. It's fine to make silly hyperbolic statements in a language war, but when you are trying to present yourself as the voice of reason.
- reikonomusha 6y ago
  I think I understand the sentiment of the above commenter. I feel it with Lisp too. There are amazing claims about how Haskell (or Lisp or Erlang or ...) give you these amazing superpowers and allow you to write immensely more correct programs immensely faster. That could be true (and I personally do believe it’s true). But then where are all of these immensely-correct fast-written programs? I don’t buy the pg-inspired secret-weapon lurking-in-the-shadows argument unfortunately. In C, C++, Java, and Python—even Pascal!—it’s not even funny how many examples there are. It’s nearly limitless. The superpower languages struggle to come up with just a handful of examples. What I personally observe in the Lisp and Haskell world is that people like to write purportedly useful “reusable” libraries, and nobody likes to write applications. A very select few are successful at these libraries (where success = broad adoption), but most of these libraries are intellectual games and puzzles that benefit almost zero “working programmers”. Lisp has plenty of libraries to do pattern matching (great!) but basically zero for putting up a native GUI. (As a self-deprecating anecdote, my first instinct writing Haskell many moons ago was to create a library of all of the major abstract algebraic structures found in pure math. You can imagine how many people that library would benefit.) A lot of this also has to do with not the language, but the tribal nature of programmers and their acceptance of other tools in their chain. The Linux kernel will never accept a patch written in Common Lisp, and a lousy middle manager will never let you write your domain logic in Prolog. Nobody wants to figure out how to integrate GHC into their CI/CD. Most people have little patience to figure out how to write good C code that integrates with Erlang’s FFI. I’m being a little flippant in my description of the state of affairs, but I think the spirit of it is correct. I think the commenter is right. If any of these languages will be successful, there have to be many, many successful programs written in said language where the language’s benefits tangibly pay off. Having one or two Hail Mary projects doesn’t really mean anything.
  - tome 6y ago
    Well, yes, to become popular a language has to become popular. It's a tricky knot to cut, but we're working on it.
    - reikonomusha 6y ago
ragnese 6y ago
Why doesn't pandoc count?
- bachmeier 6y ago
  I'm not OP but I have only a basic knowledge of Haskell, and after giving it my best effort, I wrote my own parser rather than modifying Pandoc. If Pandoc didn't sell me (user of many languages over many years, a true believer in functional programming, and someone that writes solo projects for personal use) on Haskell, I don't think it can be done. The Pandoc source is literally just a big blob of uncommented gibberish to someone that's not already a dedicated Haskell programmer.
Athas 6y ago
PostgREST is written in Haskell and quite popular: https://postgrest.org/en/v7.0.0/ https://postgrest.org/en/v7.0.0/ Shellcheck has become a very important tool to many people writing shell scripts: https://github.com/koalaman/shellcheck https://github.com/koalaman/shellcheck GitHub's semantic analysis is written in Haskell: https://github.com/github/semantic https://github.com/github/semantic I'm not sure why Pandoc doesn't count. I think it is definitely the case that most examples of successful Haskell are technical programs of interest to hackers. I don't think that's much of a problem myself.
- ragnese 6y ago
  I think the key issue is not that successful Haskell programs are technical. I think it's that Haskell is not good for heavy-IO programs. I'm not sure how PostgREST works, but shellcheck and pandoc, for example, are really well suited for "IO on the edges" style: you feed bytes in once, and then at the very end you spit some other bytes out. Everything in the middle is parsing and transforming data. If you're writing some boring CRUD app, or a GUI program that makes a bunch of syscalls, Haskell sounds like a giant pain in the ass. From that POV, I think that Haskell's relative lack of popularity is perfectly fine. Not every language has to be maximally general.
  - nightski 6y ago
    I used to write a lot of Haskell and tbh I find the idea of restricting IO to the edges of an application to be equally as important in traditional imperative programming languages as well. It's just good design, not a PITA. It seems to be a common view point that Haskell makes IO difficult. I actually personally found that it was more powerful because I was being more explicit about it. It also allowed for higher ordered functions to abstract common patterns in IO. The only difficulty in Haskell was not due to monads or type safety, but rather in getting my brain to understand lazy evaluation by default.
    - ragnese 6y ago
      I agree that keeping IO sequestered is generally good advice. And it's something that I also do in imperative and OO languages as a rule of thumb. But having the type system signalling at IO is happening doesn't end up being useful in non-lazy languages where purity doesn't actually help an optimizer. I found this blog post to be kind of interesting: https://blog.ploeh.dk/2017/02/02/dependency-rejection/ https://blog.ploeh.dk/2017/02/02/dependency-rejection/ Skim that and then take a look at the back-and-forth in the comments. Sometimes going out of your way to write mostly pure (or just non-IO) functions can make your code more difficult to reason about. In my experience, you're sometimes left with two choices: either do a bunch of IO upfront that you might end up throwing away (if there is an `if` statement in your pure function that determines whether you need the result of some IO op), or pull out logic into the naughty impure edge of your program. If you do the former, you're wasting performance. If you do the latter, you're not actually fixing anything that pure functions are supposed to help you with, because you still have logic in impure functions. In my experience there are these edge cases where finding the cutoff between "the edge where I'm allowed to do IO" and the "pure business logic" is not that clear or easy. Also, as the old saying goes: monads don't compose well.
miltondts 6y ago
"show that its better" I've being thinking a lot about this, and I think this is better addressed by using the same standards as in other fields. Namely, a scientific study. I imagine an environment like repl.it, with just a simple text editor, and some problem description and a set of compressive tests that serve as a spec. Then we measure time to produce a solution and number times the solution makes the tests fail (bugs). With enough people doing this, and in enough languages, we might be able to reach some conclusions. Until then, we will be stuck in the dark.
- Youden 6y ago
  There was a study done by Yale/US Navy/DARPA back in the 90s [0] but it was much more limited than you're describing. [0]: https://www.cs.yale.edu/publications/techreports/tr1049.pdf https://www.cs.yale.edu/publications/techreports/tr1049.pdf
_query 6y ago
We build an amazing web framework called IHP with haskell, imagine the productiveness of rails combined with the typesafety of haskell: https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/ IHP has around 230 monthly active projects at the moment, and it's growing fast. It was released 8 months ago and now is already the second biggest haskell web framework :) I think haskell has been previously tragically underused because it was missing good documentation and pragmatic solutions that help you to get things done. Atleast in the web dev space this has changed this year. Watch our IHP demo video and you'll get it: https://www.youtube.com/watch?v=UbDtS_mUMpI https://www.youtube.com/watch?v=UbDtS_mUMpI Disclaimer: Founder of digitally induced, the company that makes IHP.
dragonwriter 6y ago
> Isn't the best course of action to rewrite popular components in Haskell, and show that its bette No, the best course of action is to solve problems that haven't been solved, not to do marginal reinventions of the wheel. A killer solution is definitely a help in getting a language ecosystem to take off, but those are rarely simple reimplementation of an existing tool. Occasionally they are in a recognizable existing category, sometimes they are category-defining.

dudul 6y ago

So if erlang and clojure are superior but tragically underused in spite of having some big projects/tools to show, how is it helpful for haskell to try to have one as well?

javajosh 6y ago
First, I've made no pretense about speaking for Haskell's interests, I am speaking strictly about my own wishes. While I think our interests are aligned, I'll let you be the judge. What would be good for me as a curious developer interested in the language, and who has had a years-long low-level FOMO about it, I would like to be able to wade in and do something with it, like I did with Clojure and Erlang, confident that I could, in the end, make it do stuff (since others had already made it do stuff, first). I do really honestly believe that Haskell needs a "paragon project" like Matrix or Jepsen that has proven itself useful to the world without respect to its Haskellness, and then show that this solution was much easier in Haskell. I keep getting down-voted on this thread, and I expect it to continue. Friends thought I was nuts to give up on Lost after season 1, or The Hobbit after movie 1, or the GoT books after book 3. After years of hearing much talk and seeing no walk, I'm giving up on Haskell. More than that, I'm going to call out anyone talking it up to give specifics because literally everyone I've every spoken to about it gives it a very high regard, but have never, ever written a line of it.
- alisonkisk 6y ago
  > literally everyone I've every spoken to about it gives it a very high regard, but have never, ever written a line of it. It's fine to make silly hyperbolic statements in a language war, but when you are trying to present yourself as the voice of reason.
reikonomusha 6y ago
I think I understand the sentiment of the above commenter. I feel it with Lisp too. There are amazing claims about how Haskell (or Lisp or Erlang or ...) give you these amazing superpowers and allow you to write immensely more correct programs immensely faster. That could be true (and I personally do believe it’s true). But then where are all of these immensely-correct fast-written programs? I don’t buy the pg-inspired secret-weapon lurking-in-the-shadows argument unfortunately. In C, C++, Java, and Python—even Pascal!—it’s not even funny how many examples there are. It’s nearly limitless. The superpower languages struggle to come up with just a handful of examples. What I personally observe in the Lisp and Haskell world is that people like to write purportedly useful “reusable” libraries, and nobody likes to write applications. A very select few are successful at these libraries (where success = broad adoption), but most of these libraries are intellectual games and puzzles that benefit almost zero “working programmers”. Lisp has plenty of libraries to do pattern matching (great!) but basically zero for putting up a native GUI. (As a self-deprecating anecdote, my first instinct writing Haskell many moons ago was to create a library of all of the major abstract algebraic structures found in pure math. You can imagine how many people that library would benefit.) A lot of this also has to do with not the language, but the tribal nature of programmers and their acceptance of other tools in their chain. The Linux kernel will never accept a patch written in Common Lisp, and a lousy middle manager will never let you write your domain logic in Prolog. Nobody wants to figure out how to integrate GHC into their CI/CD. Most people have little patience to figure out how to write good C code that integrates with Erlang’s FFI. I’m being a little flippant in my description of the state of affairs, but I think the spirit of it is correct. I think the commenter is right. If any of these languages will be successful, there have to be many, many successful programs written in said language where the language’s benefits tangibly pay off. Having one or two Hail Mary projects doesn’t really mean anything.
- tome 6y ago
  Well, yes, to become popular a language has to become popular. It's a tricky knot to cut, but we're working on it.
  - reikonomusha 6y ago

ragnese 6y ago

Why doesn't pandoc count?

bachmeier 6y ago
I'm not OP but I have only a basic knowledge of Haskell, and after giving it my best effort, I wrote my own parser rather than modifying Pandoc. If Pandoc didn't sell me (user of many languages over many years, a true believer in functional programming, and someone that writes solo projects for personal use) on Haskell, I don't think it can be done. The Pandoc source is literally just a big blob of uncommented gibberish to someone that's not already a dedicated Haskell programmer.

Athas 6y ago

PostgREST is written in Haskell and quite popular: https://postgrest.org/en/v7.0.0/ https://postgrest.org/en/v7.0.0/ Shellcheck has become a very important tool to many people writing shell scripts: https://github.com/koalaman/shellcheck https://github.com/koalaman/shellcheck GitHub's semantic analysis is written in Haskell: https://github.com/github/semantic https://github.com/github/semantic I'm not sure why Pandoc doesn't count. I think it is definitely the case that most examples of successful Haskell are technical programs of interest to hackers. I don't think that's much of a problem myself.

ragnese 6y ago
I think the key issue is not that successful Haskell programs are technical. I think it's that Haskell is not good for heavy-IO programs. I'm not sure how PostgREST works, but shellcheck and pandoc, for example, are really well suited for "IO on the edges" style: you feed bytes in once, and then at the very end you spit some other bytes out. Everything in the middle is parsing and transforming data. If you're writing some boring CRUD app, or a GUI program that makes a bunch of syscalls, Haskell sounds like a giant pain in the ass. From that POV, I think that Haskell's relative lack of popularity is perfectly fine. Not every language has to be maximally general.
- nightski 6y ago
  I used to write a lot of Haskell and tbh I find the idea of restricting IO to the edges of an application to be equally as important in traditional imperative programming languages as well. It's just good design, not a PITA. It seems to be a common view point that Haskell makes IO difficult. I actually personally found that it was more powerful because I was being more explicit about it. It also allowed for higher ordered functions to abstract common patterns in IO. The only difficulty in Haskell was not due to monads or type safety, but rather in getting my brain to understand lazy evaluation by default.
  - ragnese 6y ago
    I agree that keeping IO sequestered is generally good advice. And it's something that I also do in imperative and OO languages as a rule of thumb. But having the type system signalling at IO is happening doesn't end up being useful in non-lazy languages where purity doesn't actually help an optimizer. I found this blog post to be kind of interesting: https://blog.ploeh.dk/2017/02/02/dependency-rejection/ https://blog.ploeh.dk/2017/02/02/dependency-rejection/ Skim that and then take a look at the back-and-forth in the comments. Sometimes going out of your way to write mostly pure (or just non-IO) functions can make your code more difficult to reason about. In my experience, you're sometimes left with two choices: either do a bunch of IO upfront that you might end up throwing away (if there is an `if` statement in your pure function that determines whether you need the result of some IO op), or pull out logic into the naughty impure edge of your program. If you do the former, you're wasting performance. If you do the latter, you're not actually fixing anything that pure functions are supposed to help you with, because you still have logic in impure functions. In my experience there are these edge cases where finding the cutoff between "the edge where I'm allowed to do IO" and the "pure business logic" is not that clear or easy. Also, as the old saying goes: monads don't compose well.

miltondts 6y ago

"show that its better" I've being thinking a lot about this, and I think this is better addressed by using the same standards as in other fields. Namely, a scientific study. I imagine an environment like repl.it, with just a simple text editor, and some problem description and a set of compressive tests that serve as a spec. Then we measure time to produce a solution and number times the solution makes the tests fail (bugs). With enough people doing this, and in enough languages, we might be able to reach some conclusions. Until then, we will be stuck in the dark.

Youden 6y ago
There was a study done by Yale/US Navy/DARPA back in the 90s [0] but it was much more limited than you're describing. [0]: https://www.cs.yale.edu/publications/techreports/tr1049.pdf https://www.cs.yale.edu/publications/techreports/tr1049.pdf

_query 6y ago

We build an amazing web framework called IHP with haskell, imagine the productiveness of rails combined with the typesafety of haskell: https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/ IHP has around 230 monthly active projects at the moment, and it's growing fast. It was released 8 months ago and now is already the second biggest haskell web framework :) I think haskell has been previously tragically underused because it was missing good documentation and pragmatic solutions that help you to get things done. Atleast in the web dev space this has changed this year. Watch our IHP demo video and you'll get it: https://www.youtube.com/watch?v=UbDtS_mUMpI https://www.youtube.com/watch?v=UbDtS_mUMpI Disclaimer: Founder of digitally induced, the company that makes IHP.

dragonwriter 6y ago

> Isn't the best course of action to rewrite popular components in Haskell, and show that its bette No, the best course of action is to solve problems that haven't been solved, not to do marginal reinventions of the wheel. A killer solution is definitely a help in getting a language ecosystem to take off, but those are rarely simple reimplementation of an existing tool. Occasionally they are in a recognizable existing category, sometimes they are category-defining.