New Haskell Foundation to Foster Haskell Adoption, Raises 200k USD

I thought your point about bootstrapping to popularity was a good one. It's not easy but I'm convinced that Haskell is good enough that it's possible (in fact I think it's inevitable that either some Haskellish language will become popular or some popular language will become Haskellish).

One of the problems with languages like Haskell, Erlang, and Lisp is that they’re so flexible that you often don’t know what you’re getting into when you read somebody else’s codebase. You often see projects written in these languages with a small core team that understands e.g. SBCL and the various macro libraries they use to get work done, or Haskell and the monad transformer stack they use in their app, and it’s very hard over the long-term to on-board new team members and bring them up to speed at a rate which keeps the team healthy.

Maybe this is an inherent problem with “flexible/powerful” languages.

There are a few Haskell tools around that people do regularly use—Git Annex, although Git LFS seems to have edged it out in popularity, and Pandoc, which I’d say is powerful and irreplaceable.

Maybe zero people are writing lens libraries in C, but C does have a fair number of different string libraries around, exception / error handling libraries, and a bunch of people churning out terrible “single-header” libraries which only exist because average C programmers aren’t good at working with common, mediocre C build systems.

This is easy to measure because it refers to properties of applications (performance and vulnerability-density) rather than properties of the development process.

Rust also seems to reduce the need for a ridiculous guru at your company to help keep programs correct. That is easy to identify and measure. Haskell doesn't seem to do this. If I imagine running a team of 80 people on a Haskell application vs a Java application, do I feel like I'll need fewer Haskell gurus? No.

I agree monad composition isn't amazing. When I was writing a lot of Haskell (I was working on real time 3d reconstruction algorithms from video feeds using camera input and OpenGL output) it wasn't a very large roadblock though. But effect type systems seemed like they might be cleaner.

I don't have time to read through that article right away but I saved it for future reference - thank you for sharing.

Anyway, CRUD does really not lead to clear "is IO"/"isn't IO" boundaries, and the business logic isn't a good candidate for separating from IO into a pure core. Instead, it is a great candidate for separating into a "with business data" context that is neither simple IO nor pure.

On the implementation of that "with business data" context you will find plenty of opportunities to push IO to the boundaries of complex code that will become pure. But your intuition is correct, what you are missing is that the code can be broken on more dimensions than the ones you are assuming.

Sure, which is why there is no reason to code them specifically at all as unique applications. Instead, the domain isn't the business domain of a particular application but far more general, and then you code something like PostgREST in Haskell where the domain is mapping between database and API calls, and solve the problem generally, and define specific applications just with database schemas.

“Domain logic” is only “business logic” when you've decided you need a bespoke app built for a specific business problem, which makes sense when you have a complex business problem, but is simply wasteful when you have a problem for which a general solution already exists. It's like asking who is the best designer go go to for a one-off custom car for perfectly average daily commuting use: you've chosen from the outset an inefficient solution to your problem.

Non-strict semantics would be prohibitively slow without these optimizations.

You won't find a Haskell compiler that doesn't do this.

It could do so if it were to be willing to sacrifice having even a modicum of performance.

Lazy evaluation is incredibly slow without these. The theory behind lazy evaluation, is that it can gain back some of the performance it inhærently loses by allowing these kinds of aggressive hole-program optimizations because code can freely be re-ordered as no code has side-effects.

Without taking advantage of this re-ordering, one is only met with the pœnalties.

Note that in Haskell very fundamental primitive logical operations such as `||`, `&&` and `if` receive no special treatment from the implementation and are ordinary functions. If these were not allowed to be optimized as such, and they would be provided as a library, then the code would be prohibitively slow and would essentially require that a thunk be passed at every instance of a normal logical construct.

> The archlinux haskell packagers could just ship programs as statically linked binaries and not recompile them on each minor dependency upgrade (except if there is a security upgrade). The binaries would not have any dependency on haskell packages themselves and you would not be forced to upgrade the whole package graph when some dependency is bumped, that would also save a lot of download bandwidth. I'm not sure that anyone really needs haskell packages (besides standalone programs) from the system package manager. No haskell dev I know builds their programs this way.

Indeed — no one does, because the unsung pain with Haskell is that it's impossible.

With strict languages one has the option for dynamic linking, and dynamic linking seems to be what has won out due to it's convenient “update once; update everywhere.” benefits — that is not available to non-strict languages, for which static linking is the only viable way of distribution.

> https://doc.rust-lang.org/edition-guide/rust-2018/platform-a...

Yes, I'm aware of that; the fact that they continued using glibc as their default (aka canonical) OS/syscall interface after discovering that it was so impossible to statically link that people had to retarget code to a whole second libc was one of the final nails in the proverbial coffin for me.

> because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code.

Not particularly relevant, since my inquery was mainly about Rust, but on my system I get:

  $ echo 'main = pure ()' > foo.hs
  $ ghc foo.hs
  [1 of 1] Compiling Main             ( foo.hs, /tmp/tmp.icUr2pqZXx/Main.o )
  Linking foo ...
  $ file foo
  foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

For instance let us say we have pseudocode:

   let list       = [1,2,3,4,5];
   let new_list   = do_something(list);
   lew newer_list = do_something_else(new_list);

A non-strict language however is permitted to take the side-effect-less code apart, and restructure it in such a way that the list is only traversed once, essentially combining these two functions into one function and letting what each does run successively, for this purpose it is permitted to generate a new function that combines what both does, and doing so iterating the list only once, and optimizers are typically clever enough to be able to do so.

Suppose that both of these functions be library function black boxes, provided by a dynamic library, then the implementation can no longer do this as it calls both from a library.

The way Haskell is written is completely dependent on this; it would be awfully slow if the compiler weren't allowed to do this.

The result in practice is that updating a dynamic library written in Haskell requires that all it's consumers be recompiled to compile against the new version. Or otherwise said: there is no concept of a stable a.b.i. in Haskell.

https://www.stephendiehl.com/posts/protolude.html

You're not doing Haskell any favors by comparing with "the times when STL was no good" (when was this? 20 years ago? 30?).

> Why should the situation with Haskell be different?

Because the world has moved on and expects languages, their libraries and runtimes to become better.

There are plenty of beginner-friendly resources already (more & more every year), but they can't erase worse ones from the Internet. The Haskell community lacks the sort of strong-fisted leadership to accomplish that by design.

That said, acting like a tutorial mentioning lazy IO or partial head/tail is a killer is a little ridiculous. Neither of those things are atrociously problematic, so learning about them early is fine. You may get cut due to them, but getting cut is okay if you don't flip the table.

Also I (and most of Haskell posters) do not gatekeep. The community will go well out of its way to respond to any questions beginners have with blog-post-quality comments in the various forums (mailing list, reddit, irc, slack, github issues, etc) There is definitely a teaching culture, which is the opposite of gatekeeping.

Haskell is first and foremost a gigantic personal productivity booster. It allows me to do bigger and more complex projects on my own or with one or two others. These projects are not for corporate interests although that can be for personal profit. I am pretty confident I will be able to stop giving my labor to any corporation within the 10 year mark of my career, and Haskell will be a big reason why.

But I still try to convince corporations to use Haskell since then we offload the cost of learning onto a corporation instead of an individual. That feels like a worthwhile re-allocation of capital to me! Corporate Haskellers get paid to gain expertise and keep it forever, leaving corporation with nothing besides their direct labor. Luckily it's easy to convince a corporation of anything with what amounts to propaganda & politics.

But "you won't be able to use it well if you don't learn how to use it" does indeed apply to all languages. Yet, it's more relevant for some, and Haskell is one of those more affected by it.

It is a fact that Haskell is not beginner friendly. Your first program on it will suck, whatever proficiency you have with other languages (there are some people that argue that it is easier if you know less beforehand). It takes some learning before you are able to get the better safety, high productivity and easy collaboration people talk so much about (and even then, you won't get those for every problem, the language has limitations too).

1 - The statement is false anyway. There's no such language one can single out there without more context.