Why Haskell?

https://www.gtf.io/musings/why-haskell

by mesaoptimizer • 2 years ago

433 591 2 years ago

gtf.io

louthy12• 2 years ago

I love Haskell the language, but Haskell the ecosystem still has a way to go:

* The compiler is slower than most mainstream language compilers

* Its ability to effectively report errors is poorer

* It tends to have 'first error, breaks rest of compile' problems

* I don't mind the more verbose 'stack trace' of errors, but I know juniors/noobs can find that quite overwhelming.

* The tooling, although significantly better than it was, is still poor compared to other some other functional languages, and really poor compared to mainstream languages like C#

* This ^ significantly steepens the learning curve for juniors and those new to Haskell and generally gets in the way for those more experienced.

* The library ecosystem for key capabilities in 'enterprise dev' is poor. Many unmaintained, substandard, or incomplete implementations. Often trying their best to be academically interesting, but not necessarily usable.

The library ecosystem is probably the biggest issue. Because it's not something you can easily overcome without a lot of effort.

I used to be very bullish on Haskell and brought it into my company for a greenfield project. The company had already been using pure-FP techniques (functors, monads, etc.), so it wasn't a stretch. We ran a weekly book club studying Haskell to help out the juniors and newbies. So, we really gave it its best chance.

After a year of running a team with it, I came to the conclusions above. Everything was much slower -- I kept telling myself that the code would be less brittle, so slower was OK -- but in reality it sapped momentum from the team.

I think Haskell's biggest contribution to the wider community is its ideas, which have influenced many other languages. I'm not sure it will ever have its moment in the sun unfortunately.

Vosporos2• 2 years ago

If you are willing / able to report these pain points in detail to the Haskell Foundation, this is going to be valuable feedback that will help orient the investments in tooling in the near future.

louthy12• 2 years ago

I think tooling is something that is clearly on a good trajectory. When I consider what the Haskell tooling was like when I first started using it, well, it was non-existent! (and Cabal didn't even understand what dependencies were, haha!)

So, it's much, much better than it was. It's still not comparable to mainstream languages, but it's going the right way. So, I wouldn't necessarily take that as the killer.

The biggest issue was the library ecosystem. We spent an not-small amount of time evaluating libraries, realising they were not up to scratch, trying to do build our own, or interacting with the authors to understand the plans. When you're trying to get moving at the start of a project, this can be quite painful. It takes longer to get to an MVP. That's tough when there are eyes on its success or not.

Even though I'd been using Haskell for at least a decade before we embarked upon that path, I hadn't really ever built anything substantial. The greenfield project was a complex beast on a number of levels (which was one of the reasons I felt Haskell would excel, it would force us to be more robust with our architecture). But, we just couldn't find the libraries that were good enough.

My sense was there's a lot of academics writing libraries. I'm not implying that academics write poor code; just that their motivations aren't always aligned with what an industry dev might want. Usually this is around simplicity and ease-of-use. And, because quite a lot of libraries were either poorly documented or their intent was impenetrable, it would take longer to evaluate.

I think if the Haskell Foundation are going to do anything, then they should probably write down the top 50 needed packages in industry, and then put some funding/effort towards helping the authors of existing libraries to bring them up to scratch (or potentially, developing their own), perhaps even create a 'mainstream adoption style guide', that standardises the library surfaces -- there's far too much variability. It needs a keen eye on what your average industry dev needs though.

I realise there are plenty of companies using Haskell successfully, so this should only be one data point. But, it is a data point of someone who is a massive Haskell (language) fan.

Haskell has had a massive influence on me and how I write code. It's directly influenced a major open-source project I have developed [1]. But, unfortunately, I don't think I'll use it again for a pro project.

[1] https://github.com/louthy/language-ext

adastra223• 2 years ago

All bug reports are good. But is this not obvious? Do the Haskell developers not use other language ecosystems? This goes beyond “this edge case is difficult” and into “the whole tooling stack is infamously hard to work with.” I just assumed Haskell, like eMacs, attracted a certain kind of developer that embraced the warts.

mhitza3• 2 years ago

* It tends to have 'first error, breaks rest of compile' problems

`-fdefer-type-errors` will report those errors as warnings and fail at runtime, which is good when writing/refactoring code. Even better the Haskell LSP does this out of the box.

* The tooling, although significantly better than it was, is still poor compared to other some other functional languages, and really poor compared to mainstream languages like C#

Which other functional programming languages do you think have better tooling? Experimenting lately with OCaml, feels like Haskell's tooling is more mature, though OCaml's LSP starts up faster, almost instantly.

louthy12• 2 years ago

Which other functional programming languages do you think have better tooling?

F#, Scala

OCaml's LSP starts up faster

It was two years ago that I used Haskell last and the LSP was often crashing. But in general there were always lots of 'niggles' with all parts of the tool-chain that just killed developer flow.

As I state in a sibling comment, the tooling is on the right trajectory, it just isn't there yet. So, this isn't the main reason to not do Haskell.

lkmain2• 2 years ago

I haven't yet felt the need for third party tooling in OCaml. OCaml has real abstractions, easily readable modules and one can keep the whole language in one's head.

Usually people do not use objects, and if they do, they don't create a tightly coupled object mess that can only be unraveled by an IDE.

mattpallissard3• 2 years ago

Experimenting lately with OCaml, feels like Haskell's tooling is more mature.

I feel like OCaml has been on a fast upward trajectory the past couple of years. Both in terms of language features and tooling. I expect the developer experience to surpass Haskell if it hasn't already.

I really like Merlin/ocaml-lsp. Sure, it doesn't have every LSP feature like a tool with a lot of eyes on it, such as clangd, but it handles nearly everything.

And yeah, dune is a little odd, but I haven't had any issues with it in a while. I even have some curve-ball projects that involve a fair amount of C/FFI work.

My only complaint with opam is how switches feel a little clunky. But still, I'll take it over pip, npm, all day.

I've been using OCaml for years now and compared to most other languages, the experience has been pretty pleasant.

innocentoldguy• 2 years ago

Elixir’s tooling is awesome, in my opinion.

moomin2• 2 years ago

No lies detected. I love Haskell, but productivity is a function of the entire ecosystem, and it’s just not there compared to most mainstream languages.

gtf2124• 2 years ago

The library ecosystem is probably the biggest issue.

I'd love to know which things specifically you're thinking about. For what we've been building, the "integration" libraries for postgres, AWS, etc. have been fine for us, likewise HTTP libraries (e.g. Servant) have been great.

I haven't _yet_ encountered a library problem, so am just very curious.

chii2• 2 years ago

Probably referring to something like spring (for java), which is a one stop shop for everything, including things like integration with monitoring/analytics, rate-limiting, etc

louthy12• 2 years ago

The project was a cloud agnostic platform-as-a-service for building healthcare applications. It needed graph-DBs, Postgres, all clouds, localisation, event-streams, UIs, etc. I won't list where the problems were, because I don't think it's helpful -- each project has its own needs, you may well be lucky where we were not. Certainly the project wasn't a standard enterprise app, it was much more complex, so we had some foundational things we needed that perhaps your average dev doesn't need. However, other ecosystems would usually have a decent off-the-shelf versions, because they're more mature/evolved.

You have to realise that none of the problems were insurmountable, I had a talented team who could overcome any of the issues, it just became like walking through treacle trying to get moving.

And yes, Servant was great, we used that also. Although we didn't get super far in testing its range.

crote• 2 years ago

A few years ago I tried to use Servant to make a CAS[0] implementation for an academic project.

One issue I ran into was that Servant didn't have a proper way of overriding content negotiation: the CAS protocol specified a "?format=json" / "?format=xml" parameter, but Servant had no proper way of overriding its automatic content negotiation - which is baked deeply into its type system. I believe at the time I came across an ancient bug report which concluded that it was an "open research question" which would require "probably a complete rework".

Another issue was that Servant doesn't have proper integrated error handling. The library is designed around returning a 200 response, and provides a lot of tooling to make that easy and safe. However, I noticed that at the time its design essentially completely ignored failures! Your best option was basically a `Maybe SomeResponseType` which in the `None` case gave a 200 response with a "{'status': 'error'}" content. There was a similar years-old bug report for this issue, which is quite worrying considering it's not exactly rocket science, and pretty much every single web developer is going to run into it.

All of this gave a feeling of a very rough and unfinished library, whose author was more concerned about writing a research paper than actually making useful software. Luckily those issues had no real-world implication for me, as I was only a student losing a few days on some minor project. But if I were to come across this during professional software development I'd be seriously pissed, and probably write off the entire ecosystem: if this is what I can expect from "great" libraries, what does the average ones look like - am I going to have to write every single trivial thing from scratch?

I really love the core language of Haskell, but after running into issues like these a few dozen times I unfortunately have trouble justifying using it to myself. Maybe Haskell will be great five or ten years from now, but in its current state I fear it is probably best to use something else.

[0] https://en.wikipedia.org/wiki/Central_Authentication_Service

imoverclocked3• 2 years ago

I tried building a couple small projects to get familiar with the language.

One project did a bunch of calculation based on geolocation and geometry. I needed to output graphs and after looking around, reached for gnuplot. Turns out, it’s a wrapper around a system call to launch gnuplot in a child process. There is no handle returned so you can never know when the plot is done. If you exit as soon as the call returns, you get to race gnuplot to the temp file that gets automatically cleaned up by your process. The only way to eliminate the race is by sleeping… so if you add more plots, make sure you increase your sleep time too. :-/

Another utility was a network oriented daemon. I needed to capture packets and then run commands based on them… so I reached for pcap. It uses old bindings (which is fine) and doesn’t expose the socket or any way to set options for the socket. Long story short, it never worked. I looked at the various other interfaces around pcap but there was always a significant deficiency of some kind for my use case.

Now, I’m not a seasoned Haskell programmer by any means and it’s possible I am just missing out on something fundamental. However, it really looks to me like someone did a quick hack that worked for a very specific use-case for both of these libraries.

The language is cool but I’ve definitely struggled with libraries.

catgary4• 2 years ago

I kind of agree that Haskell missed its window, and a big part of the problem is the academic-heavy ecosystem (everyone is doing great work, but there is a difference between academic and industrial code).

I’m personally quite interested in the Koka language. It has some novel ideas (functional-but-in-place algorithms, effect-handler-aware compilation, it uses reference counting rather than garbage collection) and is a Microsoft Research project. It’s starting to look more and more like an actual production-ready language. I can daydream about Microsoft throwing support behind it, along with some tooling to add some sort of Koka-Rust interoperability.

the_duke• 2 years ago

Koka is indeed incredibly cool, but:

It sees sporadic bursts of activity, probably when an intern is working on it, and otherwise remains mostly dormant. There is no package manager that could facilitate ecosystem growth. There is no effort to market and popularize it.

I believe it is fated to remain a research language indefinitely.

pyrale7• 2 years ago

Most of your comments boil down to two items:

- The Haskell ecosystem doesn't have the budget of languages like Java or C# to build its tooling.

- The haskell ecosystem was innovative 20 years ago, but some newer languages like Rust or Elm have much better ergonomics due to learning from their forebearers.

Yes, it's true. And it's true for almost any smaller language out there.

troupo2• 2 years ago

Counterpoint: Elixir. While it sits on top of industrial-grade Erlang VM, the language itself produced a huge ecosystem of pragmatic and useful tools and libraries.

louthy12• 2 years ago

If you boil down my comments, sure, you could say that. But, that's why I didn't boil down my comments and used more words, because ultimately, it doesn't say that.

The thread is "Why Haskell?", I'm offering a counterpoint based on experience. YMMV and that's fine.

devjab2• 2 years ago

compared to mainstream languages like C#

Out of curiosity does this also hold true for F#?

louthy12• 2 years ago

F#’s tooling is worse than C# for sure, but it’s a big step-up from Haskell and has access to the .NET framework.

I listed C# because that’s the mainstream language I know the best, and arguably has best-in-class tooling.

Of course you have to be prepared to lose some of the creature comforts when using a more left-field language. But, you still need to be productive. The whole ecosystem has to be a net gain in productivity, or stability, or security, or maintainability — pick your poison depending on what matters to your situation.

I had hoped Haskell would pay dividends due to its purity, expressive type-system, battle tested-ness, etc. I expected us to be slower, just not as slow as it turned out.

Ultimately the trade off didn’t work for us.

ants_everywhere7• 2 years ago

I completely agree. I'm interested in making the Haskell tooling system better. I would welcome anyone with Haskell experience to let me know what you think would be the highest priority items here.

I'm also curious about the slowness of compilation and whether that's intrinsic to the design of GHC.

tome26• 2 years ago

I would welcome anyone with Haskell experience to let me know what you think would be the highest priority items here.

Simplifying cabal probably, though that's a system-level problem, just just a cabal codebase problem.

lemonwaterlime4• 2 years ago

The Brittany code fixer needs a maintainer. The previous one had to step away. It has a unique approach to code formatting that the ormolu/fourmolu formatters doesn’t. There’s lots of the philosophy and such in the docs.

I like it better than the ormolu family because it respects your placement of comments and just formats the code itself. But it isn’t maintained as of a few years ago.

https://hackage.haskell.org/package/brittany

cptwunderlich2• 2 years ago

The Haskell Language Server (LSP) always needs help: https://github.com/haskell/haskell-language-server/issues?q=...

As for GHC compile times... hard to say. The compiler does do a lot of things. Type checking and inference of a complex type system, lots of optimizations etc. I don't think it's just some bug/inefficient implementation, bc. resources have been poured into optimizations and still are. But there are certainly ways to improve speed. For single issues, check the bug-tracker: https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5...

For the big picture, maybe ask in the discourse[1] or the mailing list. If you want to contribute to the compiler, I can recommend that you ask for a gitlab account via the mailing list and introduce youself and your interests. Start by picking easy tickets - GHC is a huge codebase, it takes a while to get familiar.

Other than that, I'd say some of the tooling could use some IDE integration (e.g., VS Code plugins).

[1]...https://discourse.haskell.org/

drblue• 2 years ago

The highest priority is probably making real debugging tools. Right now, the only decent debugging tool is ghc-debug to connect to a live process, and doing anything over that connection is slow, slow, slow. ghc-debug was the only thing which was able to resolve a long standing thunk leak in one of my systems, and I know that unexplained thunk leak caused a previous startup I was at to throw away their Haskell code and rewrite it in Rust. In my case, it found the single place where I had said `Just $` instead of `Just $!` which I had missed the three times I had inspected the ~15k line program. ghc-debug still feels like a pre-alpha though, go compare it to VisualVM for what other languages have.

Also, I have found very little use for the various runtime flags like `+RTS -p`. These flags aren't serious debugging tools; I couldn't find any way to even trigger them internally at runtime around a small section, which becomes a problem when it takes 10 minutes to load data from disk when the profiler is on.

The debugging situation with Haskell is really, really bad and it's enough that I try to steer people away from starting new projects with the language.

robocat• 2 years ago

It is a shame that the article almost completely ignores the issue of the tooling. I particularly find the attitude in the following paragraph offensively academically true:

  All mainstream, general purpose programming languages are (basically) Turing-complete, and therefore any programme you can write in one you can, in fact, write in another. There is a computational equivalence between them. The main differences are instead in the expressiveness of the languages, the guardrails they give you, and their performance characteristics (although this is possibly more of a runtime/compiler implementation question).

I decided to have a go at learning the basics of Haskell and the first error I got immediately phased me because it reminded me of unhelpful compilers of the 80s. I have bashed my head against different languages and poor tooling enough times to know I can learn, but I've also done it enough times that I am unwilling to masochistically force myself through that gauntlet unless I have a very good reason to do so. The "joy" of learning is absent with unfriendly tools.

The syntax summary in the article is really good. Short and clear.

gtf2124• 2 years ago

It is a shame that the article almost completely ignores the issue of the tooling.

Mostly because while I found of the tooling occasionally difficult, I didn’t find Haskell particularly bad compared to other language ecosystems I’ve played with, with the exception of Rust, for which the compiler errors are really good.

The syntax summary in the article is really good

Thanks, I wasn’t so sure how to balance that bit.

samatman6• 2 years ago

All mainstream, general purpose programming languages are (basically) Turing-complete, and therefore any programme you can write in one you can, in fact, write in another.

That stuck out to me as well, I said out loud "that is a very Haskell thing to say". It would be more accurate to say that Turing Completeness means that any programme you write in one language, may be run in another language by writing an emulator for the first programme's runtime, and executing the first programme in the second.

Because it is not "in fact" the case that a given developer can write a programme in language B just because that developer can write the program in language A. It isn't even "in principle" the case, computability and programming just aren't that closely related, it's like saying anything you can do with a chainsaw you can do with a pocketknife because they're both Sharp Complete.

I shook it off and enjoyed the rest of the article, though. Haskell will never be my jam but I like reading people sing the virtues of what they love.

RandomThoughts33• 2 years ago

The Haskell community is also very opinionated when it comes to style and some of the choices are not to everyone taste. I’m mostly thinking of point-free being seen as an ideal and the liberal usage of operators.

ParetoOptimal4• 2 years ago

Point-free and liberal use of operators are and have long been minority viewpoints in Haskell.

I say this as someone who prefers symbols, point free, and highly appreciates "notation as a tool of thought".

tome26• 2 years ago

It tends to have 'first error, breaks rest of compile' problems

Sort of. It has a "failure at a stage prevents progress to next stage", so a parse error means you won't type check (or indeed, continue parsing). See these proposals for some progress on the matter

* https://github.com/haskellfoundation/tech-proposals/pull/63

* https://github.com/ghc-proposals/ghc-proposals/pull/333

louthy12• 2 years ago

I understand why it happens, but it's an absolute killer for refactoring.

I didn't mention refactoring in my list because it may just be personal experience: my style of coding is to write fearlessly knowing that I will also refactor fearlessly. So less upfront thinking, more brute force writing (on instinct) & aggressive refactoring. I find I get my solution much faster and it ends up being more elegant.

Having a parse error or a type inference error in another module causing all other inference to fail kills the refactoring part of that process where there are syntax/semantic errors everywhere for a period of time whilst I fix them up.

It's good to see the issue acknowledged and hopefully resolved in the future.

Additionally, it would be good to see some proper refactoring tooling. Renaming, moving types/functions from one module to another, etc.

nh23• 2 years ago

The compiler is slower than most mainstream language compilers

Depends on which mainstream languages one compares with; there's always C++.

My project here has 50k lines Haskell, 10k C++, 50k lines TypeScript (code-only, not comments). Counting user CPU time (1 core, Xeon E5-1650 v3 3.50GHz):

    TypeScript 123 lines/s
    Haskell     33 lines/s
    C++          7 lines/s

Liquid_Fire• 2 years ago

Can you clarify what "7 lines/s" means? Surely you are not saying that your 10k lines of C++ take more than 23 minutes to compile on a single core? Is it 10k lines of template spaghetti?

For comparison, I just compiled a 25k line .cpp (probably upwards of 100k once you add all the headers it includes) from a large project, in 15s. Admittedly, on a slightly faster processor - let's call it 30s.

andrewstuart• 2 years ago

Whenever I see Haskell stuff, Steve Yegge's famous 2010 blog post instantly comes to mind:

"Haskell Researchers Announce Discovery of Industry Programmer Who Gives a Shit"

http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

TacticalCoder• 2 years ago

It's a classic and Steve Yegge hasn't been nice to Haskell with that one. As a Java programmer I used to love an even older blog making fun of Java and its ecosystem called, IIRC, "The bile blog". It was trashy, mean, using lots of swear words and it was really good.

grumpyprole4• 2 years ago

And he got it completely wrong, as more and more Haskell features end up in industrial programming languages. Oracle's Java architect even publically stated he was influenced by Haskell.

mg• 2 years ago

TL/DR: Haskell makes you add more meta information to the code, so that compilers can reason about it.

One of the examples in the article:

Python:

    def do_something():
        result = get_result()
        if result != "a result":
            raise InvalidResultError(result)
        return 42

Haskell:

    doSomething :: Either InvalidResultError Int
    doSomething = 
        let result = getResult
            in if result /= "a result"
                then Left (InvalidResultError result)
                else Right 42

Personally, I prefer the Python version. In my experience, the benefits of adding meta information like types and possible return values are very small. Because the vast majority of time fixing problems in software development is spent on systematic bugs and issues, not on dealing with type errors.

catgary4• 2 years ago

Ok, your Haskell example is basically drawing your opponent in the wojack meme and declaring yourself the winner.

black_knight• 2 years ago

The point is that the Haskell type system is an expressive way of solving systematic bugs. You can express both the data itself and the valid ways of handling it using types, which gives you a space to design yourself out of systemic problems. And when something goes awry, the strict typing and control over side effects means that you can refactor fearlessly!

Re. the example, the compiler can infer types, and you can write almost the exact same code in Haskell as in Python:

    doSomething = do
       let result = getResult
       when (result /= "a result")
            (throwError $ InvalidResultError result)
       return 42

But as it has been noted, you are unlikely to find code like this in Haskell. An element of Either type at the top level, without arguments is either always going to be Left or always going to be Right, so it is a bit pointless. Since this example is so abstract it is hard to see what the idiomatic Haskell would be, because it would depend on the particulars.

gtf2124• 2 years ago

so that compilers can reason about it

Actually this is the wrong takeaway, I think it's so that programmers can reason about it.

This isn't about type errors, it's about precisely describing a particular computational expression. In the python example, it's very unclear what `do_something` actually _does_.

mmaniac• 2 years ago

Your criticism seems more general than just Python and Haskell. It's really about dynamic and static typing. That's a legitimate debate, but as far as static typing goes, Haskell has one of the best static systems around - and because of that, idiomatic Haskell is unlikely to look like the example you posted.

thesz• 2 years ago

the vast majority of time fixing problems in software development is spent on systematic bugs and issues, not on dealing with type errors.

You can make "systematic bugs and issues" a type errors, then deal with them as type errors.

If you can confuse between meters and seconds expressed as Double and erroneously add them, wrap them into types Meters and Seconds, autogenerate Num and other classes' implementations and voila, you cannot add Meters and Seconds anymore, you get type error.

I do that even in C++, if I use it for my personal projects. ;)

But where Haskell really shine is in effect control. You cannot open file and write into it during execution of transaction between threads. If you parse text, you also can restrict certain actions. There are many cases where you need control over effects, and Haskell gladly helps there.

bmacho2• 2 years ago

TL/DR: Haskell makes you add more meta information to the code, so that compilers can reason about it.

Actually Haskell lets you to add more meta information to the code, similar to modern Python or TypeScript. Type information is optional. But you might want to add it, it is helpful most of the times.

In the example, doSomething implicitly depends on getResult, which doesn't show up in the type information, so the type information only tells you how you can use doSomething. To know what is doSomething, you actually have to read the code :\

gtf2124• 2 years ago

I'm not sure that's entirely true (I wrote the examples): the point I'm trying to make is that you can precisely describe what `doSomething` consumes and produces (because it's pure) and you don't have to worry about what some nested function might throw or some side-effect it might perform.

lkmain2• 2 years ago

I prefer the Haskell version. One can read it as a full sentence instead of being interrupted by the boring imperative Python version that breaks the train of thought on every line.

cpa• 2 years ago

Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. The stateless nature of Haskell is something that many rediscover at different points in their careers. Eg in webdev, it's mostly about offloading state to the database and treating the application as "dumb nodes." That's what most K8s deployments do.

The type system in Haskell, particularly union types, is incredibly powerful, easy to understand for the most part (you don't need to understand monads that deeply to use them), and highly useful.

And I've had a lot of fun micro-optimizing Haskell code for Project Euler problems when I was studying.

Give it a try. Especially, if you don't know what to expect, I can guarantee that you'll be surprised!

Granted, the tooling is sh*t.

adastra223• 2 years ago

Haskell also changed the way I think about programming. But I wonder if it would have as much of an impact on someone coming from a language like Rust or even modern C++ which has adopted many of haskell’s features?

mmoll• 2 years ago

True. I often think of Rust as a best-of compilation of Haskell and C++ (although I read somewhere that OCaml had a greater influence on it, but I don’t know that language well enough)

In real life, I find that Haskell suffers from trying too hard to use the most general concept that‘s applicable (no pun intended). Haskell programs happily use “Either Err Val” and “Left x” where other languages would use the more expressive but less general “Result Err Val” and “Error x”. Also, I don’t want to mentally parse nested liftM2s or learn the 5th effect system ;-)

setopt3• 2 years ago

I think it does, actually. Python also has many of Haskell's features (list comprehensions, map/filter/reduce, itertools, functools, etc.). But I only started reaching for those features after learning about them in Haskell.

In Python, it's very easy to just write out a for-loops to do these things, and you don't necessarily go looking for alternative ways to do these things unless you know the functional equivalents already. But in Haskell you're forced to do things this way since there is no for-loop available. But after learning that way of thinking, the result is then more compact code with arguably less risk of bugs.

odyssey73• 2 years ago

Check out Swift, too!

TylerE2• 2 years ago

Heck, even coming from Python (2) it felt very underwhelming and hugely oversold. (Edit: To be fair, I'd done a bit of Ocaml years earlier so algebraic data types weren't some huge revelation).

Laziness is mostly an anti-pattern.

gtf2124• 2 years ago

Granted, the tooling is sh*t.

I hear this a lot, but am curious about two things: (a) which bit(s) of the toolchain are you thinking about specifically -- I know HLS can be quite janky but I haven't really been blocked by any tooling problems myself; (b) have you done much Haskell in production recently -- i.e. is this scar tissue from some ago or have you tried the toolchain recently and still found it to be lacking?

n_plus_1_acc2• 2 years ago

Everytime I use cabal and/or stack, it gives me a wall of errors and i just reinstall everyrhing all the time.

moomin2• 2 years ago

Sum types are finally coming to C#. That’ll make it the first “Mainstream” language to adopt them. Will it be as solid and simple as Haskell’s implementation? Of course not. Will having a backing ecosystem make up for that deficiency? Yes.

n_plus_1_acc2• 2 years ago

Rust is mainstream, just not use in enterprise applications

SkiFire132• 2 years ago

What counts as mainstream for you?

Java has recently added sealed classes/interfaces which offer the same features as sum types, and I would argue that Java is definitely mainstream.

Kotlin has a similar feature. It might be used less than Java, but it's the default language for Android.

Swift has `enum` for sum types and is the default language for iOS and MacOS.

Likewise for Rust, which is gaining traction recently.

Typescript also has union/sum types and is gaining lot of traction.

pjmlp• 2 years ago

Not really, other mainstream languages got there first.

pid-12• 2 years ago

Python has sum types

optional_int: int | None = None

setopt3• 2 years ago

Haskell has had a profound impact on the way I think about programming and how I architect my code and build services.
And I've had a lot of fun micro-optimizing Haskell code for Project Euler problems when I was studying.

Sounds a lot like my experience. I never really used Haskell for "real work", where I need support for high-performance numerical calculations that is simply better in other languages (Python, Julia, C/C++, Fortran).

But learning functional programming through Haskell – mostly by following the "Learn you a Haskell" book and then spending time working through Project Euler exercises using it – had a quite formative effect on how I write code.

I even ended up baking some functional programming concepts into my Fortran code later. For instance, I implemented the ability to "map" functions on my data structures, and made heavy use of "pure functions" which are supported by the modern Fortran standard (the compiler then checks for side effects).

It's however hard to go all the way on functional programming in HPC contexts, although I wish there were better libraries available to enable this.

nextos3• 2 years ago

But learning functional programming through Haskell [...] had a quite formative effect on how I write code.

I think it is a shame Haskell has gained a reputation of being hard, because it can be an enriching learning experience. Lots of its complexity is accidental, and comes from the myriad of language extensions that have been created for research purposes.

There was an initiative to define a simpler subset of the language, which IMHO would have been great, but it didn't take off: https://www.simplehaskell.org. Ultimately, one can stick to Haskell 98 or Haskell 2010 plus some newer cherry-picked extensions.

l5870uoo9y• 2 years ago

Pure functions are a crazy useful abstractions. Complex business logic? Extract it into a type-safe pure function. Still to "unsafe"? Testing pure functions are fast and simple. Unclear what a complex function does? Extract it into meaningful pure functions.

ayakang31415• 2 years ago

Haskell sounds like a good language to hone your programming skills. What kind of projects is Haskell suited for to get started (besides Euler project)? I use Python primarily for scientific research (mostly numerical computation).

jillesvangurp4• 2 years ago

I think the tooling being not ideal is a reflection of how mature/serious the community is about non academic usage. Haskell has been around for ages but it never really escaped its academic nature. I actually studied in Utrecht in the nineties where there was a lot of activity around this topic at the time. Eric Meyer who later created F# at MS was a teacher there and there was a lot of activity around doing stuff with Gopher which is a Haskell predecessor, which I learned and used at the time. All our compiler courses were basically fiddling with compiler generator frameworks that came straight out of the graduate program. Awesome research group at the time.

My take on this is that this was all nice and interesting but a lot of this stuff was a bit academic. F# is probably the closest the community got to having a mature tooling and developer ecosystem.

I don't use Haskell myself and have no strong opinions on the topic. But usually a good community response to challenges like this is somebody stepping up and doing something about it. That starts with caring enough. If nobody cares, nothing happens.

Smalltalk kicked off a small tool revolution in the nineties with its refactoring browser. Smalltalk was famous for having its own IDE. That was no accident. Alan Kay, who was at Xerox PARC famously said that the best way to predict the future was to invent it. And of course he was (and is) very active in the Smalltalk community and its early development. Smalltalk was a language community that was from day one focused on having great tools. Lots of good stuff came out of that community at IBM (Visual Age, Eclipse) and later Jetbrains and other IDE makers.

Rust is a good recent example of a community that's very passionate about having good tools as well. Down to the firmware and operating system and everything up. In terms of IDE support they could do better perhaps. But I think there are ongoing efforts on making the compiler more suitable for IDE features (which overlap with compiler features). And of course Cargo has a good reputation. That's a community that cares.

I use Kotlin myself. Made by Jetbrains and heavily used in their IDEs and toolchains. It shows. This is a language made by tool specialists. Which is why I love it. Not necessarily for functional purists. Even though som Scala users have reluctantly switched to it. And the rest is flirting with things like Haskel and Elixir.

odyssey73• 2 years ago

“Greece, Rome’s captive, took Rome captive.”

The languages of engineering-aligned communities may appear to have won the race, though they have been adopting significant ideas from Haskell and related languages in their victories.

pyrale7• 2 years ago

I think the tooling being not ideal is a reflection of how mature/serious the community is about non academic usage.

I'd say it's more of a reflection of how having a very big company funding the language is making a difference.

People like to link Haskell's situation to its academic origins, but in reality, most of the issues with the ecosystem are related to acute underfunding compared to mainstream languages.

Nelkins• 2 years ago

Pretty sure F# was created by Don Syme, not Erik Meijer.

cies4• 2 years ago

Haskell has had a profound impact on the way I think about programming and how I architect my code and build services.

Exactly the same for me.

Granted, the tooling is sh*t.

Stack and Stackage (one of the package managers and library distribution systems in Haskell-land) is the best I found in any language.

Other than that I also found some tools to be lacking.

dario_od• 2 years ago

What makes you say that stack is the best you found in any language? I use it daily, and in my experience I'd put it just a bit above PHP's composer

0x3444ac53• 2 years ago

Would you mind explaining what you mean by stateless?

jgwil22• 2 years ago

Haskell functions are pure, like mathematical functions: the same input to a function produces the same output every time, regardless of the state of the application. That means the function cannot read or write any data that is not passed directly to it as an argument. So the program is "stateless" in that the behavior does not depend on anything other than its inputs.

This is valuable because you as the developer have a lot less stuff to think about when you're trying to reason about your program's behavior.

BoiledCabbage2• 2 years ago

Give it a try. Especially, if you don't know what to expect, I can guarantee that you'll be surprised!

And I will as strongly as possible emphasize the opposite you should not.

If you are are already experienced in functional programming, as well as in statically typed functional programming or something lovely in the ML family of languages then only then does Haskell make sense to learn.

If you are looking to learn about either FP in general, or staticly typed FP Haskell is about the single worst language anyone can start with. More people have been discouraged from using FP because they started with Haskell than is probably appreciated. The effort to insight ratio for Haskell is incredibly high.

You can learn the majority of the concepts faster in another language with likely 1/10th the effort. For general FP learn clojure, Racket, or another scheme. For statically typed FP learn F# or Scala or OCAML or even Elm.

In fact if you really want to learn Haskell is is faster to learn Elm and then Haskell than it is to just learn Haskel. Because the amout or weeds you have to navigate through to get to the concepts in Haskell are so high that you can first learn the concepts and approach in a tiny language like Elm and it will more than save the amount of time it would take to understand those approaches from trying to learn Haskell. It seems unbelievable but ai found it to be very try. You can learn two languages faster than just one because of how muddy Haskell is.

Now that said FP is valuable and in my opinion a cleaner design and why in general our industry keeps shifting that way. Monoids, Functors, Applicative are nice design patterns. Pushing side effects to the edge of your code (which is enforced by types) is a great practice. Monads are way overhyped, thinking in types is way undervalued. But you can get all of these concepts without learning Haskell.

So that's the end of my rant as I've grown tired of watching people dismiss FP because they confuse the great concepts of FP with the horrible warts that come with Haskell.

Haskell is a great language, and I'm glad I learned it (and am in no way an expert at it)- but it is the single worst language for an introduction to FP concepts. If you're already deep in FP it's and awesome addition to your toolbox of concepts and for that specific purpose I highly recommend it.

And finally, LYAH is a terrible resource.

the_af7• 2 years ago

And finally, LYAH is a terrible resource.

Could you elaborate? I know LYAH doesn't teach enough to write real programs, and does not introduce necessary concepts such as monad transformers, but why is it so terrible as an introduction to Haskell and FP? (In my mind, incomplete/flawed != terrible... Terrible means "avoid at all costs").

As for your overall point, I remember articles posted here on HN about someone teaching Haskell to children (no prior exposure to any other prog lang) with great success.

dietlbomb• 2 years ago

Is it worth learning JavaScript before learning Elm?

scotty792• 2 years ago

Unlearning and relearning

Interesting how, when encountering Rust, I didn't have to unlearn reference based programming, just learn value based programming. Somehow pure functional language advocates insist you are doing things wrong and need to unlearn it first. Kind of reminds me of a sect that promises you great things if only you work hard on leaving all your prior life behind.

gtf2124• 2 years ago

I think there are more fundamental differences between functional and imperative programming paradigms (or, perhaps, declarative and imperative programming styles?) than between passing by reference and passing by value (after all, variables are just references, filesystems have links, it just doesn't seem that unfamiliar).

I have definitely seen people struggle to wrap their head around declaring expressions representing what they want to compute when they are very used to imperative control flow like mutating some state while iterating through a loop.

Kind of reminds me of a sect that promises you great things if only you work hard on leaving all your prior life behind.

I think this is sort of saying "hey this one thing looks like this other thing I don't like, therefore it must carry all the same problems". Perhaps we can call it "the duck type fallacy", but I don't think it's true to say that "anything which tries to change paradigm" is equivalent to cults.

chii2• 2 years ago

definitely seen people struggle to wrap their head around...

I think it's a top-down vs bottoms-up approach to solving a problem.

Most people actually think in terms of top-down. They break a problem down into smaller sub-problems, which they then either break down more or has done sufficient breaking down to solve it.

I think functional style of thinking would make you do a bottoms-up approach to problem solving. You will create a very small solution (function) to solve a very trivial version/type of the problem, then repeat for each small thing. Once you have sufficient number of basic functions written, you can assemble them into solving a bigger problem.

scotty792• 2 years ago

after all, variables are just references

That's the whole point of Rust, that they are not that. They are named, sized memory slots that values can be moved into or moved out of.

I have definitely seen people struggle to wrap their head around ...

The struggle comes from being forced to use recursion where it doesn't make things easier to express but harder. Then they remember it all compiles down to machine code that just uses iteration fueled by bare metal equivalent of goto-s and the struggle feels pointless.

Imagine somebody took away your stack so when you want to do recursion, you'd be forced to roll your own stack every time. You'd struggle too.

fbn793• 2 years ago

We need a language with Haskell syntax, Rust memory management and Typescript toolchain/ecosystem :))

joelthelion• 2 years ago

I'd argue the syntax is the worst part of haskell. In particular, the lack of object notation for accessing fields (e.g. car.doors) is particularly frustrating.

I still love the language, BTW.

gtf2124• 2 years ago

You can have that syntax if you want it via `OverloadedRecordDot`.

I actually really like the syntax as it makes it easy to write DSLs which are actually just Haskell functions.

rebeccaskinner8• 2 years ago

There is an extension that lets you do this now (OverloadedRecordDotSyntax) but truthfully I think it’s a really bad idea. The (.) operator already has a very concrete meaning in Haskell, and record dot notation means that you suddenly need to care about the specific details of how values are calculated. Field accessor functions are much better imo even if they seem a little odd.

swiftcoder2• 2 years ago

I feel like you've specifically picked the worst part of each language here.

Haskell's syntax, like many FP syntaxes, is inscrutable on first acquaintance. There's a reason hybrid languages like Elixir thrive...

Rust's memory management is a great boon for a close-to-the-metal language, but if all your types are immutable you don't actually need/want to deal with the borrow checker.

Typescripts toolchain and ecosystem are... ok, at best? I'd give a solid pitch for the Rust ecosystem having reproduced the best parts thereof (and there is still room for improvement even so)

fbn793• 2 years ago

Haskell have a garbage collector (and it have a lot or work to do). So even if you are in the context of immutability, if you don't want a gc, you still need to take care of memory yourself using RAII like Rust or any other low level technique. About syntax for me haskell is beautiful. But maybe it's just my love for having type notation aside from function declaration and not mixed.

empath75• 2 years ago

I think you just want Rust.

You can write extremely haskell-like code with Rust.

Here's the first example in rust:

    fn safe_head<T>(list: &[T]) -> Option<&T> {
        match list {
            [first, ..] => Some(first),  
            [] => None,                  
        }
    }

    fn print_the_first_thing(my_list: &[String]) {
        match safe_head(my_list) {
            Some(something) => println!("{}", something),
            None => println!("You don't have any favourite things? How sad."),
        }
    }

    fn main() {
        let my_favourite_things = vec!["raindrops on roses".to_string(), "whiskers on kittens".to_string()];
        let empty_list: Vec<String> = vec![];

        print_the_first_thing(&my_favourite_things);
    
        print_the_first_thing(&empty_list);
    }

(of course Rust has a lot of helper functions that avoid all that verbosity -- you can do the whole thing in one expression, if you want)

    println!(
        "{}",
        my_favourite_things.get(0).map_or(
            "You don't have any favourite things? How sad.".to_string(),
            |something| something.to_string()
        )
    );

rebeccaskinner8• 2 years ago

Haskell has linear types now, which can give you something similar to rusts affine types. The library ecosystem for it isn’t very mature yet though.

Mikhail_K6• 2 years ago

Haskell programs are hard to read and hard to reason about. That is the reason the language is not very practical.

The promise "if Haskell program compiles, it is probably correct" have not materialized. The most popular Haskell project Pandoc has 1000 open issues.

grumpyprole4• 2 years ago

This is a poor and lazy criticism of Haskell. It might be hard to reason about the memory usage and other operational behaviours of a Haskell program, but the ability to reason about semantics and correctness is far ahead of the mainstream. It actually supports equational reasoning. It has statically checked effect tracking, checked encapsulation of mutable state and much more. There is no all powerful pervasive "ambient monad" that lets code do absolutely anything.

Mikhail_K6• 2 years ago

It might be hard to reason about the memory usage and other operational behaviours of a
Haskell program, but the ability to reason about semantics and correctness is far ahead
of the mainstream.

For any practical program, memory usage and number of operations are part of the engineering specification and no one will deem correct a program that exceeds those specifications. So you just confirmed “impractical”, “academic” and “niche” charges.

It actually supports equational reasoning.

TLDR: to understand what a Haskell 5-liner does, you sometimes have to read a paper. Are you actually disputing “impractical” and “academic” labels, or saying that those _good_ things?

kreyenborgi3• 2 years ago

Haha those issues are things like "LaTeX to HTML conversion: \\label and \\ref work for figures but not equations" which I mean how on earth is that related to what language pandoc was created in ... I'm guessing the number of issues are because of pandoc's popularity and insane scope.

Mikhail_K6• 2 years ago

So you're saying that pandoc is correct in academic, but not practical sense?

bwidlar• 2 years ago

An implementation of an extended subset of Haskell. It uses combinators for the runtime execution:

https://github.com/augustss/MicroHs

https://www.youtube.com/watch?app=desktop&v=uMurx1a6Zck&t=36...

tromp• 2 years ago

An even more minimal Haskell compiler and combinatory logic runtime won in the 26th IOCCC:

https://crypto.stanford.edu/~blynn/compiler/ioccc.htm

Coolbeanstoo• 2 years ago

I would like to use haskell or another functional language professionally.

I try them out (ocaml,haskell,clojure,etc) from time to time and think they're fairly interesting, but i struggle to figure out how to make bigger programs with them as I've never seen how you build up a code base with the tools they provide and with someone to review the code i produce and so never have any luck with jobs i've applied to.

On the flipside I never had too much trouble figuring out how to make things with Go, as it has so little going on and because it was the first language i worked with professionally for an extended period of time. I think that also leads me to trying to apply the same patterns because I know them even if they dont really work in the world of functional languages

Not sure what the point of this comment is, but I think i just want to experience the moment of mind opening-ness that people talk about when it comes to working with these kinds of languages on a really good team

cosmic_quanta5• 2 years ago

I have also initially struggled with structuring Haskell programs. Without knowing anything about what you want to do, here's my general approach:

1. Decide on an effect system

Remember, Haskell is pure, so any side-effect will be strictly explicit. What broad capabilities do you want? Usually, you need to access some program-level configuration (e.g. command-line options) and the ability to do IO (networking, reading/writing files, etc), so most people start with that.

https://tech.fpcomplete.com/blog/2017/06/readert-design-patt...

2. Encode your business logic in functions (purely if possible)

Your application does some processing of data. The details don't matter. Use pure functions as much as possible, and factor effectful computations (e.g. database accesses) out into their own functions.

3. Glue everything together in a monadic context

Once you have all your business logic, glue everything together in a context with your effect system (usually a monad stack using ReaderT). This is usually where concurrency comes in (e.g. launch 1 thread per request).

---

Beyond this, your application design will depend on your use-case.

If you are interested, I strongly suggest to read 'Production Haskell' by Matt Parsons, which has many chapters on 'Haskell application structure'.

solomonb7• 2 years ago

1. Decide on an effect system

This shouldn't even be proposed as a question to someone new to Haskell. They should learn how monad transformers work and just use them. 90% of developers playing around effect systems would be just fine with MTL or even just concrete transformers. All Haskell effect systems should be considered experimental at this point with unclear shelf lives.

Everything else you said I agree with as solid advice!

jsbg• 2 years ago

This is excellent advice that unfortunately seems to get lost in a lot of Haskell teachings. I learned Haskell in school but until I had to use it professionally I would have never been able to wrap my head around effect systems. I still think that part of Haskell is unfortunate as it can get in the way of getting things done if you're not an expert, but being able to separate pure functions from effectful ones is a massive advantage.

bedman123453• 2 years ago

I’ve been working with pure functional languages and custom lisp dialects professionally my whole tenure. You get a whole bag of problems for a very subjective upside. Teams fragment into those that know how to work with these fringe tools and those who don’t. The projects using them that I worked on all had trouble with getting/retaining people. They also all had performance issues and had bugs like all other software. You’re not missing out on anything.

zelphirkalt• 2 years ago

Many problems stem from people not being willing to learn another paradigm of computer programming. Of course teams will split, if some people are not willing to learn, because then some will be unable to work on certain things, while other will be able to do so.

You mention performance. However, if we look at how many Python shops there are, this can hardly be a problem. I imagine ecosystems to be a much bigger issue than performance. Many implementations of functional languages have better performance than Python anyway.

There are many reasons why a company can have issues retaining people. A shitty uninteresting product, bad management, low wages, bad culture ... Lets eliminate those and see whether they still have issues retaining devs. I suspect, that an interesting tech stack could make people stay, because it is not so easy to find a job with such a tech stack.

However, many companies want easily replaceable cogs, which FP programmers are definitely not these days. So they would rather hire low skill easily replaceable than highly skilled but more expensive workforce. They know they will not be able to retain the highly skilled, because they know their other factors are not in line for that.

MetaWhirledPeas• 2 years ago

Teams fragment into those that know how to work with these fringe tools and those who don’t.

So the teams self-select to let you work with the people you want to work with? Tell me more!

mattgreenrocks• 2 years ago

I've used Haskell professionally for two years. It is the right pick for the project I'm working on (static analysis). I'm less sold on the overall Haskell ecosystem, tooling, and the overall Haskell culture.

There are still plenty of ways to do things wrong. Strong types don't prevent that. Laziness is a double-edged sword and can be difficult to reason about.

jerf2• 2 years ago

People love to talk about the upsides and the fun and what you can learn from Haskell.

I am one of these people.

People are much more reluctant to share what it is that led them to the conclusion that Haskell isn't something they want to use professionally, or something they can't use professionally. It's a combination of things, such as it just generally being less energizing to talk about that, and also some degree of frankly-justified fear of being harassed by people who will argue loudly and insultingly that you just Don't Get It.

I am not one of those people.

I will share the three main reasons I don't even consider it professionally.

First, Hacker News has a stronger-than-average egalitarian streak and really wants to believe that everybody in the world is already a developer with 15 years of experience and expert-level knowledge in all they survey from atop their accomplished throne, but that's not how the real world works. In the real world I work with coworkers who I have to train why in my Go code, a "DomainName" is a type instead of just a string. Then, just as the light bulb goes off, they move on from the project and I get the next junior dev who I have to explain it to. I'm hardly going to get to the point where I have a team of people who are Haskell experts when I'm explaining this basic thing over and over.

And, to be 100% clear, this is not their "fault", because being a junior programmer in 2024 is facing a mountain of issues I didn't face at their age: https://news.ycombinator.com/item?id=33911633 I wasn't expected to know about how to do source control or write everything to be rollback-able or interact with QA, or, well, see linked post for more examples. Haskell is another stack of requirements on top of a modern junior dev that is a hell of an ask. There better be some damn good reasons for me to add this to my minimim-viable developer for a project. I am not expressing contempt for the junior programmers here from atop my own lofty perch; I am encouraging people to have sympathy with them, especially if you also come up in the 90s when it was really relatively easy, and to make sure you don't spec out projects where you're basically pulling the ladder up after yourself. You need to have an onboarding plan, and "spend a whole bunch of time learning Haskell" is spending a lot of your onboarding plan currency.

Second, while a Haskell program that has the chef's kiss perfect architecture is a joy to work with, it is much more difficult to get there for a real project. When I was playing with Haskell it was a frequent occurrence to discover I'd architected something wrong, and to essentially need to rewrite the whole program, because there is no intermediate functioning program between where I was and where I needed to be. The strength of the type system is a great benefit, but it does not put up with your crap. But "your crap" includes things like being able to rearchitect a system in phases, or partially, and still have a functioning system, and some other things that are harder to characterize but you do a lot of without even realizing it.

I'd analogize it to a metalworker working with titanium. If you need it, you need it. If you can afford it, great. The end result is amazing. But it's a much harder metal to work with for the exact same reason it's amazing. The strength of the end part is directly reflected in the metal resisting you working with it.

I expect at a true expert level you can get over this, but then as per my first point, demanding that all my fellow developers become true experts in this obscure language is taking it up another level past just being able to work in it at all.

Finally, a lot of programming requirements have changed over the years. 10-15 years ago I could feasibly break my program into a "functional core" and an external IO system. This has become a great deal less true, because the baseline requirement for logging, metrics, and visibility have gone up a lot, and suddenly that "pure core" becomes a lot less appealing. Yes, of course, our pure functions could all return logs and metrics and whathaveyou, and sure, you can set up the syntax to the point that it's almost tolerable, but you're still going to face issues where basically everything is now in some sort of IO. If nothing else, those beautiful (Int -> Int -> Int) functions all become (Int -> Int -> LoggingMetrics Int) and now it isn't just that you "get" to use monadic interfaces but you're in the LoggingMetrics monad for everything and the advantages of Haskell, while they do not go away entirely, are somewhat mitigated, because it really wants purity. It puts me halfway to being in the "imperative monad" already, and makes the plan of just going ahead and being there and programming carefully a lot more appealing. Especially when you combine that with the junior devs being able to understand the resulting code.

In the end, while I still strongly recommend professional programmers spend some time in this world to glean some lessons from it that are much more challenging to learn anywhere else, it is better to take the lessons learned and learn how to apply them back into conventional languages than to try to insist on using the more pure functional languages in an engineering environment. This isn't even the complete list of issues, but they're sufficient to eliminate them from consideration for almost every engineering task. And in fact every case I have personally witnessed where someone pushed through anyhow and did it, it was ultimately a business failure.

cosmic_quanta5• 2 years ago

I'd analogize it to a metalworker working with titanium. If you need it, you need it. If you can afford it, great. The end result is amazing. But it's a much harder metal to work with for the exact same reason it's amazing.

What a beautiful, succinct analogy. I'm stealing this.

ninetyninenine2• 2 years ago

I'd analogize it to a metalworker working with titanium. If you need it, you need it. If you can afford it, great. The end result is amazing. But it's a much harder metal to work with for the exact same reason it's amazing. The strength of the end part is directly reflected in the metal resisting you working with it.

I’d say you missed one of the main points of Haskell and functional programming in general.

The combinator is the most modular and fundamental computational primitive available in programming. When you make a functional program it should be constructed out of the composition of thousands of these primitive with extremely strict separation from IO and multiple layers of abstraction. Each layer is simply composed functions from the layer below.

If you think of fp programming this way. It becomes the most modular most reconfigurable programming pattern in existence.

You have access to all layers of abstraction and within each layer are independent modules of composed combinators. Your titanium is given super powers where you can access the engine, the part, the molecule and the atom.

All the static safety and beauty Haskell provides is actually a side thing. What Haskell and functional programming in general provides is the most fundamental and foundational way to organize your program such that any architectural change only requires you replacing and changing the minimum amount of required modules. Literally the opposite of what you’re saying.

The key is to make your program just a bunch of combinators all the way down with an imperative io shell that is as thin as possible. This is nirvana of program organization and patterns.

rebeccaskinner8• 2 years ago

I’ve been using Haskell professionally off and on, along with other languages, since 2008. Professional experience certainly will help you learn some patterns, but honestly my best advice for structuring programs is to not think too hard about it.

Use modules as your basic unit of abstraction. Don’t go out of your way to make their organization over-engineered, but each module should basically do one thing, and should define everything it needs to do that thing (types, classes, functions).

Use parametric polymorphism as much as you can, without making the code too hard to read. Prefer functions and records over type classes as much as possible. Type classes that only ever have a single instance, don’t have laws, or type classes defined for unit data types are major code smells.

Don’t worry about avoiding IO, but as much as you can try to keep IO code separate from pure code. For example, if you need to read a value from the user, do some calculations, then print a message, it’s far better to factor the “do some calculations” part out into a pure function that takes the things you read in as arguments and returns a value to print. It’s really tempting to interleave logic with IO but you’ll save so much time, energy, and pain if you avoid this.

Essentially, keep things as simple as you can without getting belligerent about it. The type system will help you a lot with refactoring.

Start at the beginning. Write functions. When you see some piece of functionality that you need, use `undefined` to make a placeholder function. Then, go to your place holder and start implementing it. Use undefined to fill in bits that you need, and so on.

Fancy types are neat but it’s easy to end up with a solution in search of a problem. Avoid them until you really have a concrete problem that they solve- then embrace them for that problem (and only that problem).

You’ll refactor a lot, and learn to have a better gut feeling for how to structure things, but that’s just the process of gaining experience. Leaning into the basics of FP (pure functions, composed together) will be the path of least resistance as you are getting there.

axilmar• 2 years ago

My question for Haskellers is how to do updates of values on a large scale, let's say in a simulation.

In imperative languages, the program will have a list of entities, and there will be an update() function for each entity that updates its state (position, etc) inline, i.e. new values are overwriten onto old values in memory, invoked at each simulation step.

In Haskell, how is that handled? do I have to recreate the list of entities with their changes at every simulation step? does Haskell have a special construct that allows for values to be overwritten, just like in imperative languages?

Please don't respond with 'use the IO monad' or 'better use another language because Haskell is not up for the task'. I want an actual answer. I've asked this question in the past in this and some other forums and never got a straight answer.

If you reply with 'use the IO monad' or something similar, can you please say if whatever you propose allows for in place update of values? It's important to know, for performance reasons. I wouldn't want to start simulations in a language that requires me to reconstruct every object at every simulation step.

I am asking for this because the answer to 'why Haskell' has always been for me 'why not Haskell: because I write simulations and performance is of concern to me'.

bedman123453• 2 years ago

An example of how to use the io monad for simulations https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It’s one of the nicer to read ones I’ve seen. Still is terrible imo.

gspr• 2 years ago

Use the ST monad? :)

louthy12• 2 years ago

In your imperative language, imagine this:

    World simulation(Stream<Event> events, World world) =>
       events.IsComplete
           ? world
           : simulation(applyEventToWorld(events.Head, world), events.Tail);

    World applyEventToWorld(Event event, World world) =>
       // .. create a new World using the immutable inputs

That takes the first event that arrives, transforms the World, then recursively calls itself with the remaining events and the transformed World. This is the most pure way of doing what you ask. Recursion is the best way to 'mutate', without using mutable structures.

However, there are real mutation constructs, like IORef [1] It will do actual in-place (atomic) mutation if you really want in-place updates. It requires the IO monad.

[1] https://hackage.haskell.org/package/base-4.20.0.1/docs/Data-...

lieks• 2 years ago

You... don't. You have to rely on compiler optimizations to get good performance.

Monads are more-or-less syntax sugar. They give you a structure that allows these optimizations more easily, and also make the code more readable sometimes.

But in your example, update returns a new copy of the state, and you map it over a list for each step. The compiler tries to optimize that into in-place mutation.

IMO, having to rely so much on optimization is one of the weak points of the language.

kreetx2• 2 years ago

You do, and you'll have to use do destructive updates within either ST or IO monad using their respective single variable or array types. It looks roundabouty, but does do the thing you want and it is fast.

ST and IO are "libraries" though, in the sense that they not special parts of the language, but appear like any other types.

whateveracct7• 2 years ago

Fast immutable data structures don't rely on compiler optimizations. They just exist lol.

tikhonj• 2 years ago

I mean, Haskell has mutable vectors[1]. You can mutate them in place either in the IO monad or in the ST monad. They fundamentally work the same way as mutable data structures in any other garbage collected language.

When I worked on a relatively simple simulation in Haskell, that's exactly what I did: the individual entities were immutable, but the state of the system was stored in a mutable vector and updated in place. The actual "loop" of the simulation was a stream[2] of events, which is what managed the actual IO effect.

My favorite aspect of designing the system in Haskell was that I could separate out the core logic of the simulation which could mutate the state on each event from observers which could only read the state on events. This separation between logic and pure metrics made the code much easier to maintain, especially since most of the business needs and complexity ended up being in the metrics rather than the core simulation dynamics. (Not to say that this would always be the case, that's just what happened for this specific supply chain domain.)

Looking back, if I were going to write a more complex performance-sensitive simulation, I'd probably end up with state stored in a bunch of different mutable arrays, which sounds a lot like an ECS. Doing that with base Haskell would be really awkward, but luckily Haskell is expressive enough that you can build a legitimately nice interface on top of the low-level mutable code. I haven't used it but I imagine that's exactly what apces[3] does and that's where I'd start if I were writing a similar sort of simulation today, but, who knows, sometimes it's straight-up faster to write your own abstractions instead...

[1] https://hackage.haskell.org/package/vector-0.13.1.0/docs/Dat...

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

[3] https://hackage.haskell.org/package/apecs

whateveracct7• 2 years ago

apecs is really nice! it's not without its issues, but it really is a sweet library. and some of its issues are arguably just issues with ECS than apecs itself.

icrbow2• 2 years ago

does Haskell have a special construct that allows for values to be overwritten

Yes and no.

No, the language doesn't have a special construct. Yes, there are all kinds of mutable values for different usage patterns and restrictions.

Most likely you end up with mutable containers with some space reserved for entity state.

You can start with putting `IORef EntityState` as a field and let the `update` write there. Or multiple fields for state sub-parts that mutate at different rates. The next step is putting all entity state into big blobs of data and let entities keep an index to their stuff inside that big blob. If your entities are a mishmash of data, then there's `apecs`, ECS library that will do it in AoS way. It even can do concurrent updates in STM if you need that.

Going further, there's `massiv` library with integrated task supervisor and `repa`/`accelerate` that can produce even faster kernels. Finally, you can have your happy Haskell glue code and offload all the difficult work to GPU with `vulkan` compute.

icrbow2• 2 years ago

ECS library that will do it in AoS way

TLAs aren't my forte. It's SoA of course.

contificate• 2 years ago

I have a rather niche theory that many Hindley-Milner type inference tutorials written by Haskellers insist on teaching the error-prone, slow, details of algorithm W because otherwise the authors would need to commit to a way to do destructive unification (as implied by algorithm J) that doesn't attract pedantic criticism from other Haskellers.

For me, I stopped trying to learn Haskell because I couldn't quite make the jump from writing trivial (but neat) little self-contained programs to writing larger, more involved, programs. You seem to need to buy into a contorted way of mentally modelling the problem domain that doesn't quite pay off in the ways advertised to you by Haskell's proponents (as arguments against contrary approaches tend to be hyperbolic). I'm all for persistent data structures, avoiding global state, monadic style, etc. but I find that OCaml is a simpler, pragmatic, vehicle for these ideas without being forced to bend over backwards at every hurdle for limited benefit.

throwaway81523• 2 years ago

Well what kind of values and how many updates? You might have to call an external library to get decent performance, like you would use NumPy in Python. This might be of interest: https://www.acceleratehs.org/

mrkeen11• 2 years ago

My question for Haskellers is how to do updates of values on a large scale, let's say in a simulation.

The same way games do it. The whole world, one frame at a time. If you are simulating objects affected by gravity, you do not recalculate the position of each item in-place before moving onto the next item. You figure out all the new accelerations, velocities and positions, and then apply them all.

tome26• 2 years ago

I'm not sure why you say not to respond with 'use the IO monad' because that's exactly how you'd do it! As an example, here's some code that updates elements of a vector.

    import Data.Vector.Unboxed.Mutable
    
    import Data.Foldable (for_)
    import Prelude hiding (foldr, read, replicate)
    
    -- ghci> main
    -- [0,0,0,0,0,0,0,0,0,0]
    -- [0,5,10,15,20,25,30,35,40,45]
    main = do
      v <- replicate 10 0
    
      printVector v
    
      for_ [1 .. 5] $ \_ -> do
        for_ [0 .. 9] $ \i -> do
          v_i <- read v i
          write v i (v_i + i)
    
      printVector v
    
    printVector :: (Show a, Unbox a) => MVector RealWorld a -> IO ()
    printVector v = do
      list <- foldr (:) [] v
      print list

It does roughly the same as this Python:

    # python /tmp/test28.py
    # [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
    # [0, 5, 10, 15, 20, 25, 30, 35, 40, 45]
    def main():
        v = [0] * 10
    
        print(v)
    
        for _ in range(5):
            for i in range(10):
                v_i = v[i]
                v[i] = v_i + i
    
    
        print(v)
    
    if __name__ == '__main__': main()

rebeccaskinner8• 2 years ago

In imperative languages, the program will have a list of entities, and there will be an update() function for each entity that updates its state (position, etc) inline, i.e. new values are overwriten onto old values in memory, invoked at each simulation step.
In Haskell, how is that handled? do I have to recreate the list of entities with their changes at every simulation step? does Haskell have a special construct that allows for values to be overwritten, just like in imperative languages?

You don't _have to_ recreate the list each time, but that's probably where I'd suggest starting. GHC is optimized for these kinds of patterns, and in many cases it'll compile your code to something that does in-place updates for you, while letting you write pure functions that return a new list. Even when it can't, the runtime is designed for these kinds of small allocations and updates, and the performance is much better than what you'd get with that kind of code in another language.

If you decided that you really did need in-place updates, then there are a few options. Instead of storing a vector of values (if you are thinking about performance you probably want vectors instead of lists), you can store a vector of references that can be updated. IO is one way to do that (with IORefs) but you can also get "internal mutability" using STRefs. ST is great because it lets you write a function that uses mutable memory but still looks like a pure function to the callers because it guarantees that the impure stuff is only visible inside of the pure function. If you need concurrency, you might use STM and store them as MVars. Ultimately all of these options are different variations on "Store a list of pointers, rather than a list of values".

There are various other optimizations you could do too. For example, you can use unboxed mutable vectors to avoid having to do a bunch of pointer chasing. You can use GHC primitives to eek out even better performance. In the best case scenario I've seen programs like this written in Haskell be competitive with Java (after the warmup period), and you can keep the memory utilization pretty low. You probably won't get something that's competitive with C unless you are writing extremely optimized code, and at that point most of the time I'd suggest just writing the critical bits in C and using the FFI to link that into your program.

kccqzy4• 2 years ago

I don't understand why you hate the IO monad so much. I mean I've seen very large codebases doing web apps and almost everything is inside the IO monad. It's not as "clean" and not following best practices, but still gets the job done and is convenient. Having pervasive access to IO is just the norm in all other languages so it's not even a drawback.

But let's put that aside. You can instead use the ST monad (not to be confused with the State monad) and get the same performance benefit of in-place update of values.

whateveracct7• 2 years ago

You can use apecs, a pretty-fast Haskell ECS for those sorts of things.

IceDane2• 2 years ago

"Pretty fast".. relatively speaking, considering that it's in an immutable, garbage collected language. Still woefully slow compared to anything else out there(say, bevy? which incidentally works similarly to apecs) and mostly practically unusable if the goal is to actually create a real product.

Want to just have fun? Sure.

kreyenborgi3• 2 years ago

I've used Haskell for a decade or so, and tooling has improved immensely, with ghcup and cabal sandboxing and HLS now being quite stable. Maybe I've been lucky, but I haven't found much missing in the library ecosystem, or maybe I just have a lower threshold for using other languages when I see something is easier to do with a library from Python or whatever (typically nlp stuff). The one thing I still find annoying about Haskell is compile times. For the project itself, one can do fast compiles during development, but say you want to experiment with different GHC versions and base libraries, then you have to wait forever for your whole set of dependencies to compile (or buy some harddrives to store /nix on if you go that route). And installing some random Haskell program from source also becomes a drag due to dependency compile times (I'm always happy when I see a short dependency tree). Still, when deps are all compiled, it really is a fun language to program in.

transpute2• 2 years ago

ghcup and cabal sandboxing

Would you recommend using cabal or stack to package Haskell components in a Yocto layer, for sandboxed, reproducible, cross-compiled builds that are independent of host toolchains?

runeks• 2 years ago

My advice: use Stack if you're new to Haskell, otherwise cabal. Stack has better UX but isn't as powerful as cabal.

cubefox26• 2 years ago

Using "Maybe" as a positive example of what Haskell can do isn't right. Say you have a function with input of type A and output of type B, written (A -> B). The problem with Maybe ("option" types) then is that if you have a function, in production use, of type (X -> Maybe Y), you can't "weaken your assumptions for the input and strengthen your promises for the output" (which would be an improvement) and rewrite it to the type (Maybe X -> Y). Because then you would have to modify all the code which already uses the function. Since "A" and "Maybe A" are incompatible types. Which is illogical.

Several other null-safe languages solve this correctly by allowing disjunctions of types (often called unions, though countless other type related things are also called unions). They have a type operator "|" (or) and the function type (X -> Y|Null) can be improved by rewriting the function to (X|Null -> Y). Code outside the function doesn't have to be changed: Accepting X or Null implies accepting X, and returning Y implies returning Y or Null.

dsign• 2 years ago

data Maybe a = Nothing | Just a deriving (Eq, Ord)

> Because then you would have to modify all the code which already uses the function, as "A" and "Maybe A" are incompatible types. Which is illogical.

I'm not so sure about your statement. If the type of the function changes, revising its usage at every use point is good for your sanity. I would go further and say that sometimes Maybe X is too weak, because it doesn't contain precise semantics for its Nothing and Just x alternatives. For example, sometimes you want a `Nothing` for a value that hasn't yet been found, but could potentially be filled up the evaluation chain, e.g. `NothingYet`, and a different Nothing for a value that is conclusively not there, e.g. `TerrifyingVoid`. If you fork your `Nothing` value into these two variants after you discover the need for it, you will have to revise each call anyway, and check what's the proper course of action. And this is a feature I wish I could use from Python.

More generally, in large Haskell code bases, having the type-checker help you track, at compile time, code that breaks far away from where you made your changes, is an incredible time-saver.

cubefox26• 2 years ago

Yes, there are edge cases where you would like to have multiple different "kinds of null", but those use cases seem so uncommon in practice that they are mostly irrelevant.

magicalhippo7• 2 years ago

I don't use Haskell, so this is a dumb question. Why can't X be implicitly cast to Maybe X?

tobz6194• 2 years ago

It can using pure or return or if working with just Maybe specifically then Maybe is defined like so:

data Maybe a = Just a | Nothing

So to make an X a Maybe X, you'd put a Just before a value of type X.

For example:

one :: Int

one = 1

mOne :: Maybe Int

mOne = Just one -- alternatively, pure one since our type signature tells us what pure should resolve to.

Reason we can do this is because Maybe is also an Applicative and a Monad and so implements pure and return which takes an ordinary value and wraps it up into an instance of what we want.

mrkeen11• 2 years ago

Haskell/GHC tells you what the types are. Proper, global, most-general type inference. Not that local inference crap [1] that the sour-grapes types will say is better.

You lose this ability if you start letting the compiler decide that `Int` is as good as `Maybe Int`. Or if an `Async (Async String)` may as well be an `Async String`.

That's not to say it's not easy to transform (just a few keystrokes), but explicit beats implicit when it comes to casting (in any language).

[1] Does this work?

  var x = 1 == 2 ? Optional.of(2L) : Optional.empty().map(y -> y + y);
  // Operator '+' cannot be applied to 'java. lang. Object', 'java. lang. Object'

How about

  Optional<Long> x = 1 == 2 ? Optional.of(2L) : Optional.empty().map(y -> y + y);
  // Operator '+' cannot be applied to 'java. lang. Object', 'java. lang. Object'

or even

  Optional<Long> x = 1 == 2 ? Optional.of(2L) : Optional.empty().map((Long y) -> y + y);
  // Cannot infer functional interface type

No, we needed Optional.<Long>empty() instead of Optional.empty() to make it work

tobz6194• 2 years ago

If you have a value "aValue :: a" and a monadic function of "mFunc :: (a -> Maybe b)" that's essentially just asking you to use `>>= :: Maybe a -> (a -> Maybe b) -> Maybe b` as well as `pure :: Applicative f => a -> f a` which will lift our regular `aValue` to a `Maybe a` in this instance.

Then to get the result "b" you can use the `maybe :: b -> (a -> b) -> Maybe a -> b` function to get your "b" back and do the weakening as you desire.

`Maybe` assumes a computation can fail, and the `maybe` function forces you to give a default value in the case that your computation fails (aka returns Nothing) or a transformation of the result that's of the same resultant type.

Overall, you'd end up with a function call that looks like:

foo :: b

foo = maybe someDefaultValueOnFailure someFuncOnResult (pure aValue >>= mFunc)

or if you don't want to change the result then you can use `fromMaybe :: a -> Maybe a -> a`

bar :: b

bar = fromMaybe someOtherDefaultValueOnFailure (pure value >>= mFunc) -- if the last computation succeeds, return that value of resultant type of your computation

cubefox26• 2 years ago

Perhaps that theoretically solves the problem, but it sounds awfullly complicated in practice.

HelloNurse9• 2 years ago

This is fine and understandable in theory, but a usability disaster in practice.

If function f returns b or nothing/error, and is then improved to return b always, client code that calls f should not require changes or become invalid, except perhaps for a dead code warning on the parts that deal with the now impossible case of a missing result from f.

You are suggesting not only a pile of monad-related ugly complications to deal with the mismatch between b and Maybe b, which are probably the best Haskell can do, but also introducing default values that can only have the practical effect of poisoning error handling.

kyjasdfwus2• 2 years ago

Scala seems to be the only language that recognizes the merit of having both unions and ADTs. It even has GADTs!

tobz6194• 2 years ago

Haskell also has GADTs: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/gadt..., firstly as an extension and now it's built into the latest version of this year's compiler

cubefox26• 2 years ago

Yet ironically Scala is not null safe I believe.

pyrale7• 2 years ago

if you have a function, in production use, of type (X -> Maybe Y), you can't "weaken your assumptions for the input and strengthen your promises for the output" (which would be an improvement) and rewrite it to the type (Maybe X -> Y).

If your value of Y is predicated on receiving an X, I have trouble seeing how you would write such a function. If you have a default value, then Haskell would solve it just like any language with optionals:

    y :: Int -> String

    (fromMaybe "defaultValue" (map y (Just 3))

> Several other null-safe languages [...] returning Y implies returning Y or Null.

I have trouble seeing how the language is null-safe in that situation.

cubefox26• 2 years ago

If your value of Y is predicated on receiving an X

We didn't assume it is. Say you have a function of type (String -> String|Null). Further assume that you realize you don't necessarily need a String as input, and that you in fact are able to always output a string, no matter what. This means you can rewrite (improve!) the function such that it now has the type (String|Null -> String). Relaxing the type requirements for your inputs, or strengthening the guarantees for the type of your output, or both, is always an improvement. And there is no logical reason why you would need to change any external code for that. But many type systems are not able to automatically recognize and take advantage of this logical fact.

> Several other null-safe languages [...] returning Y implies returning Y or Null.
I have trouble seeing how the language is null-safe in that situation.

If you always assign a value of type Y to a variable of type Y|Null, the compiler will enforce a check for Null if you access the value of the variable, which is unnecessary (as the type of the variable could be changed to Y), but it can't result in a null pointer exception.

solomonb7• 2 years ago

So in your hypothetical language with union types `X | Null -> Y` is a function that can actually return `Y | Null`? Why would you want to allow that as an implicit behavior? This would make for surprising and unclear error handling requirements.

One of the main points of encoding error information in the type system in the type system is that it forces you to account for it when you modify your code.

By "weakening" your assumptions on your function to allow it to produce Null values you have introduced a new requirement at all your call sites. Everywhere that you call this function now needs to handle the Null value. Its a GOOD thing that Haskell forces you to handle this via the type system.

cubefox26• 2 years ago

So in your hypothetical language with union types `X | Null -> Y` is a function that can actually return `Y | Null`?

No, but a function which returns Y | Null can be replaced with a function which returns Y without changing code on the call site.

Imagine I always used to give you a nail (Y) or nothing (Null), and you can handle both receiving a nail and receiving nothing. Then I can, at any time, change my behavior to giving you nails only. Because you can already handle nails, and the fact that I now never give you nothing doesn't bother you. You just perform a (now useless) check of whether you have received a nail or nothing.

robertlagrant3• 2 years ago

I, like probably many people, like the idea of Haskell, but don't need a bottom-up language tutorial. Instead, I need:

- how easy is it to make a web application with a hello world endpoint?

- How easy is it to auth a JWT?

- Is there a good ORM that supports migrations?

- Do I have to remodel half my type system because a product owner told me about this weird business logic edge case we have to deal with?

- How do I do logging?

Etc.

gtf2124• 2 years ago

- how easy is it to make a web application with a hello world endpoint?

If that's all you want it to do, it's very easy with Wai/Warp.

- How easy is it to auth a JWT?

We don't use JWTs, but we did look at it and Servant (which is a library for building HTTP APIs) has built in functionality for them.

- Is there a good ORM that supports migrations?

There are several with quite interesting properties. Some (like persistent) do automatic migrations based on your schema definitions. Others you have to write migration SQL/other DSL.

- Do I have to remodel half my type system because a product owner told me about this weird business logic edge case we have to deal with?

I think that's going to really depend on how you have structured your domain model, it's not a language question as much as a design question.

- How do I do logging?

We use a library called Katip for logging, but there are others which are simpler. You can also just print to stdout if you want to.

robertlagrant3• 2 years ago

Thank you! What I was more saying was that an article like this would do better showing some practical simple examples, that would let people do things, rather than bemoaning how Haskell is viewed in 2024.

kccqzy4• 2 years ago

You can't do any of that without having first understood a bottom-up introduction. There are so many web frameworks from Yesod to Scotty to Servant (these are just the ones I've used personally) but you can't use any of them without at least an understanding of the language.

Ericson2314• 2 years ago

https://haskell-beam.github.io/beam/ is fantastic, but good luck understanding it if you don't already know some Haskell

justinhj• 2 years ago

That sounds valuable too but maybe it comes after the basic concepts or you may find people immediately dismiss it. There is all kinds of extra syntax and baggage that may seem pointless at first.

valenterry4• 2 years ago

This doesn't work.

Imagine you talk to someone who has done assembly his whole life and now wants to write something in, let's say, Java.

What would you think if he asks the question in the way you did?

Sometimes, when you learn a language that is so different you really really should NOT try to assume that your current knowledge just translates.

robertlagrant3• 2 years ago

I'm not advocating for removing the existing articles that introduce people to Haskell.

0xTJ2• 2 years ago

While the article is interesting, I find the layout of this website infuriating. A narrow strip of text, each line holding ~a dozen words makes it so much longer vertically than it needs to be, on desktop. I ended up using Inspect Element to change the width from 600px to 1200px, to fill up the most comfortable reading area on-screen.

gtf2124• 2 years ago

Sorry to hear that. I built it that way because I prefer reading narrower columns of text (maybe because I read a lot of magazines and newspapers, who knows).

0xTJ2• 2 years ago

Fair enough, if that's what you prefer than you might as well, it's more of a personal preference. My main monitor is an ultra-wide, so it ends up using less than 20% of the total width. Though I can see it being tough to have a good solution that works everywhere.

maleldil2• 2 years ago

I feel like part of the problem is Haskell's extremism towards purity and immutability. I find some code easier to express with procedural/mutable loops than recursion, and I believe the vast majority of programmers. I think that one thing that makes Rust so successful is its capable type of system and use of many functional idioms, but you can use loops and mutability when it's more comfortable. And of course, the borrow checker to ensure that such mutability is sound.

pyrale7• 2 years ago

That's a problem no haskell user has, honestly. Your issue seems to be about getting your feet wet. Could you imagine people saying the issue with Java is its extremism towards objects and method calls?

Sure, a determined Fortran programmer can write Fortran in any language, but if they have trouble doing so, maybe the issue isn't the language.

bedman123453• 2 years ago

Could you imagine people saying the issue with Java is its extremism towards objects and method calls?

I think exactly that all the time. It’s ridiculous.

That's a problem no haskell user has, honestly.

I had this problem all the time when trying to write games in Haskell. Not every subject matter decomposes into semirings. Just like not everything decomposes nicely into objects. People tried to fix this with FRP or lenses. Both are worse than imperative programming for games imo.

Joker_vD• 2 years ago

That's a problem no haskell user has, honestly.

In a sense, that's true: people who do have this trouble constantly (e.g. me) very quickly cease being Haskell users. But that's hardly an argument for TFA's claim that "Haskell is probably the best choice for most programmers, especially if one cares about being able to productively write robust software, and even more so if one wants to have fun while doing it"; if anything, it's a counter-argument.

mrkeen11• 2 years ago

Could you imagine people saying the issue with Java is its extremism towards objects and method calls?

"Execution in the Kingdom of Nouns" comes to mind.

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

the_af7• 2 years ago

I feel like part of the problem is Haskell's extremism towards purity and immutability

You missed "lazy evaluation by default" in that list ;) Those properties are kind of the definition of Haskell, so without all of them you'd have another language.

Like the sibling commenter mentions, this seems more of a "I'm unfamiliar with this" thing rather than a problem with Haskell...

cosmic_quanta5• 2 years ago

I find some code easier to express with procedural/mutable loops than recursion, and I believe the vast majority of programmers

I think this comes from early and continuous exposure to some forms of programming, rather than inherent to pure functional programming.

I personally find it much easier to use recursion and other functional techniques because it composes better. This probable comes from my exposure to Haskell much earlier than most.

cies4• 2 years ago

This has been researched. If you were educated with FP-langs first, you'd say it's harder "to express with procedural/mutable loops".

I believe the vast majority of programmers.

Yups. We get educated with imperative langs. The majority of us do.

enugu• 2 years ago

Haskell doesn't stop you from mutation, it just makes you explicitly mark it, like types of inputs/output are explicit in statically typed languages instead of being implicit or borrowing is explicit in Rust.

Mutations becomes first class values like numbers or arays, and hence can be primitives for more complex mutations, whose types can be inferred from the types of primitive mutations.

This means that the we have compile time guarantees that certain piece of code wont change anything in certain part of the state - This function wont change anything in that part of the data.

It is no joke, though not strictly true, that Haskell has been called the world's best imperative language.

gtf2124• 2 years ago

I find some code easier to express with procedural/mutable loops than recursion

This is what I was talking about in the section "Unlearning and relearning". While there are _some_ domains (like embedded systems) for which Haskell is a poor fit, a lot of the difficulties people have with it (and with FP in general) is that they have been heavily educated to think in a particular way about computation. That's an accident of history, rather than any fundamental issue with the programming paradigm.

maleldil2• 2 years ago

How does one go from years and decades of imperative programming to becoming fluent in Haskell's style of functional programming? It feels like a steep price to pay when most over languages don't require such substantial re-learning.

wavemode• 2 years ago

I feel like part of the problem is Haskell's extremism towards purity and immutability

Eh. Elm has achieved quite a bit of success just by having good tooling and a good ecosystem. Says something about people's willingness to learn pure functional programming, if the situation is right.

I find some code easier to express with procedural/mutable loops than recursion

This is usually a familiarity problem, IMO.

I often say: people think mastering Haskell is about mastering monads. But it's actually about mastering folds.

1-more2• 2 years ago

the best intro to writing Haskell for me was writing Elm. The best intro to writing Elm was writing pointfree Codewars kata solutions in JS using

    with(require("ramda")) fn = pipe(…)

And yep, you end up with a lot of folds (well, reduces) where that ellipsis is. Or related functions that are really folds.

For those wondering `with` in JS is a bit like `extract` in PHP except it creates a new context right after itself rather than modify the context it finds itself in. It's super deprecated because it's inscrutable and silly except in this case and/or when you need to solve Codewars katas in a limited number of characters.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://www.php.net/manual/en/function.extract.php

EDIT ramda is a nice utility library in JS that supports partial application of arguments in arbitrary order https://ramdajs.com/docs/#subtract

tome26• 2 years ago

I find some code easier to express with procedural/mutable loops than recursion

Do you mean like this example of calculating the 5th triangular number with a procedural loop and mutable state? Haskell supports them just fine!

https://hackage.haskell.org/package/bluefin-0.0.7.0/docs/Blu...

imoverclocked3• 2 years ago

My biggest gripe with Haskell, especially when dealing with lower level code, is that there is no implicit enforcement of dealing with error states. I like golang far more in this regard. All of the “if error” guards may be ugly but they sure impose a culture of dealing with problems that will arise.

I’ve come across plenty of Haskell code that just expects a happy path all of the time and can’t deal with any other situation. That’s great for POC work but horrible in production.

HelloNurse9• 2 years ago

And also horrible for the typical functional programmer that likes clever "solutions" but hates the "boring" parts of actual good software.

gtf2124• 2 years ago

I write about this at some length in the essay, perhaps you can help me by telling me why the section on "Make fewer mistakes" _doesn't_ satisfy?

weebull2• 2 years ago

I think one of the big takeaways from Haskell for me was that errors don't always need to be explicitly handled. Sometimes returning a safe sentinel value is enough.

For example, if the function call returns some data collection, returning an empty collection can be a safe way to allow the program to continue in the case of something unexpected. I don't need to ABORT. I can let the program unwind naturally as all the code that would work on that collection would realise there's nothing to do.

Debugging that can be a pain, but traces and logging tend to fix that.

YuukiRey2• 2 years ago

You wrote

Haskell solves the problem of the representation of computations which may fail very differently: explicitly through the type system.

In my experience this is very hit and miss. Some libraries use exceptions for lots of error states that in Go would be a returned error value. I'm therefore left to decipher the docs (which are often incomplete) to understand which exceptions I can except and why and when.

Last library I remember is https://hackage.haskell.org/package/modern-uri

From their docs: > If the argument of mkURI is not a valid URI, then an exception will be thrown. The exception will contain full context and the actual parse error.

The pit of success would be if every function that can fail because of something reasonable (such as a URI parser for user supplied input) makes it a compile time message (warning, error, whatever you prefer) if I fail to consider the error case. But there's nothing that warns me if I fail to catch an exception, so in the end, in spite of all of Haskell's fancy type machinery, in this case, I'm worse off than in Golang.

spopejoy3• 2 years ago

There are real dragons handling AsyncException vs Exception, with extremely poor ecosystem understanding about how to deal with them properly.

There's also the huge performance divergence between IO exceptions (fast) vs a mtl stack built around Either which will have huge problems successfully inlining and thus be slowwww.

Indeed this is a great example of how Haskell can have serious performance issues in areas that would never occasion a second look in other mature GP langs. Who ever heard of well-modelled error handling having performance problems? Only In HaskellTM

Vosporos2• 2 years ago

At work we use Haskell, and have been for around 10 years. It's a delight for iterations and refactoring, as the solid foundations it bring relieve you of spending your time writing tests checking for rogue nils or undefined.

sevensor• 2 years ago

Not a word about laziness? This is at this point the most interesting thing about Haskell. As many others have pointed out, the type system has hugely influenced other languages, but laziness by default, for everything, seems like an equally big deal, and equally hard to get one’s head around.

gtf2124• 2 years ago

Nope: I think the laziness aspect is very interesting, but it's not something that makes Haskell (for me) a great programming language. Or, at least, it's not in my list of the top reasons (it is in there somewhere).

whateveracct7• 2 years ago

You don't even notice the laziness most of the time. Even if you are benefiting from it.

dbacar• 2 years ago

Why not?

iso8859-16• 2 years ago

We can generalise this idea of being forced to handle the failure cases by saying that Haskell makes us write total functions rather than partial functions.

Haskell doesn't prevent endless recursion. (try e.g. `main = main`)

As the typed FP ecosystem is moving towards dependent typing (Agda, Idris, Lean), this becomes an issue, because you don't want the type checker to run indefinitely.

The many ad-hoc extensions to Haskell (TypeFamilies, DataKinds) are tying it down. Even the foundations might be a bit too ad-hoc: I've seen the type class resolution algorithm compared to a bad implementation of Prolog.

That's why, if you like the Haskell philosophy, why would you restrict yourself to Haskell? It's not bleeding edge any more.

Haskell had the possibility of being a standardized language, but look at how few packages MicroHS compiles (Lennart admitted to this at ICFP '24[0]). So the standardization has failed. The ecosystem is built upon C. The Wasm backend can't use the Wasm GC because of how idiosyncratic GHC's RTS is.[1]

So what does unique value proposition does GHC have left? Possibly the GHC runtime system, but it's not as sexy to pitch in a blog post like this.

[0]: Lennart Augustsson, MicroHS: https://www.youtube.com/watch?v=uMurx1a6Zck&t=36m

[1]: Cheng Shao, the Wasm backend for GHC: https://www.youtube.com/watch?v=uMurx1a6Zck&t=13290s

samvher• 2 years ago

For a long time already I've wanted to make the leap towards learning dependently typed programming, but I was never sure which language to invest in - they all seemed either very focused on just proofs (Coq, Lean) or just relatively far from Haskell in terms of maturity (Agda, Idris).

I went through Software Foundations [0] (Coq) which was fun and interesting but I can't say I ever really applied what I used there in software (I did get more comfortable with induction proofs).

You're mentioning Lean with Agda and Idris - is Lean usable as a general purpose language? I've been curious about Lean but I got the impression it sort of steps away from Haskell's legacy in terms of syntax and the like (unlike Agda and Idris) so was concerned it would be a large investment and wouldn't add much to what I've learned from Coq.

I'd love any insights on what's a useful way to learn more in the area of dependent types for a working engineer today.

[0] https://softwarefoundations.cis.upenn.edu/

iso8859-16• 2 years ago

Lean aims to be a general purpose language, but I haven't seen people actually write HTTP servers in it. If Leo de Moura really wanted it to be general purpose, what does the concurrent runtime look like then? To my knowledge, there isn't one?

That's why I've been writing an HTTP server in Idris2 instead. Here's a todo list demo app[1] and a hello world demo[2]. The advantage of Idris is that it compiles to e.g. Racket, a high level language with a concurrent runtime you can bind to from Idris.

It's also interesting how languages don't need their own hosting (e.g. Hackage) any more. Idris packages are just listed in a TOML file[3] (like Stackage) but still hosted on GitHub. No need for versions, just use git commit hashes. It's all experimental anyway.

[1] https://janus.srht.site/docs/todolist.html [2]: https://git.sr.ht/~janus/web-server-racket-hello-world/tree/... [3]: https://github.com/stefan-hoeck/idris2-pack-db/blob/main/STA...

agentultra9• 2 years ago

Lean can be used to write software in [0]. I dare say that it may even be the intended use for Lean 4. Work on porting mathlib to Lean 4 is far along and the mathematicians using it will certainly continue to do so. However there is more space for software written in Lean 4 as well.

However...

it's no where near ready for production use. They don't care about maintaining backwards compatibility. They are more focused on getting the language itself right than they are about helping people build and maintain software written in it. At least for the foreseeable future. If you do build things in it you're working on shifting ground.

But it has a lot of potential. The C code generated by Lean 4 is good. Although, that's another trade-off: compiling to C is another source of "quirks."

[0] https://agentultra.github.io/lean-4-hackers/

mebassett• 2 years ago

Lean definitely intends to be usable as a general purpose language someday. but I think the bulk of the people involved are more focused on automated theorem proving. The Lean FRO [0] has funds to guide development of the language and they are planning to carve out a niche for stuff that requires formal verification. I'd say in terms of general purpose programming it fits into the category of being "relatively far from haskell in terms of maturity".

[0] https://lean-fro.org/about/roadmap-y2/

pmarreck• 2 years ago

One reason I took interest in Idris (and lately Roc, although it's even less mature) is the promise of a functional but usable to solve problems today language with all the latest thinking on writing good code baked-in already, compiling to a single binary (something I always envied about Go, although unfortunately it's Go). There simply isn't a lot there yet in the space of "pure functional language with only immutable values and compile time type checking that builds a single fast binary (and has some neat developer-friendly features/ideas such as dependent types, Roc's "tags" or pattern-matching with destructuring)" (this rules out OCaml, for example, despite it being mature). You get a lot of that, but not all of it, with other options (OCaml, Elixir/Erlang, Haskell... but those 3 offer a far larger library of ready-to-import software at this point). Haskell did manage to teach everyone who cares about these things that managing side-effects and keeping track of "purity" is important.

But it's frankly still early-days and we're still far from nirvana; Rust is starting to show some warts (despite still being a massive improvement over C from a safety perspective), and people are looking around for what's next.

One barely-touched thing is that there are compiler optimizations made possible by pure functional/pure immutable languages (such as caching a guaranteed result of an operation where those guarantees simply can't be given elsewhere) that have simply been impossible until now. (Roc is trying to go there, from what I can tell, and I'm here for it! Presumably, Rust has already, as long as you stick with its functional constructs, which I hear is hard sometimes)

bmitc• 2 years ago

When I last looked into Lean, I was highly unimpressed, even for doing math proofs. There's no way I'd invest into as a general-purpose language.

Idris at least does state that they what people building real programs with it and don't want it to just be a research language.

For dependent types, I myself am skeptical about languages trying to continuously push more and more stuff into types. I am not certain that such efforts are a net positive on writing good software. By their very definition, the more typed a language gets, the less programs it can represents. That obviously reduces buggy programs, but it also reduces non-buggy programs that you can implement. Highly typed languages force more and more effort into pre-compile time and you will often find yourself trying to fit a problem into the chains of the type system.

Rather, I think reasonably multi-paradigm languages like F# are the sweet spot. Just enough strict typing and functional core to get you going for most of your program, but then it allows classes and imperative programming when those paradigms are appropriate.

I think the way to go to write better software is better tooling and ergonomics. I don't think type systems are going to magically save us.

saghm• 2 years ago

I took that course as well, and for me, the big takeaway wasn't that I specifically want to use Coq for anything practical, but the idea that you can actually do quite a lot with a non-Turing complete language. Realizing that constraints in a language can be an asset rather than a limitation is something that I think isn't as widely understood as it should be.

lemonwaterlime4• 2 years ago

why would you restrict yourself to Haskell? It's not bleeding edge any more.

I'm not using Haskell because it's bleeding edge.

I use it because it is advanced enough and practical enough. It's at a good balanced spot now to do practical things while tapping into some of the advances in programming language theory.

The compiler and the build system have gotten a lot more stable over the past several years. The libraries for most production-type activities have gotten a lot more mature.

And I get all of the above plus strong type safety and composability, which helps me maintain applications in a way that I find satisfactory. For someone who aims to be pragmatic with a hint of scholarliness, Haskell is great.

iso8859-16• 2 years ago

The compiler and the build system have gotten a lot more stable over the past several years.

GHC2021 promises backwards compatibility, but it includes ill-specified extensions like ScopedTypeVariables. TypeAbstractions were just added, and they do the same thing, but differently.[0] It hasn't even been decided yet which extensions are stable[1], yet GHC2021 still promises compatibility in future compiler versions. So either, you'll have GHC retain inferior semantics because of backwards compatibility, or multiple ways of doing the same thing.

GHC2024 goes even further and includes extensions that are even more unstable, like DataKinds.

Another sign of instability is the fact that GHC 9.4 is still the recommended[2] release even though there are three newer 'stable' GHCs. I don't know of other languages where the recommendation is so far behind! GHC 9.4.1 is from Aug 2022.

It was the same situation with Cabal, it took forever to move beyond Cabal 3.6 because the subsequent releases had bugs.[3]

[0] https://serokell.io/blog/ghc-dependent-types-in-haskell-3 [1]: https://github.com/ghc-proposals/ghc-proposals/pull/669 [2]: https://github.com/haskell/ghcup-metadata/issues/220 [3]: https://github.com/haskell/ghcup-metadata/issues/40

HelloNurse9• 2 years ago

The libraries for most production-type activities have gotten a lot more mature.

Can you provide an example of a "mature" way to match a regular expression with Unicode character classes or download a file over HTTPS?

gtf2124• 2 years ago

That's why, if you like the Haskell philosophy, why would you restrict yourself to Haskell?

In the essay, I didn't say "Haskell is the only thing you should use", what I said was:

Many languages have bits of these features, but only a few have all of them, and, of those languages (others include Idris, Agda, and Lean), Haskell is the most mature, and therefore has the largest ecosystem.

On this:

It's not bleeding edge any more.

"Bleeding edge" is certainly not something I've used as a benefit in this essay, so not really sure where this comes from (unless you're not actually responding to the linked essay itself, but rather to ... something else?).

giraffe_lady3• 2 years ago

As the typed FP ecosystem is moving towards dependent typing (Agda, Idris, Lean)

I'm not really sure where the borders of "the typed FP language ecosystem" would be but feel pretty certain that such a thing would enclose also F#, Haskell, and OCaml. Any one of which has more users and more successful "public facing" projects than the languages you mentioned combined. This is not a dig on those languages, but they are niche languages even by the standards of the niche we're talking about.

You could argue that they point to the future but I don't seriously believe a trend among them represents a shift in the main stream of functional programming.

xupybd• 2 years ago

This is the F# time that I've seen F# contrasted as the more mainstream option and it warms my heart.

mightybyte• 2 years ago

That's why, if you like the Haskell philosophy, why would you restrict yourself to Haskell? It's not bleeding edge any more.

Because it has a robust and mature ecosystem that is more viable for mainstream commercial use than any of the other "bleeding edge" languages.

js8• 2 years ago

As the typed FP ecosystem is moving towards dependent typing (Agda, Idris, Lean), this becomes an issue, because you don't want the type checker to run indefinitely.

First of all, does ecosystem move to dependent types? I think the practical value of Hindley-Milner is exactly in the fact that there is a nice boundary between types and terms.

Second, why would type checking running indefinitely be a practical problem? If I can't prove a theorem, I can't use it. The program that doesn't typecheck in practical amount of time is in practice identical to non-type-checked program, i.e. no worse than a status quo.

DonaldPShimoda• 2 years ago

No, the FP community at large is definitely not moving toward dependent types. However, much more of the FP research community is now focused on dependent types, but a good chunk of that research is concerned with questions like "How do we make X benefit of dependent types work in a more limited fashion for languages without a fully dependent type system?"

I think we'll continue to see lots of work in this direction and, subsequently, a lot of more mainstream FP languages will adopt features derived from dependent types research, but it's not like everybody's going to be writing Agda or Coq or Idris in 10 years instead of, like, OCaml and Haskell.

tkz13125• 2 years ago

So what does unique value proposition does GHC have left? Possibly the GHC runtime system, but it's not as sexy to pitch in a blog post like this.

The point is that programming in a pure language with typed side effects and immutable data dramatically reduces the size of the state space that must be reasoned about. This makes programming significantly easier (especially over the long term).

Of the languages that support this programming style Haskell remains the one with the largest library ecosystem, most comprehensive documentation, and most optimised compiler. I love lean and use it professionally, but it is nowhere near the usability of Haskell when it comes to being a production ready general purpose language.

dataflow2• 2 years ago

dramatically reduces the size of the state space that must be reasoned about

True

This makes programming significantly easier (especially over the long term)

Not true. (As in, the implication is not true.)

There are many many factors that affect ease of programming and the structure of the stage space is just one of them.

User232• 2 years ago

When you start mathematically characterizing state spaces it quickly becomes apparent that pure functional languages advantage over imperative ones is more a matter of the poor design of popular imperative languages rather than an intrinsic difference.

That (in)famous goto paper isn't really about spaghetti code, it's about how on Earth do you mathematically define the semantics of any statement in a language with unrestricted goto. If any continuation can follow literally anything then you're pretty much in no man's land. On the other hand imperative code is easy and natural to reason about when it uses a small set of well defined primitives.

If that sounds surprising, consider how mathematical logic itself, especially obviously in the calculational proof style, is essentially a series of assignment statements.

aSanchezStern• 2 years ago

Uhh, endless recursion doesn't cause your typechecker to run indefinitely; all recursion is sort of "endless" from a type perspective, since the recursion only hits a base case based on values. The problem with non-well-founded recursion like `main = main` is that it prevents you from soundly using types as propositions, since you can trivially inhabit any type.

remexre2• 2 years ago

The infinite loop case is:

    loopType : Int -> Type
    loopType x = loopType x

    foo : List (loopType 3) -> Int
    foo _ = 42

    bar : List (loopType 4)
    bar = []

    baz : Int
    baz = foo bar

Determining if baz type-checks requires evaluating loopType 3 and loopType 4 to determine if they're equal.

throwthrow5643• 2 years ago

Haskell doesn't prevent endless recursion. (try e.g. `main = main`)

Do you mean to say Haskell hasn't solved the halting problem yet?

xigoi3• 2 years ago

There are languages that don’t permit non-terminating programs (at the cost of not being Turing-complete), such as Agda.

watt2• 2 years ago

The article lost me at following sentence:

A double arrow => describes constraints on the type variables used, and always come first: add1 :: Num a => a -> a describes a function which takes any type a which satisfies Num a, and returns a value of the same type.

Here, I don't understand what `Num a` syntax means. It was not defined before. And, what does "satisfies" mean? It is also not defined before it is used. (It is also never mentioned again in the article.) It is maddening to read such sloppily constructed prose. Define your terms before you use them!

ethangk• 2 years ago

It just means that ‘a’ must be a Number [0]. In this context, I believe satisfies means that it implements the things defined in the ‘minimum definition’ in the link below. If you’re familiar with Go, it’s similar to something implementing an interface.

[0] https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-N...

watt2• 2 years ago

well why does Num then come before a ? If a :: Num would mean a is a value of type Num, why does this "satisfies" constraint does not follow the pattern?

desdenova• 2 years ago

This terseness is what makes Haskell so hard to approach for beginners, unfortunately.

After you went through the effort of learning the syntax, it becomes very clear what it means, but I agree that dropping punctuation between a bunch of names isn't the clearest communication.

It becomes even worse when you start using third party libraries that abuse Haskell's ability to define custom operators, so you get entire APIs defined as arcane sigil invocations instead of readable functions.

That's why I gave up the idea of using Haskell for actual programming, and just took the functional programming philosophy from it to other languages.

As for the meaning, in a more conventional (rust) syntax, it'd be similar to this:

    fn add1<A: Num>(a: A) -> A

ColonelPhantom• 2 years ago

I disagree that the 'arcane sigil invocations' are necessarily a problem. Yes, they can be, but I also think they can definitely be preferable!

Naming everything as a function often leads to a problem of very deep visual nesting. For example, map-then-filter can be written as "filter p . map f" in Haskell, whereas in sigil-free languages you'd write a mess like (lambda (x) (filter p (map f x))) in Lisp or "lambda x: filter(p, map(f, x))" in Python.

Of course, function composition is a very simple case, but something like lenses are another less simple case where a library would be unusable without custom operators.

kazinator3• 2 years ago

The problem with A -> B -> C is that it could be (A -> B) -> C or A -> (B -> C).

The -> operator in C is obvious. Though it does have left to right associativity, it's largely moot because only A would be a pointer-valued expression. The B and C would have to be member names:

  A->left->value.

Even if the associativity went right to left, the semantic interpretation would have to be that the left member of A is selected, and then the value member of that.

When X -> Y means "mapping from X to Y", the associativity could be anything, and make sense that way. Moreover (X -> Y) -> Z is different from X -> (Y -> Z). One is a function which maps an X-to-Y function to Z, whereas the other is a function which maps X to a Y-to-Z function.

AzzieElbab• 2 years ago

Yes, this bad mathematician's lingo is really unnecessary. It means someone else wrote an implementation of an interface called Num for your `a` type. Well, it is not really an interface. The correct term is type class, but that is details.

gtf2124• 2 years ago

If I may, as the author of "such sloppily constructed prose" (which I think might be a little unfair as a summary of all 6.5k words):

In this syntax note, I was not trying to teach someone to write Haskell programmes, but rather to give them just enough to understand the examples in the essay. I did test it on a couple of friends to see if it gave them enough to read the examples with, but was trying to balance the aim with not making this section a complete explainer (which would have been too long).

Perhaps I got the balance wrong, which is fair enough, but I don't think it's required to define _every single_ term upfront. It's also not crucial to the rest of the essay, so "The article lost me at following sentence" feels a bit churlish.

kazinator3• 2 years ago

"Satisfies" is a common math term. For instance given

  x + 3 = 4

the value of x which satisfies the equation is 1. To satisfy is to be a value which makes true some truth valued formula (such as an invocation of a predicate like blue(x) or equation like the above, or inequality or such).

Satisfiability comes up in logic; a "SAT" problem is, in a nutshell, the problem of finding the combination of true/false values of a bunch of Boolean variables, which make some formula true.

When the Haskeller says that "Num a" is something that is satisfied by a, it means that it's a kind of predicate which says a is a Num. That predicate is true of an a which is a Num.

agentultra9• 2 years ago

It's really good for boring, line of business software (BLOBS).

The vast majority of business logic can be modelled with a handful of simple types and pattern matching. Very few design patterns are needed. And if you keep to the simple parts you can even teach the syntax (just the types) to non-technical contributors in an afternoon. Then they can read it and help verify that you implemented the business process correctly.

It's also just nice for how my brain works. I like being able to substitute terms and get an equivalent program. Or that I can remember a handful of transformation rules that often get me from a first cut of a program to an efficient, fast one.

And it's just fun.

mumblemumble• 2 years ago

It is. But I think that, for that purpose, I like F# even better. Even beyond getting access to the .NET ecosystem, you also get some language design decisions that were specifically meant to make it easier to maintain large codebases that are shared among developers with varying skill levels.

Lack of typeclasses is a good example. Interface inheritance isn't my favorite, but after years working as the technical lead on a Scala project I've been forced to concede that haranguing people who just want to do their job and go home to their family about how to use them properly isn't a good use of anyone's time. Everyone comes out of school already knowing how to use interfaces and parametric polymorphism, and that is fine.

agentultra9• 2 years ago

I adore Scott Wlaschin's work [0] -- that's where I picked up on the acronym, BLOBS! F# is super cool, I agree.

[0] https://www.youtube.com/watch?v=Up7LcbGZFuo

chefandy2• 2 years ago

Anecdotally, the handful of people I've known that worked in commercial Haskell shops, after the initial honeymoon period intensified by actually finding a paying Haskell dev job, wishes they were using a more practical "happy medium" FP language. I don't know anyone that's used F# in production, but nobody I know that's worked in Elixir, erlang, or elm environments has expressed the same frustration.

darby_nine2• 2 years ago

If that's what you're looking for, why not rip out most of the language? You'll end up with something that looks a lot like Elm. You'll end up with a purely deterministic program with no i/o (albeit with a kind of crappy debugging experience).

agentultra9• 2 years ago

Well because you need the rest of the language to make your program tell your system to do stuff.

Turns out `IO` is the most essential and useful bit of a Haskell program. That part can be left to the programmers. Haskell has a lot of facilities for making that nicer to work with as well.

I find that when I tell folks I work in Haskell full-time you can see their opinion of you change on their face. I'm not some kind of PhD genius programmer. I'm pretty middle-of-the-road to be honest.

It's just nice to have a language that makes the work of writing BLOBS straight-forward.

gavinray2• 2 years ago

Only on HN will you read someone unironically suggest writing LOB software in Haskell.

tome26• 2 years ago

Why not? Many of us do it every day.

jose_zap2• 2 years ago

We do that at our company, it's been great

bunderbunder• 2 years ago

I am not prepared to hunt down the citation, but several years back I stumbled across a paper that was trying to compare the effectiveness of various languages for grinding out "domain logic-y" code. Among the ones they evaluated, Haskell came out on top in terms of both time to get the work done and correctness of the implementation.

IIRC this was testing with students, which would be both a strength and a weakness of the experimental design.

__MatrixMan__• 2 years ago

Not just HN, Cardano's smart contract language, Plutus, is based on Haskell.

ninetyninenine2• 2 years ago

Haskell is just hard when you get to the advanced stuff. I mean beyond monads there’s the state monad, lenses, etc. a lot of these are not trivial to wrap your brain around. Like for Java head first design patterns I read it and I’m good. For monads it took me weeks to wrap my head around it and I still don’t understand every monad.

Yeah I get a bunch of basic apps can be modeled easily, you get unparalleled static safety but programmers will spend an inordinate amount of time figuring out mind bending algebraic patterns.

I think something like ocaml or f sharp are more down to earth.

agentultra9• 2 years ago

The advanced parts of most languages can get hairy. Don't mistake familiarity with complexity. Even Java has hard, dense code that is difficult to work with and learn.

I tend to stay away from the advanced parts of Haskell when writing BLOBS.

The advanced stuff is there when you need to write libraries that need generic code that works with types you haven't defined yourself. You learn it as you go when you need to.

But when I'm writing BLOBS I mostly stick to using libraries and that's pretty straight-forward.

bazoom42• 2 years ago

Sounds about as plausible as “Non-programmers can draw the business logic as UML diagrams, then the code can be generated by automated tools”

wredue• 2 years ago

Good question

Runtime immutability is brain dead

Haskell doesn’t “solve maintainability” even remotely. Most people leaving Haskell say maintainability is worse

Haskell doesn’t solve parallelism as Haskell devs claim

Haskell is not beautiful

And that’s literally every selling point. Why choose it?

reidrac• 2 years ago

I like haskell. Actually, let me rephrase that: I like GHC2021.

And I have found that's one of the tricky bits with Haskell, together with the language being in very active development, wich makes upgrading your compiler a thing.

tome26• 2 years ago

Actually, changes to the compiler hardly ever break anything. I recently upgraded four compiler versions in a row and apart from a bug and some warnings the compiler didn't force any changes at all. It's primarily changes to libraries that introduce churn.

https://h2.jaguarpaw.co.uk/posts/ghc-8.10-9.6-experience-rep...

(DeepSubsumption wouldn't have been a problem if we'd specified Haskell2010, as we should have.)

igouy• 2 years ago

Awaiting part 2 — Why not to use Haskell?

sesm• 2 years ago

Haskell is an experiment on having laziness at language level. This experiment clearly shows, that laziness on language level is a bad idea.You can get all the benefits of laziness at standard library level, as illustrated by Clojure and Twitter Storm using it in production.

All the other FP stuff (union types, etc) existed before Haskell in non-lazy FP languages.

agentultra9• 2 years ago

There’s a strong case that laziness should be the default: https://m.youtube.com/watch?v=fSqE-HSh_NU

I’m not sure I’m experienced enough in PLT enough to have a strong opinion myself.

However, from experience, laziness has a lot of advantages both from a program construction and performance perspective.

kccqzy4• 2 years ago

Laziness is but one mistake in Haskell. It should not prevent you from using other parts of the language that are wonderful. There's a reason Mu exists, which is to take Haskell and make it strict by default: there are plenty of good things about Haskell even if you consider laziness to be a mistake.

(Of course a small minority of people don't consider laziness as a mistake as it enables equational reasoning; let's not go there.)

tome26• 2 years ago

Having used Mu I concluded that Haskell got function laziness correct. (Data type laziness is a different issue, but that can be solved by `StrictData`).

iainmerrick• 2 years ago

Right, I was surprised I had to scroll down here so far to see the first mention of laziness; it's the core feature of Haskell (copied from Miranda so researchers had a non-proprietary language to build their work on).

From everything I've ready about people's experiences with using Haskell for large projects, it sounds like lazy evaluation unfortunately adds more problems than it removes.

whateveracct7• 2 years ago

This experiment clearly shows, that laziness on language level is a bad idea.

This is quite the claim. I know plenty of experienced and productive Haskellers who disagree with this (myself included)

louthy12• 2 years ago

I don't see laziness as a problem in Haskell, especially as you can opt out of laziness altogether, or partially. In practice I found that `StrictData` solves pretty much every issue.

semiinfinitely2• 2 years ago

Haskell had a large impact on the design of JAX which is probably the future of ML development frameworks.

drdrey• 2 years ago

The Python example feels like a strawman. You can write Python in a way that gets you most of the benefits of the Haskell version if you wanted to:

    @dataclass
    class InvalidResultError:
        result: str

    def do_something() -> int | InvalidResultError:
        result = get_result()
        return 42 if result == "a result" else InvalidResultError(result)

Using a dataclass like this seems a little overkill, but it does get you something close to `Either`.

I also don't understand the argument against nullable types: you could return `int | None` here, which would be the same as treating a `Maybe` (you have to explicitly consider the case where there is no value)

rbonvall2• 2 years ago

The most important benefit is not that you CAN unwrap a value, but rather that you CANNOT NOT do it.

jesse__2• 2 years ago

The thing that always amuses me when I read articles like this is that the things they point out as differentiating the language are usually, at best, small time-savers.

1. the lack of nullable types

I very rarely write these bugs, and when I do I can typically fix them in 5 minutes. This is because I typically do (2) in my projects, which does largely eliminate this error.

2. representations of “failable” computations

Basically any modern language can do this. It might not be 100% as ergonomic as it is in Haskell, but it also isn't a large source of bugs in my experience.

3. pattern matching and completeness checks

Okay, these are nice and ergonomic in Haskell. Other languages get pretty close. Again, not a source of time-consuming bugs.

4. the avoidance of “primitive obsession”

The example he gave for this is innanely contrived, and the bug would likely take a small amount of time to fix, even for a junior. Admittedly, this is a nice convenience feature and I would love having types for different color spaces, or radians vs degrees, but at the end of the day I spend basically 0% of my time on bugs like this, so it's barely worth mentioning.

You know what I'd like a language to help me with? Keeping track of inter-data dependencies so I don't have to litter my code with a million assertions to make sure the sub-type of the sum type I'm working with is correct. Or giving me a way to express structural dependencies between pieces of code when writing multithreaded programs. Like saying "hey, this render pass has to happen after 'DoEntitySimulation' has completed" .. or whatever. I'm not aware of any language that even tries to do that, although I think Bungie wrote something like this in their engine for Destiny2.

And metaprogramming. I ended up writing my own metaprogramming language because none of the ones I tried could even do the basics of what I wanted in an ergonomic way, and be runtime-performant.

For reference, my language of choice is typically C++99. Maybe I'm not the intended target audience.

valcron1000• 2 years ago

This is actually a very good comment. Haskell has had these features since early ~2000s and it was a major competitive advantage in the language space, but today I would argue that if you're using a modern language then they don't stand out as much. Nevertheless, not all popular languages provide all the above mentioned features and in case they implement them it's usually in a compromised fashion. For example, nullable types are still an open issue in Java, while C# and Typescript provide easy ways to circumvent them, a lot of times by accident (the main issue is that they're mostly annotations, not runtime checks).

On the other hand, you mention several features which Haskell provides, usually through libraries that can only be implemented due to the features provided by the base language:

- Refinement types [1] allow to add runtime invariants to existing types in an ergonomic fashion, or you can go even further and use something like LiquidHaskell[2] to enforce properties at compile time.

- For multithreaded programs, the existence of STM[3] allows to to write mutable variables which are safe to use across threads. Very few languages offer something like this.

- For structural dependencies, you can apply the techniques of "ghost of departed proofs"[4]. Personally I don't like to go that route since programming becomes an act of "proving" rather than "doing" but I appreciate the fact that you can encode it if you want/need to.

- Metaprogramming in Haskell is not as ergonomic as in a LISP yet you have the full access to the language through TemplateHaskell[5]. A more constrained form is available as QuasiQuotations that allow you, for example to write a regex[6] string and have it compiled alongside the rest of the code.

There are other features that I personally think are still far ahead from the competition, like lenses[7] to traverse nested data, the async[8] package for ergonomic concurrent programs, effect systems[9] for more granular dependency injection, immutability by default to avoid corrupting state, full type inference, top level functions and values (I can't believe the amount of times I find myself missing them in OOP languages like Java and C#), among others.

---

[1] https://hackage.haskell.org/package/refined [2] https://ucsd-progsys.github.io/liquidhaskell/ [3] https://hackage.haskell.org/package/stm [4] https://hackage.haskell.org/package/gdp [5] https://serokell.io/blog/introduction-to-template-haskell [6] https://hackage.haskell.org/package/regexqq [7] https://hackage.haskell.org/package/lens [8] https://hackage.haskell.org/package/async [9] https://hackage.haskell.org/package/effectful

jesse__2• 2 years ago

This is actually a very good comment.

Thank you, I appreciate that. And that you took the time to write such a complete response.

At the end of the day, Haskell is just way too slow (at runtime) for me to consider using, so debating that these features satisfy my requirements is purely an academic exercise. One which I don't have much interest in doing.

I am glad to hear that you seem to enjoy using Haskell, and I hope it continues to bring you joy :)

semiinfinitely2• 2 years ago

I love Haskell but I hate using it.

jes5199• 2 years ago

in general, I am in favor of language features that make it easy to prove that common errors will not happen. Conversely, I am against language features that make it easy to make new classes of errors that are hard to reason about.

Haskell manages to do a lot of both. The kinds of problems I ran into in my Haskell error were much, much weirder than the problems I run into in other environments - things that when I explain them to other programmers they often don't even believe me.

On balance, for me, the new problems were worse than the old problems, but your mileage may vary.

alxmng2• 2 years ago

This is my experience as well. Referential transparency and immutability have many advantages, with few disadvantages (if any). Type checking is great as a way to enforce constraints. However, nominal types create unnecessary incompatibility and endless type shuffling every time you want to make even simple changes. I maintain a web app written in Haskell and there’s 3 or 4 different types for URLs in the codebase, even though there’s no real difference between them. Nominal typing is terrible for code reuse via third-party modules. So many hours wasted wrapping types or shuffling between them.

A functional language with a simple set of structural types would be the sweet spot for me. Clojure is probably the closest to this.

birdfood• 2 years ago

I think I'm at the same conclusion. I basically want ocaml but with structural / compile time duck typing of all types (I know about objects but they don't seem widely used). And some sort of reflection mechanism to cover 80% of the cases where you'd reach for ppx / macros (i.e. database interface code gen of types).

joshlemer2• 2 years ago

What kinds of things led to multiple types of URL's in the same codebase?

me_vinayakakv2• 2 years ago

I was looking into the pattern matching example in the article with `Either` type. If we need to unwrap and check for all the cases one by one would it become a callback hell?

I was going through a Scala codebase at work that uses `Future`s and `map`ing and `flatMap`ing them. Sometimes the callbacks went 5-6 levels deep. Is there a way to "linearlize" such code?

I come from JS/TS background and have not much experience with pufe functional languages. But I love how TS handles discriminated unions - if we handle a branch and `return` early, that branch is removed from the union for the subsequent scope, and I was wondering if something of that sort can be achieved in Haskell/Scala.

tel2• 2 years ago

In Haskell, that's usually that's done using `do` syntax.

    do
      a <- somePartialResult
      b <- partialFunction1 a
      c <- partialFunction2 a b
      return c

where we assume signatures like

    somePartialResult : Either<A, Error>
    partialFunction1 : A -> Either<B, Error>
    partialFunction2 : A -> B -> Either<C, Error>

this overall computation has a signature Either<C, Error>. The way it works is that the first failing computation (the first Either that's actually Left-y) will short-circuit and become the final result value. Only if all of the partial computations succeed (are Right-y) will the final result by Right(c).

In Haskell we don't have an early return syntax like `return` and function scope. Instead, we construct something equivalent using `do` syntax. This can be a little weightier than `return`, but the upside is that you can construct other variants of things like early returns that can be more flexible.

me_vinayakakv2• 2 years ago

Nice! Would it be possible to transform an error to something else using this syntax?

Or, should we resort to a method of `Either` that transforms its `Left` in that case?

jose_zap2• 2 years ago

Yes, it is possible to linearize it. You can, for example use do notation:

    result <- do
        a <- someEitherValue
        b <- anotherEitherValue
        return (doStuff a b)

In the above example the do notation will unwrap the values as an and b, but if one of the results is Left, the computation is aborted, returning the Left value.

This is one just of the many techniques available to make error checking linear.

TJSomething• 2 years ago

I've been out of the Scala game for a few years, but I would use a for comprehension with the cats EitherT monad transformer.

https://typelevel.org/cats/datatypes/eithert.html

    def divisionProgramAsync(inputA: String, inputB: String): EitherT[Future, String, Double] =
      for {
        a <- EitherT(parseDoubleAsync(inputA))
        b <- EitherT(parseDoubleAsync(inputB))
        result <- EitherT(divideAsync(a, b))
      } yield result

valenterry4• 2 years ago

Yeah, but Usually we just use something like ZIO nowadays. So the code becomes:

    def divisionProgramAsync(inputA: String, inputB: String): IO[String, Double] =
      for {
        a      <- parseDoubleAsync(inputA)
        b      <- parseDoubleAsync(inputB)
        result <- divideAsync(a, b)
      } yield result

(the annoying wrapping/unwrapping isn't necessary with ZIO here)

You can also write this shorter if you want:

    def divisionProgramAsync(inputA: String, inputB: String): IO[String, Double] =
      for {
        (a, b) <- parseDoubleAsync(inputA) <*> parseDoubleAsync(inputB)
        result <- divideAsync(a, b)
      } yield result

1oooqooq• 2 years ago

What's one big web facing application which handles modern authentication protocols?

whateveracct7• 2 years ago

mercury.com ?

yakshaving_jgt9• 2 years ago

For a bit more context, iirc mercury is at ~2m lines of Haskell over ~10k modules.

nazka• 2 years ago

Is it still true that writing optimized Haskell is extremely hard? Since Haskell is GC, can I write code as fast as say Java or Go?

kevindamm• 2 years ago

This varies by use case and how much / which extensions you're including in your Haskell source (and, to a lesser extent, which libraries being included in the equivalent Java or Go source).

I haven't taken a lot of measurements and my production code is biased to Go, C++, Python and Java, with most of my Haskell experience being side projects and toys for learning from, and writing a type-unifier for a production project. I can summarize what I learned but I would be interested in seeing better measurements.

First, though, let's be more specific about what you mean by "writing code as fast," which I think should be refined to "time spent writing code" + "time compiling code" + "time spent in language runtime" + "time spent debugging / reading code". Depending on your project, and who if anyone is collaborating, each of these might be more or less important. Sometimes runtime speeds dwarf the needs of development or even debugging time. Sometimes compilation speeds afford the quick feedback loop that contributes to flow in development time.

Within that framing, Haskell can excel at development time with small teams and limited scopes. It affords writing a domain-specific language within the code, including very custom operators, and this carries the risk of overburdening with complexity, and strongly proportional to the number of people on the team. Things can get complex fast and it can contribute some to compilation time if there is a lot of recursive complexity to the type system. But if the source is organized well and doesn't need to be very dynamic, this may not be much of a concern. As an underlying engine for very dynamic data inputs and sufficiently complex numerical analysis or IO management as its primary purpose, it would probably do well.

The packaging system (Hackage) is pretty good, and that benefits the development time considerably. Adding some modules may impede compilation times, for much of the same reason as above, the type inference can become expensive. And undisciplined source management can lead to a lot of type implementations that are near copies of each other. Obviously this also ties into the reading/debugging time, too.

For runtime, though, yes Haskell can be competitive with bare-metal C implementations. I think there have been a few papers written about that going back a decade or so.

rebeccaskinner8• 2 years ago

I don’t think optimization in Haskell is much different from any other language. In most cases naive Haskell is pretty fast and memory efficient, but there are some patterns that will make it more or less so. There are a handful of common patterns you can learn that are idiomatic and will generally result in faster or more memory efficient code, and some common libraries that you can use that are more efficient.

There are also some common patterns for less idiomatic but more performant code that you can use as a first pass when you need to optimize things further. Usually that’s sufficient, but when you need to go even further with optimization then it can get hard. Every language can. In Haskell, it usually means starting by dumping core and seeing what the compiler is doing, and getting familiar with the different passes the compiler makes. As a last resort you can also just write in C and use the ffi.

skybrian3• 2 years ago

As far as I've heard, Haskell's type system doesn't normally prove functions to be total; they can diverge. This fine, though, because for ordinary programming, a proof of totality isn't a useful guarantee. You care how long programs actually take to run, not whether they would theoretically finish eventually.

It's only when proving theorems that a mathematical proof of totality matters, and there are specialized languages for that.

For most people, we test in order to make a scientific claim, that we tried running it, and it worked for the inputs we tried, and completed in a reasonable amount of time.

This is true of property testing and even model-checking; in simple cases, sometimes an exhaustive test can be done, but they don't actually prove statements outside the bounds used when testing.

staunton5• 2 years ago

It's perfectly feasible to have proofs about programs together with a guaranteed upper bound on (something like) the "number of processor instructions it will take" (given known finite bounds for all inputs).

Of course, just like any other system that allows correctness proofs, it wouldn't be nearly useful enough to justify the effort for all but a negligible number of applications. That's at least until the levels of effort required are significantly reduced.

skybrian3• 2 years ago

Yes, a theoretical calculation like that would be useful as an estimate. But theoretical performance on ideal machines is only loosely related to performance on real machines under real conditions. That's true of testing, too. Benchmark performance varies even between runs.

So there's still going to be a theoretical math versus science and engineering divide.

Another perspective is that we have a useful division of concerns. Static checking is useful to find some kinds of errors. API's help to ensure that certain things don't change in a new version, so that performance improvements are less likely to break callers.

Depending on the domain, leaving some things like performance and size limits deliberately unspecified in API's seems like more of a feature than a bug? Stricter interfaces aren't always an improvement.

mrkeen11• 2 years ago

As far as I've heard, Haskell's type system doesn't normally prove functions to be total; they can diverge.

This is true. You can write a function which is the natural numbers, and I wouldn't want the type system to preclude it.

  nats :: [Integer]
  nats = [1..]

However, I would love to be able to opt in to declaring functions total on a case-by-case basis, like Idris can.

This fine, though, because for ordinary programming, a proof of totality isn't a useful guarantee. You care how long programs actually take to run, not whether they would theoretically finish eventually.

This wouldn't be the point of the guarantee for me. Haskell functions already give you assurances that you've not made any mistakes:

* You haven't accidentally introduced null, or missed any null checks. * You haven't written code which will do a different thing tomorrow than it did today. * Your function won't race, nor will it cause other functions to race.

If you have a function Foo->Bar, and you give it a Foo, you've all-but-proved that you'll get a valid Bar back. How can you screw that up? By diverging. I'm not trying to put a bound on a long-running function, I just want the type system to make sure the function isn't sucking on its own tailpipe.

skybrian3• 2 years ago

Yes, it would detect a certain class of mistakes where you put an infinite loop or infinite recursion in your code. But I find these are pretty rare, and there would still be other mistakes where on some inputs, it would take a year to run.

adamddev12• 2 years ago

I want Haskell with the tooling, DX, and packages of TypeScript.

yakshaving_jgt9• 2 years ago

I don’t. I don’t think gradual typing is enough to cover for the unprincipled mess that I’ve observed in the JS world over the past 15 years.

adamddev12• 2 years ago

I meant the amount/functionality of the packages one finds in TypeScript, but written in good Haskell. A dream I know.

hugodan• 2 years ago

I'll tell you why, it is simply the best refactoring experience out there. This.

devit2• 2 years ago

I think Haskell is fundamentally a bad design, because there is no reason to not have dependent types and totality checking in such a language, and also laziness is bad as it makes memory usage unpredictable and potentially asymptotically broken.

Basically Rust is much better at producing efficient code with zero abstraction cost (while still doing a decent job at controlling mutation and having an expressive non-dependent type system) and having a large package ecosystem, and Lean, Agda and Idris are much better at being theoretically perfect languages while sacrificing code efficiency, so why use Haskell?

mrkeen11• 2 years ago

I think (s/Haskell/Rust) is fundamentally a bad design, because there is no reason to not have dependent types and totality checking in such a language

devit2• 2 years ago

So far no one has managed to produce a programming language with dependent types that compiles to efficient machine code with zero overhead like Rust and C do, so the reason to not have dependent types in Rust is to be able to produce efficient code (which Haskell doesn't even without dependent types).

Obviously if such a language is possible to make and gets made, it will be the strict best programming language overall and make all other languages obsolete (just like Rust obsoleted C/C++, etc.)

komali2• 2 years ago

All mainstream, general purpose programming languages are (basically) Turing-complete, and therefore any programme you can write in one you can, in fact, write in another. There is a computational equivalence between them. The main differences are instead in the expressiveness of the languages, the guardrails they give you, and their performance characteristics (although this is possibly more of a runtime/compiler implementation question).

Yes, as I like to tell project managers, everything can be implemented.

... But the Google drive sdk is available in python, java, and node.

Tooling, deployment, library ecosystem, and talent pool are just as important when choosing a language or framework as performance, syntax, or guardrails. Unless you have unlimited budget!

revskill• 2 years ago

It is all about monad.

ackfoobar3• 2 years ago

I believe Haskell is worth learning.

But I don't want to spend any more time near purely functional programmers in my professional life, so I will spend some time to unfairly nitpick the article.

a lot of the new features ... are either inspired by, or at least more robustly implemented in, Haskell.

This is like some programmers, who don't know much about the history of programming languages, saying Java is stealing features from Kotlin (a language I enjoy). In both cases the inspiration usually comes from ML (a language family which includes OCaml - a language I deeply admire).

Type classes (first implemented in Haskell) are neat though. I heard that Java is considering adopting them.

Let’s imagine we represented these as plain old strings ... `Theatre String String -- venue name and event name respectively` `checkForSeats :: String -> String -> IO [Seat]`

If your language has named arguments, and sum type cases are records where you have to name your fields, using plain strings is just fine, and probably more ergonomic than wrapping the strings in another type.

`Either AddressParseError ValidAddress`

Real world procedures usually involves many steps which can fail in many ways. The HM type system does not have subtypes. To stuff all possible failures into the `Left` case of `Either` you have to wrap all possible failure types into a sum type, possibly with multiple layers of nesting (huge PITA).

concurrent Haskell

For all the hassle with the IO monad, you cannot offload your understanding of memory model to the compiler when you use an `IORef`.

Maybe most your problems are embarrassingly parallel and STM is fast enough for the rest. Maybe.

exactly encode the effects we want a function to be permitted to perform

https://degoes.net/articles/no-effect-tracking "Effect Tracking Is Commercially Worthless"

See "Tagless-Final Effect-Tracked Java™" for a chuckle.

small sample program

The `Money` type is monomorphic, and `Functor`s are higher-kinded. You get the error message `Expected kind ‘* -> *’, but ‘Money’ has kind ‘*’`

ParetoOptimal4• 2 years ago

To stuff all possible failures into the `Left` case of `Either` you have to wrap all possible failure types into a sum type, possibly with multiple layers of nesting (huge PITA).

Is this not inherent complexity? Is there some language or approach you believe makes this easier? Does it provide the same or similar correctness?

ackfoobar3• 2 years ago

Untagged union types.

psychoslave4• 2 years ago

programming is not maths, and that anything that smells of maths should be excised

Math is not academic gibberish though, and actually often the hard part to make a great conceptual thing work finely in the wild is to give it a more approachable form than the ridiculously arcan soup of greek letters and made up symbols sprinkled with generous quantity of opaque acronyms and words shrinked into trigrams.

Not to say CS/IT industry always shines at making all these better, and it can actually be even more "enthusiast" with acronym jargon in my experience.

No one communicate perfectly, sure starting with me. :D

xigoi3• 2 years ago

Do you think mathematicians deliberately use Greek letters and “made up symbols” (whatever that even means) to make their work less accessible? Or could there possibly be a different reason?

stoperaticless• 2 years ago

To seem cool and get laid.

psychoslave4• 2 years ago

No, at least I think that generally this is not like a voluntary conscious move from individual. Back in university, I remember how often my teacher would not be able to inform me about why this or that symbol was used, they were just reproducing what they had been introduced to without questioning its history and the relevance to keep it forward. Now to be fair, it seems that most people never care about that kind of "details" and are happy to just apply the formula as expected by whoever will assess your performance, get the degree and move forward in their career.

Of course there are a few people out there who do deliberately select an obscure symbol just to put some esoteric vibe on the topic. But I believe that’s definitely not the norm. Lambda as selected by church is almost there, should I believe https://math.stackexchange.com/a/2095748/85628 And in any case I by far prefer "anonymous function" as a term and prefer languages that doesn’t use `lambda` as keyword to implement them (looking at you Python!). Of course, just one symbol is not a big deal, but when each academic out there feels like they need to also introduce their special symbols to feel as special as the ones they admire, we end up with a mess of irrelevantly large number of symbols that don’t really bring a significant addition in term of expressiveness but do contribute to make things harder to grasp.

https://en.wikipedia.org/wiki/Mathematical_operators_and_sym... for what I have in mind about "made up symbols".

djtango2• 2 years ago

For me there is an ebb and flow between Maths (theory) and practice. Humans have long been able to achieve things with loose and intuitive understanding of what they're doing - this usually outpaces theory for a long time while theory struggles to catch up but once it does it tends to unlock a lot more new and interesting things.

You can choose examples like "sun rises in the east" or "things fall down to the ground" or even things like fire to see how we were long able to do useful things before having a deep fundamental understanding of what they were. And while trying to understand them, we had a whole bunch of wrong ideas along the way all while the practitioners got on with their lives.

We also see this in physiological spaces like sports and health. Just the other day I watched a video about how Chopin had some deep intuitive understandings about the anatomy of the hand that was contrarian to his peers but proved to be far ahead of his time.

With programming we have a lot of different theory to dip into: information theory, computer science, systems theory, category theory etc. some of these ideas have been slowly chugging along in academia but the early days of computing were built with dirty for loops, goto and hand crafted assembly or even less. We still managed to put people on the moon with that nevertheless and automated a bunch of commerce and put stuff on the internet - long before most devs had heard of an ML type system

But the ideas from Scheme gave us Ruby Python and JS which unlocked a whole new wave of programming and arguably made it accessible to more people increasing humanity's "productivity" in some sense. I'm sure people who believe in static typing would disagree but YouTube, Instagram and Github were built in these dynamic languages...

psychoslave4• 2 years ago

Just the other day I watched a video about how Chopin had some deep intuitive understandings about the anatomy of the hand that was contrarian to his peers but proved to be far ahead of his time.

Would you be generous enough to share a link to this video, please. :)

IceDane2• 2 years ago

I started writing Haskell in something like.. 2008 or so. Before that, I was an avid low-level programmer that sneered at high level languages that held your hand.

I quickly realized the folly of my ways, however, and became what I would call a Haskell zealot. It was my favorite and most-used programming language, and I even wrote it professionally very early in my career.

As my career progressed and I had to use other languages, Haskell quickly lost its shine. It's just not a very practical language, no matter what they like to claim from their academic ivory tower. I wasn't some sort of novice. I could speak fluent lens and was well-versed in arcane type theoretic concepts, wrote entire data pipelines using recursion-schemes and what have you.

The problem with Haskell it's just way too far out on the spectrum of purity, I think. Everything is way too cumbersome because the language is so rigid. Building real software in Haskell, while trying to make use of its advanced features, is sort of like wanting to do basic arithmetic for your budget, but starting out by proving that mathematics actually make sense. Naturally, you don't have to build your software like that, and it seems like a lot of actually practical haskell apps out there aren't written like this.

Nevertheless, Haskell fundamentally changed the way I view programming and I learned many incredibly useful things, which I have taken with me. Try to keep your functions pure and small. Use static types, and lean on the type system to help you prove that you have covered all cases. Stuff like that.

ur-whale• 2 years ago

Since the syntax is quite distant from C-like syntax

THIS - and none of the other things cited in the article - is the main reason why Haskell is getting no traction in the real world.

The syntax is an abomination, and worse, IMO pretty much unnecessary. The ideas of the language are interesting, and could be expressed in a much more familiar syntax which would be a huge win for the language (although the convoluted hoops you have to jump through when you truly and actually need to mutate data would still be a sheer nightmare).

Haskell's syntax is exactly what keeps it niche and academic, except for the happy few who have managed to twist their brain into being able to parse that grotesque syntax.

fsckboy• 2 years ago

tangential haskell question (I don't know haskell at all)

does haskell have any facility for inspecting the "lazy evaluation queue" in a human readable way? I'm doing some binary-level math-as-logic calculations and I'd like to look at the patterns that emerge deep down, what cancels out and can be optimized away: think of it this way, I want to multiply AxB, where in bits thats (a0 a1 a2...) x (b0 b1 b2...) which turns into a bunch of a0 OR b0 , a0 XOR b0, (don't forget the carries :) etc, which after a few operations in an expression would be really hairy looking but completely straightforward.

so, I can write a little program to do that in any language and print out what happens (lisp/scheme would be a good one). If a wrote a little program like that in Haskell, would it afford me any extra "free" options for inspecting what's going on? where if a0 and b3 where unknown, they'd be variables, but if I had actual values for them they could be evaluated away.

maybe i should ask this as its own thread...

rednafi• 2 years ago

Still “impractical, academic, and niche”

MrResearcher• 2 years ago

I'd love to see a memory efficient and performant implementation of lock-free skip lists written in Haskell, and it'd better beat my C++ implementation!

Laziness incurs amortized costs all over the place, and makes reasoning about the application state more difficult, can you help me justify the cost for the extra electricity?

And, btw, last time I wrote a web server in Haskell, I was very much surprised that the standard way of implementing it was to use lenses, which mimic imperative style of assignments to a variable. And logging. Turned out you need logging for anything real, and in Haskell they are side effects implemented via a dirty hack that can be invoked anywhere.

Finally, you can pry my Knuth tomes from my dead cold hands.

On a more serious note, if you are really into immutability and functional style, F# is deemed to be a far better and practical choice. I reserve only praise for Common Lisp and Clojure, although I typically prefer static typing.

Why Haskell?

Related Stories