5 ms·

It's a bit of a chicken and egg problem and pretty much what the author of the article is talking about as well. You need people's time and energy to improve th

by pwm 6y ago

It's a bit of a chicken and egg problem and pretty much what the author of the article is talking about as well. You need people's time and energy to improve the status quo and getting people's attention takes ... people's time and energy. Haskell has always been grassroots and imho has enough hard-core believers that it will never go away but whether it'll ever be mainstream I don't know. I have great admiration for the small group of people who put their own time and energy into making the language and the ecosystem better. Re IDE support - loads happening there atm, ghcide is imho a true game changer and fast becoming an invaluable tool for working with Haskell.

Silhouette 6y ago
It's a bit of a chicken and egg problem It is. The way you usually resolve that problem if your language is going to become a big mainstream success is to have a particular focus, one key selling point where it is uniquely capable or at least so far ahead of the opposition that using it is a compelling advantage. JavaScript was the language for writing front-end code. C was the language for low-level programming. Java was the language for getting code monkey class programmers to be reasonably productive in enterprise environments. There are now other languages in each category, and there are now other uses for each of these languages, but the important point remains: those languages dominated those niches at the time they took off and that was why they took off. Unfortunately for Haskell, a sophisticated type system and compiler capable of supporting experimental language design research is a niche that about 0.0001% of developers and people who pay developers care about. Haskell has indeed been very successful in that small niche, and it remains so. But I had a look into it the other day from the point of view of implementing the back-end for a new web project, and its support for writing web servers is still probably a decade behind the state of the art. I swallowed my pride and today that back end runs on Node. Would I prefer Haskell's safety and power over JS? Of course. But I'd prefer a language where any server I wrote can speak modern web protocols and support the functionality I need, and of those two languages, only one clears that bar.
- ardfard 6y ago
  Can you explain what Haskell fall behind in term of writing web servers? As someone who wrote Node and Haskell web apps in the past I don't think it's true. Let't take a look at one of premier Haskell web framework Yesod. It has support for authentication, http/2, https, middlewares, logging, etc. I don't think there is any "modern web protocols" that Haskell cannot support. It's only a language anyway. It popular and powerful enough for people to implement something novel with it. I know Haskell had been used for testing-bed for programming language ideas because making abstractions in Haskell is freaking easy. But you can just ignore them and stick to boring, working and practical subset of the language. The language already been heavily used in industries so I know for a fact that it's fit for production use. I myself did deploy Haskell apps to production (Telegram bot for personal use) and never encounter any problem.
  - Silhouette 6y ago
    Let't take a look at one of premier Haskell web framework Yesod. OK, let's do that, since that's exactly one of the things I tried. So, one thing I was interested in was indeed support for HTTP/2. You've just stated that Yesod supports it. Right now, with the aid of all of the main types of documentation linked from the Yesod site and a search engine, I am totally unable to verify that. I literally cannot find a single reference to it on the entire Web. The same is true of identifying anything about the level of TLS support, configuring which cipher suites to accept, etc. I was also interested in WebSocket support. Again, there's no obvious sign of this in the documentation, at least not that I found in a few minutes of browsing. Any of it. Seriously, projects wanting programmers to use them should have one authoritative source of reference documentation, and it should be up to date and easily searchable. Still, on this one, at least a web search finds me yesod-websockets. That has the usual mix of package technicalities on its Hackage page, plus a documentation page with a long list of functions, type signatures and one-line descriptions in the Hackage documentation. Ironically, there is also a link from the package description to Stackage, which has another page of package technicalities linking to another similar page of documentation, which is roughly the same, but apparently the two versions I've found are different because one is 0.3.0.1 and one is 0.3.0.2. There's nothing to give you confidence in using a library in production like a four-part version number that starts with "0.". And no obvious description of the real level of maturity and stability that reflects, so I'm going to assume this is pre-release quality. And did I mention there should be one authoritative home for reference documentation? That goes for the package itself, too. No matter how many times a Haskell fan says that this kind of thing is sufficient, it simply isn't. There is no introductory tutorial. There are no illustrative code snippets or HOWTOs or full working examples. There is no apparent organisation of any kind in what little reference documentation does exist except for a few headers that have little meaning if you don't already know what they mean. I have no idea how stable this package and its API are, but the version numbers (plural) suggest the default assumption should be "not very". This isn't a serious proposition for production work. It just isn't. Maybe it's useful if you already know the Yesod library and the related libraries well, for example because you developed some of that ecosystem, or you've talked with someone who did, or maybe you've watched it evolve since it was simple enough to figure out from the limited documentation and kept up. But for someone with Haskell experience who hasn't used it to build a web server before, it's all but useless. For the record, I had a working server, including proof of concept WebSockets code, up and running on both the client and server side using Node, in less time than it's taken me to re-check a few facts and then write this comment. And a web search for any of "node http2", "node tls" or "node websocket" immediately locates a wealth of relevant documentation, examples, etc.
ashtonkem 6y ago
I no longer think it's a chicken and egg problem with Haskell, and more of a goals & culture problem. Libraries like lens and parseq have a huge amount of effort put into them, probably more than what it would take to create a good HTTP client library. The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has.
- nilkn 6y ago
  > The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has. I don't think that's a fair take. Haskell started as a research language, and it's only in the 2010s really that it started taking off and becoming more and more practical. That's because people invested lots of effort in libraries like lens (and many others). Haskell didn't even have a strong build system until Stack popped up in the mid-2010s. Frankly these were bigger priorities. These things had to be solved first in order to transition Haskell from a research experiment in lazy evaluation into a real-world tool. In 2020, outside of maybe dependent types, the community is probably more concerned with practicality and pragmatism than ever before. There's a huge focus right now on improved IDE support, for instance.
  - ashtonkem 6y ago
    10 years should be enough time to get a working IDE and a good starting set of libraries, and my personal experience is that Haskell has neither.
    - nilkn 6y ago
      Maybe you ran into an issue where there still isn’t a decent starter library, but there are actually tons of great ones out there that we’ve used to build production services. So I can’t say I really know what you’re talking about in general. Language server support is a recent trend, and it’s being worked on for Haskell just like it is for everything else.
- pwm 6y ago
  People put energy into what's most useful for them and I don't think they should be blamed for this. I'm sure I'm biased but Lens and Parseq (and its successors) are both amazing libraries solving real problems in a powerful way. You probably don't agree and that's perfectly fine by me. I'd also go as far as saying that the 2 libs you've picked actually have pretty comprehensive documentations as well which is not always the case with Haskell libs (a real problem I 100% agree with btw).

by pwm 6y ago

Silhouette 6y ago

It's a bit of a chicken and egg problem It is. The way you usually resolve that problem if your language is going to become a big mainstream success is to have a particular focus, one key selling point where it is uniquely capable or at least so far ahead of the opposition that using it is a compelling advantage. JavaScript was the language for writing front-end code. C was the language for low-level programming. Java was the language for getting code monkey class programmers to be reasonably productive in enterprise environments. There are now other languages in each category, and there are now other uses for each of these languages, but the important point remains: those languages dominated those niches at the time they took off and that was why they took off. Unfortunately for Haskell, a sophisticated type system and compiler capable of supporting experimental language design research is a niche that about 0.0001% of developers and people who pay developers care about. Haskell has indeed been very successful in that small niche, and it remains so. But I had a look into it the other day from the point of view of implementing the back-end for a new web project, and its support for writing web servers is still probably a decade behind the state of the art. I swallowed my pride and today that back end runs on Node. Would I prefer Haskell's safety and power over JS? Of course. But I'd prefer a language where any server I wrote can speak modern web protocols and support the functionality I need, and of those two languages, only one clears that bar.

ardfard 6y ago
Can you explain what Haskell fall behind in term of writing web servers? As someone who wrote Node and Haskell web apps in the past I don't think it's true. Let't take a look at one of premier Haskell web framework Yesod. It has support for authentication, http/2, https, middlewares, logging, etc. I don't think there is any "modern web protocols" that Haskell cannot support. It's only a language anyway. It popular and powerful enough for people to implement something novel with it. I know Haskell had been used for testing-bed for programming language ideas because making abstractions in Haskell is freaking easy. But you can just ignore them and stick to boring, working and practical subset of the language. The language already been heavily used in industries so I know for a fact that it's fit for production use. I myself did deploy Haskell apps to production (Telegram bot for personal use) and never encounter any problem.
- Silhouette 6y ago
  Let't take a look at one of premier Haskell web framework Yesod. OK, let's do that, since that's exactly one of the things I tried. So, one thing I was interested in was indeed support for HTTP/2. You've just stated that Yesod supports it. Right now, with the aid of all of the main types of documentation linked from the Yesod site and a search engine, I am totally unable to verify that. I literally cannot find a single reference to it on the entire Web. The same is true of identifying anything about the level of TLS support, configuring which cipher suites to accept, etc. I was also interested in WebSocket support. Again, there's no obvious sign of this in the documentation, at least not that I found in a few minutes of browsing. Any of it. Seriously, projects wanting programmers to use them should have one authoritative source of reference documentation, and it should be up to date and easily searchable. Still, on this one, at least a web search finds me yesod-websockets. That has the usual mix of package technicalities on its Hackage page, plus a documentation page with a long list of functions, type signatures and one-line descriptions in the Hackage documentation. Ironically, there is also a link from the package description to Stackage, which has another page of package technicalities linking to another similar page of documentation, which is roughly the same, but apparently the two versions I've found are different because one is 0.3.0.1 and one is 0.3.0.2. There's nothing to give you confidence in using a library in production like a four-part version number that starts with "0.". And no obvious description of the real level of maturity and stability that reflects, so I'm going to assume this is pre-release quality. And did I mention there should be one authoritative home for reference documentation? That goes for the package itself, too. No matter how many times a Haskell fan says that this kind of thing is sufficient, it simply isn't. There is no introductory tutorial. There are no illustrative code snippets or HOWTOs or full working examples. There is no apparent organisation of any kind in what little reference documentation does exist except for a few headers that have little meaning if you don't already know what they mean. I have no idea how stable this package and its API are, but the version numbers (plural) suggest the default assumption should be "not very". This isn't a serious proposition for production work. It just isn't. Maybe it's useful if you already know the Yesod library and the related libraries well, for example because you developed some of that ecosystem, or you've talked with someone who did, or maybe you've watched it evolve since it was simple enough to figure out from the limited documentation and kept up. But for someone with Haskell experience who hasn't used it to build a web server before, it's all but useless. For the record, I had a working server, including proof of concept WebSockets code, up and running on both the client and server side using Node, in less time than it's taken me to re-check a few facts and then write this comment. And a web search for any of "node http2", "node tls" or "node websocket" immediately locates a wealth of relevant documentation, examples, etc.

ashtonkem 6y ago

I no longer think it's a chicken and egg problem with Haskell, and more of a goals & culture problem. Libraries like lens and parseq have a huge amount of effort put into them, probably more than what it would take to create a good HTTP client library. The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has.

nilkn 6y ago
> The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has. I don't think that's a fair take. Haskell started as a research language, and it's only in the 2010s really that it started taking off and becoming more and more practical. That's because people invested lots of effort in libraries like lens (and many others). Haskell didn't even have a strong build system until Stack popped up in the mid-2010s. Frankly these were bigger priorities. These things had to be solved first in order to transition Haskell from a research experiment in lazy evaluation into a real-world tool. In 2020, outside of maybe dependent types, the community is probably more concerned with practicality and pragmatism than ever before. There's a huge focus right now on improved IDE support, for instance.
- ashtonkem 6y ago
  10 years should be enough time to get a working IDE and a good starting set of libraries, and my personal experience is that Haskell has neither.
  - nilkn 6y ago
    Maybe you ran into an issue where there still isn’t a decent starter library, but there are actually tons of great ones out there that we’ve used to build production services. So I can’t say I really know what you’re talking about in general. Language server support is a recent trend, and it’s being worked on for Haskell just like it is for everything else.
pwm 6y ago
People put energy into what's most useful for them and I don't think they should be blamed for this. I'm sure I'm biased but Lens and Parseq (and its successors) are both amazing libraries solving real problems in a powerful way. You probably don't agree and that's perfectly fine by me. I'd also go as far as saying that the 2 libs you've picked actually have pretty comprehensive documentations as well which is not always the case with Haskell libs (a real problem I 100% agree with btw).