My biggest complaints are 1) the lack of good libraries, and 2) the apalling state of documentation for the few that exist. Too many Haskell projects read like "I figured out this neat family of types for thinking about X - at last URL parsing is provably safe - now you figure out the rest".

Let's take a practical example: HTTP requests. If I'm a budding JavaScript developer, or Kotlin developer, or Python developer, I can read through copious search results and tutorials on Axios / OkHttp / Requests / delete as appropriate. These tutorials not only walk me through the common use cases but also show me their APIs in the context of the new and alien syntax of the language I'm grappling with. They give me enough template code that I can use an incomplete understanding of whatever language it is I'm learning to figure out the rest without recourse to a textbook.

What does Haskell have? It has Req (and a bunch of other also rans), and the docs for Req are atrocious, spanning a staggering 1 (one) example and then a meandering essay on the deficiency of other Haskell HTTP clients. It's not good enough.

And that's my assessment of Haskell as a whole - not the language individually, which is expressive and powerful and inspired - but the whole ecosystem around Haskell that feels like a set of beta projects and hobby repositories generally developed by interested individuals rather than commercial endeavours.

Or look at the paltry state of IDE support. It's 2020 and the best option we have is VSCode with HIE, which rapidly spirals out of control allocating memory, randomly crashes and on Windows just refuses to even start half the time. Without this tooling a lot of the theoretical benefit of the type system is being lost. This is low hanging fruit but there's been no incentive to pick it.

And so I've made the difficult decision to leave Haskell behind. If you need typed functional programming, your options are OCaml, Scala, F# or even subsets of Rust and TypeScript. Haskell is a great learning experience but totally unproductive right now.

I learned Rust in 2016, and have kept up with it since. It was a painful first entry point, and then another rather painful experience when I first used it for a big hobby project, but now it is my go-to language because it's exactly as hard as it needs to be, has amazing community and documentation and libraries, and gives me the option to have really good performance while also using very nice ML-family linguistic constructs.

Well begin is half done, and Python and Ruby made it so easy to program that without reading multiple of books and spending a year or two, programmers can write decent code. This is the reason why Go and Swift the other two system programming language is far ahead of Rust despite being GC language. Indeed even the latest OS Fuschia is written in C++ (zircon kernel), with Rust SDK to write high level programs same as the one written with Dart and flutter.

Zig is a kind of language that wouldn't have been written if its author discovered ATS[1] at a right time.

[1]: http://www.ats-lang.org

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.

Language server support is a recent trend, and it’s being worked on for Haskell just like it is for everything else.

They’re fine libraries, they’re just not what I want to see if you’re trying to convince me to replace Java with Haskell at work. If I was looking to write a compiler however...

Brutalist Software engineering.

If you want chickens to hatch reliably, you need a coop too.

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.

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.

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.

> The same is true of identifying anything about the level of TLS support, configuring which cipher suites to accept, etc.

This is really weird, and I think that your comment doesn't represent the reality. Here's the official Yesod Book[1] mentioning WAI and Warp as a de-facto standard server implementation for a Haskell Web ecosystem. The Hackage page for Warp[2] contains "HTTP/2" and "TLS" at the very top of the package description section. Googling "haskell warp tls" produces the topmost link pointing to warp-tls package[3]. The package docs clearly show all supported ciphers[4]. And googling "haskell yesod http2" produces the second top link[5][6] that mentions HTTP/2 and TLS and it has been around since 2015.

[1]: https://www.yesodweb.com/book/web-application-interface#web-...

[2]: https://hackage.haskell.org/package/warp

[3]: https://hackage.haskell.org/package/warp-tls

[4]: https://hackage.haskell.org/package/warp-tls-3.2.12/docs/Net...

[5]: https://www.yesodweb.com/blog/2015/07/http2

[6]: https://pasteboard.co/JaRXKUR.png

So just to be clear:

To discover what is actually possible in this area, someone new to Yesod is supposed to read the entire book through to an appendix, which itself could kindly be described as "not entirely clear".

Then they're supposed to recognise that they need to write their Haskell application using WAI and a Warp backend (whatever that means in this context, because the relationships between these tools are among the "not entirely clear" aspects of that appendix) instead of using the other tools that were already described earlier in the book, despite having no obvious motivation for doing so at this point (because terms like HTTP/2 and TLS do not appear anywhere in the Yesod book appendix you linked to).

Then on the off chance that these alternative tools mentioned in an appendix of an online book can do what the developer wants even though the appendix doesn't say anything about that at all, our intrepid developer is supposed to go and look up the Hackage pages for those tools, one of which does at least mention the term HTTP/2.

There's no further information on those documentation pages about how to actually use important features of HTTP/2, for example setting up server push, though. In fact, the only reference to server push I can find anywhere in the Warp documentation relates to the function setServerPushLogger.

So while I appreciate your taking the time to comment, I'm afraid my previous conclusion has not changed. Maybe these tools are useful if you already understand them in detail, but for someone familiar with Haskell but writing a web application with it for the first time, this experience isn't even on the same scale as a good, production-ready ecosystem.

Finally, just for the record, while choosing the perfect query to Google might have found you a useful link, several similar obvious searches I tried before did not, nor indeed does the exact term you mentioned ("haskell yesod http2") in some other search engines such as Duck Duck Go. And your Pasteboard link (I assume) intending to demonstrate the search you managed successfully is not working from here.

But this is hardly an example of "not being able to find it with a search engine" as the original message seemed to claim. Surely it takes time to get acquainted with a new ecosystem, and curiosity is welcomed in the community.

> To discover what is actually possible in this area, someone new to Yesod is supposed to read the entire book through to an appendix

That's hardly true either, one just needs to google "haskell yesod http2" or "haskell yesod tls" - both results will be within topmost 5 links. The results will be full of potentially unfamiliar technical details, but they still allow getting the general idea of what is possible. And reading the book helps enormously to get everything internalized.

> There's no further information on those documentation pages about how to actually use important features of HTTP/2, for example setting up server push, though

the top link of googling "haskell warp http2 server push" produces a whole section on how server pushes are done - https://hackage.haskell.org/package/wai-3.0.4.0/docs/Network...

> in some other search engines such as Duck Duck Go

I use DDG by default, and I regularly add !g for the same reason

The only related thing I got at the end of search results is this page https://www.yesodweb.com/blog/2015/07/http2 that doesn't even mention yesod so good luck trying to understand what is it while all it talks about is haskell warp.

By the way this paragraph is scary. Haskell didn't support half of the modern cryptography required for TLS 1.2 (2008) so the author had to write them himself (and sent pull request to the tls haskell package).

"Unfortunately, many pieces were missing in the tls library. So, it was necessary for me to implement ALPN, ECDHE(Elliptic curve Diffie-Hellman, ephemeral) and AES GCM(Galois/Counter Mode). They are already merged into the tls and cryptonite library."

[0] puts examples front-and-center on the Hackage page.

[1] lets you easily integrate WebSockets with other things like Warp.

[2] shows that WebSocket servers in Haskell are actually quite performant.

[0] https://hackage.haskell.org/package/websockets

[1] https://hackage.haskell.org/package/wai-websockets

[2] https://github.com/hashrocket/websocket-shootout/blob/master...

Again, that's all well and good if you already know how to do it. But to be useful for serious production work, it shouldn't take several hours of reading, including numerous side trips to dead ends, and a discussion on HN where multiple Haskell developers who apparently have a lot more experience in this area suggest a variety of different libraries that collectively might get the job done. Except that right now, we've got two libraries for dealing with the WebSockets aspect in play, not counting plumbing libraries to join them up with the other aspects, and it's not clear which would be preferable to use or why.

It's worth remarking that at this point, we still haven't reached the point where I'd know how to write the simple proof of concept that I wrote in probably 20-30 minutes with Node without needing to consult anyone else. Achieving that within the Haskell ecosystem would apparently take considerable further reading, not to mention writing considerably more code if the examples we've collectively come up with so far in this discussion are as good as it gets.

Just to be clear, that is a fair comparison. In both cases, I was already familiar with the language and its main tools but I had no previous experience of writing the server side of a web application using either.

I don't know how much clearer I can make my point here, and I think perhaps those commenting to defend Haskell are still missing it. Even if some combination of libraries exists to do something in Haskell, that is still of very limited practical use if someone who isn't already an expert in them can't find the relevant information about what they are and how to use them. The documentation and packaging we've been talking about in this part of the discussion appear to be far from ideal, and keep in mind that even in the discussions here, we've already started from the premise that the developer recognised Yesod as the way to go when several other similarly well-known libraries are available for writing web servers in Haskell with varying capabilities and limitations. This is the same fundamental criticism that numerous people have made of the Haskell ecosystem in many different contexts, including elsewhere in today's HN discussion.

This is an unsubstantiated claim. For years, Haskell has had the best in class backend web stack - https://www.aosabook.org/en/posa/warp.html

Please define "best in class".

* Semi-explicit deterministic parallelism out of the box (https://www.microsoft.com/en-us/research/wp-content/uploads/... , https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_gui...)

* implicit Async IO runtime out of the box (https://www.microsoft.com/en-us/research/wp-content/uploads/...)

* thread-safe global mutable state and atomic transactions (http://book.realworldhaskell.org/read/software-transactional...)

* type-safe native TLS (https://hackage.haskell.org/package/tls)

* multicore async streaming web server (Warp) with a unified application API (WAI)

* type-safe embeddable DSLs for rendering web content (https://hackage.haskell.org/package/blaze-html , http://fvisser.nl/clay/)

* type-safe embeddable binary content at build-time (https://hackage.haskell.org/package/file-embed-0.0.12.0/docs... , https://hackage.haskell.org/package/servant-static-th-0.2.2....)

* type-safe HTTP specs and automatic schema derivation (https://docs.servant.dev/en/stable/cookbook/index.html)

* the whole stack (multicore asyncio runtime, Network, HTTP/1.1/2, WebSockets, TLS, HTTP Server + Schema Specs, Markup rendering) is compiled into a single static binary of ~3 megabytes, universally across Linux, MacOS, Windows.

* fullstack story with a help of GHCJS and a selection of frameworks (https://reflex-frp.org , https://haskell-miso.org)

If we surveyed a representative sample of 1000 professional web developers, how many of them do you think would give a list broadly in line with your definition for the properties of their ideal server implementation language?

The list above was a list of features, not a list of benefits. Those features might bring practical benefits to the working web developer -- after all, people who program in Haskell do so for a reason, which is probably that they believe this kind of language is helpful in some way -- but that has yet to be established here.

Meanwhile, an experienced back end web developer will probably be asking questions about managing large numbers of routes or guarding against common attack vectors or integrating with databases or calling external APIs or having a template system that supports translation to multiple (human) languages or understanding performance characteristics and how the servers will react to higher loads. These are practical matters that many web server frameworks attempt to address. It is revealing but not entirely surprising that the Haskell response to my question was instead to talk about strong typing and STM and so on.

I was answering your comment about Haskell's web ecosystem. I didn't claim that Haskell is the best in class for everything just because it's the best for implementing web backends.

> It is revealing but not entirely surprising that the Haskell response to my question was instead to talk about strong typing and STM and so on.

I put them into my response because they are the features that you highly likely are not going to find alltogether on any other platform. The regular things like I18N, L10N, and so on that you mentioned are not worth the discussion, because Haskell ecosystem has them, in various shapes and forms, and apart from boring implementation details they are no different from similar libraries on other platforms.

So for example, just use http-client instead of req. Use postgres-simple or persistent instead of beam, etc...

For HTTP request library, most would recommend Wreq. Being most popular, the documentation is really good I might say with most used API have their own example [1]. You can also easily find great tutorial on the net, like http://www.serpentine.com/wreq/tutorial.html for example. Honestly I never use Req myself and looking at the documentation myself, even though I don't it's lacking, I think it's not really geared toward Haskell beginners so maybe you have a point there.

As a novice Haskell programer who only use it for side projects, I don't think the documentation is that bad and it's only getting better. Most popular libraries like database clients and web frameworks have intensive documentation and tutorial nowadays.

I agree with you for the state of IDE support, it leaves something to be desired. But people are still working on it[2]. For now I mostly use vim with help of linter and formatter. The great thing about good type system is, you can still do much even without great IDE support. Haskell already have working and great REPL support that make development a breeze so it helped. I'll still take Haskell over OCaml or Scala anyday. Rust is great and I love it so much that it's my go to language for something system programming or networking related, but I don't think it's a good match if you want to learn functional programming.

[1] https://hackage.haskell.org/package/wreq-0.5.3.2/docs/Networ...

[2] https://github.com/haskell/haskell-language-server

Plenty of people (including some of my colleagues) write Haskell in Visual Studio Code.

I don’t know anything about Tensorflow (though machine learning seems a bit more “niche” than building websites tbqh), and I haven’t known anyone to use Eclipse for writing code in the past decade or so.

Genuinely, I haven’t a clue what you are talking about. How would three general purpose languages “work out of the box” with X, but a fourth would not? Eclipse is a text editor and you can write Haskell with it. There are Haskell bindings to Tensorflow available.

Your point now doesn’t even seem to be consistent with your original point. How is Eclipse state-of-the-art? How is Haskell behind?

And don't forget D. It's surprisingly well-suited for FP as its effects system has explicit support for pure functions and specifying a function is guaranteed not to throw, in addition to support for true (transitive) immutability. Not to mention full first-class function support, with lexical closures.

There's at least https://plugins.jetbrains.com/plugin/8258-intellij-haskell that is as simple for newcomers to setup as it can be.

Maybe my needs are limited but I rarely need something more than the GET and POST json examples there.

To elaborate further, some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane. We are just trying to build things here. These are very boring implementation issues that just need to get done.

It read like a series of math equations, with frequent single letter variable names.

It was concise and elegant in it's own way, but hard to follow in some cases due the lack of readable variable names.

I like the language but this cultural aspect made it harder to get up to speed and contribute.

     mReadFilePS p = B.concat `fmap` BL.toChunks `fmap` TM.readFile p

In Node.js, the convention is that classes are named after the modules they import-- they are full words:

    const config = require('config')

  import qualified Data.ByteString      as B
  import qualified Data.ByteString.Lazy as BL
  import qualified Data.Map             as M
  import qualified Darcs.Util.Tree.Monad as TM

I'll accept the learning curve for Haskell is at least longer (rather than steeper) than in most languages, but to hold this up as an example to me is just bizarre.

And I say this is someone who only knew JavaScript and PHP for some years before learning a bunch of other languages including Haskell.

Moreover, you've conveniently left out the type signature which I expect would normally accompany this function, which would tell the reader what the `p` variable is.

> We are just trying to build things here.

Some languages are built to do engineering first-and-foremost. Languages like Haskell are built to do mathematics in first-and-foremost. This doesn't mean that such languages aren't also well-engineered, or that they aren't also tuned to do engineering in; but the engineering concerns must be subordinated to not breaking the model that mathematicians rely upon to do math in the language. So you can't just e.g. change whether a particular kind of function can emit IO or not; or change what values exist as part of the lattice of a type; or any number of other things visible within the language's abstraction; because those very properties/constraints are also syllogisms which are relied upon in mathematics done in the language.

And before you say "why not just break the runtime model", by e.g. having special debug functions that can do IO while presenting to the runtime as pure functions—well, it's not impossible, in theory, but it's a Hard Problem, because those properties that a function presents to the runtime are also used by the compiler to optimize (or memoize, or fuse, or eliminate) code. You can't really declare something as a pure function without the runtime thinking it can do all sorts of things that result in the function being called less.

In theory, Haskell could have something like a "volatile" qualifier for functions, sort of like C's volatile qualifier for data, to tell the runtime that while the function has type X, all optimization opportunities that would normally apply to type X are off the table. Then you could have special debug functions of type X. It's just that getting this working would require a lot of re-work throughout the compiler, since the compiler mostly deduces optimization opportunities from the type (and marks something as having more optimization opportunities by proving that it has an extra applicable type), rather than just tracking some separate metadata that can be arbitrarily written to.

> And before you say "why not just break the runtime model", by e.g. having special debug functions that can do IO while presenting to the runtime as pure functions—well, it's not impossible, in theory, but it's a Hard Problem.

  import Debug.Trace

  square x = 
      trace "I'm a Hard Problem" (x * x)

  main =
      print (square 3)

It's hard for me to find a reasonable interpretation of this sentence that is true. I'm not sure much serious mathematics is done is Haskell, beyond the usual arithmetic operations present in most programs, especially relative to other programming languages. It hasn't taken off in the numerical computating market, for example.

Historically, it also seems like Haskell was built as a research language.

[1]: https://en.wikipedia.org/wiki/L4_microkernel_family#High_ass...

All that stuff about types and categories and monads and so on is maths too. Arithmetic or numerical work is only a subset of that field. Lots of maths doesn’t even involve numbers!

They don't really "do" category theory, for example; simply noting that something forms a category is mathematics only in the most trivial sense.

I think the question he's asking is: What papers have been published in math journals where the work was done in Haskell? Which mathematicians use Haskell to do mathematics work?

  foo :: IO X

0: Which is a completely resonable thing to do, and the basis of any language's standard library, the ability to recapitulate which in normal code separates good languages from Go-like special-cases-for-me-but-not-for-thee languages.

This is not the first time I have seen this claim, but it's so much in contrast with my experience that I don't know what to think.

There seems to be some cliques of Haskell developers on mostly non-communicating communities. I would imagine they self-select but I have actually only encountered any hostility on Stack Overflow, and the Haskell part of it, besides being business as usual for the site, also is a mostly useless knowledge base (to the point that I remove the site from searches to decrease the noise).

O yeah, I totally forgot that. There is a very senior guy on SO who literally helped to fix all our non-trivial problems. I still need to investigate if we could move from Elm to Elmish (or more like SAFE).

Although there have been heated public disagreements, I haven't seen the people trying to destroy one another. They just have very strong disagreements. That doesn't bother me directly since I'm not in those discussions. The most I can say is that the lack of unity means there is a shortage of "best practice" of how to do certain things and lower community focus in advancing the ecosystem.

A common workflow for Haskellers is to specify type signatures and interactively edit until the compiler is satisfied. Often, the code gives you correct results on the first try.

This means the type signatures aren't simply documentation, they also strongly direct your implementation. The problem from a marketing and adoption standpoint is that this isn't visible until you've hopped into a REPL or IDE and tried it yourself.

This is a common counter-argument. It is a true statement. And, in the nicest possible way, it is also completely missing the point.

When you're playing with cute mathematical code and almost everything is written in terms of totally generic types, it's cute that you get free theorems and automatic derivations of some basic functions and all that stuff.

However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. This remains true notwithstanding the possibility that some of that cute generic code was used to implement various small parts of the function you actually care about if you dig down far enough.

This means the type signatures aren't simply documentation, they also strongly direct your implementation. The problem from a marketing and adoption standpoint is that this isn't visible until you've hopped into a REPL or IDE and tried it yourself.

I would argue that the problem from a marketing and adoption standpoint is that it still isn't visible even if you do do those things, unless you're interested in writing heavily mathematical generic code rather than completing the job your boss told you to do within a reasonable timeframe.

Yes, kind of.

> When you're playing with cute mathematical code and almost everything is written in terms of totally generic types, it's cute that you get free theorems and automatic derivations of some basic functions and all that stuff.

It's not only "cute" as you so reductively put it. There are real world benefits.

> However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. This remains true notwithstanding the possibility that some of that cute generic code was used to implement various small parts of the function you actually care about if you dig down far enough.

That presumes an arguably wrong method of developing software that needlessly eschews understanding and correctness confused for superior economic choices, finally resulting in "real world programming".

But, on the gripping hand, using types unspecific enough that that is the case is often a sign of underusing the type system. E.g., very few domains actually deal with bare numbers as domain values, and when you express concrete types specific enough, there may be more than one possible correct function, Bru very often the one actually correct function will be much more obvious, and the mistakes possible by omitting a step when using less-robust sets of types become impossible because you effectively have statically verified dimensional analysis.

In my experience, though of course yours may differ, there are very often still many plausibly correct implementations of functions working with those types and many ways to combine them that might make sense and that would satisfy the type checker. The idea that specifying the types alone is a viable substitute for proper documentation of the real meaning of the functions just falls apart at that point.

Not if your logic is primarily in terms of domain types, invariants encoded in those domain types as is necessary and economical.

> And at that point, all the power you get from saying things like there's only one possible implementation of a function f :: a -> a immediately go out of the window, because you don't have a value of type a, you have a value of type SomeConcreteTypeThatIKnowThingsAbout.

Can you give an example? I can only see this being the case if your logic is done at the concrete type level.

That does not square with the constant complaints about insufficient documentation.

It also does not matter if there's only one or two valid ways to call a function if the programmer can't figure out how to do it.

None of what you wrote contradicts that examples could be given in the docs.

But defending the lack of documentation kind of shows why haskell will not see much adoption.

Also, rust for example is much more rich when it comes to examples in docs and rust people could also argue to not provide docs because of type signatures. They just decide to provide documentation and succeed in attracting people.

In terms of reducing development time or cost, reducing defects, improving design, or really improving any business outcomes whatsoever, Haskell showed no success, only failure.

How could that be in contrast to “ugly” and “complex” languages like Java and C++, or free for all languages like Python and Node js?

The reason is simple:

1. imperative structure is actually clearer and easier to understand, easily amenable to all the upsides of function-oriented programming with far fewer downsides.

2. removing whole categories of bugs through compilation and type system patterns is a hugely overrated waste of time. Lightweight unit tests get you 99% of the way there with far less rigid design commitment

3. safety and correctness are resources just like memory or runtime complexity, not absolutes. Being able to tradeoff safety against other concerns, at a moment’s notice, deep in the guts of a large system, is one of the most critical requirements of business software

4. Premature abstraction costs you way more in pure functional languages than most other imperative or OO situations.

Are you referring to language extensions? This is sooooo off-base if so.

I don't see how people can bemoan Haskell's complexity but love a language like Kotlin which has its hodgepodge of function call semantics. Talk about complexity without any sane ground. It's so hacked together. At least with Haskell everything is very simple in isolation and composes for the most part.

--

Also re:examples.. I'd say Haskell libraries have better examples than the average Go library for instance. Many have entire modules whose entire existence is for putting examples & tutorials in the haddocks themselves.

One of a few possible explanations: they are mobile app devs who simply want to get things done, instead of hacking the toolchain (including myself).

Sure I'd love be able to write Android apps in Haskell. What's the easiest way to do it?

With Kotlin, it's already nicely packaged in Android Studio. Very convenient.

* https://github.com/ElvishJerricco/reflex-project-skeleton

* https://github.com/reflex-frp/reflex-platform/blob/develop/d...

I do appreciate the tooling around Kotlin. Definitely wish we had more time and money available in Haskell to match it.

Still doesn't explain enterprise use of Kotlin on the backend lol.

From my limited experience I agree that debugging a bug that passes compilation is more difficult than on other platforms.

How come I never seem to have this problem. I mean one scala dick (who wasn't actually so bad after a while) but that's it.