Hacker News Reader

Comment by agentultra | Hacker News Reader

Haskell is much closer to the lego blocks analogy than most languages I've tried due to the focus on composition and polymorphism.

The teetering edge that grinds some people's gears are monads which don't compose generally but do compose in specific, concrete ways a-la monad transformers. The next breakthrough here, I think, is going to be the work coming out of effect systems based on free(r) monads and delimited continuations. Once the dust settles here I think we'll have a good language for composing side effects as well.

In the current state of things I think heart-surgery is an apt metaphor. The lego brick analogy works for small, delimited domains with denotational semantics. "Workflow" languages and such.

View on HN

I like Haskell, I write Haskell at my day job (and did so at my previous day job), and I help maintain some of the community build infrastructure so I’m familiar with a large-ish graph of the Haskell ecosystem and how things fit together.[0]

I don’t really think Haskell is _meaningfully_ superior than other languages at the things that OP is talking about.

Refactoring Haskell _in the small_[1] is much nicer than many other languages, I don’t disagree on that point. Despite this, Haskell applications are _just as susceptible_ to the failures of software architecture that bind components of software together as other languages are.

In some cases I would even suggest that combining two Haskell applications can be _more_ fraught than in other languages, as the language community doesn’t have much in the way of agreed-upon design patterns that provide common idioms that can be used to enmesh them cleanly.

[0] I’m mostly belaboring these points to establish that I’m not talking out of my ass, and that I’ve at least got some practical experience to back up my points.

[1] This is to say when one refractors individual functions collections of interlocking abstraction

I think what OP was hitting on is that functional programming likes to put function composition front-and-center.

Glomming together functions that operate on very abstract data structures feels a lot more like Legos than wiring traditional imperative/OO code.

> Despite this, Haskell applications are _just as susceptible_ to the failures of software architecture that bind components of software together as other languages are.

I think it's more complicated than this. Yes, you can push poorly-architected Haskell to production & be in a rough spot. However, my experience says that even the gnarliest Haskell is easier to improve than any other language.

Because of the types, purity, etc, I find that it's much easier to zoom around a codebase without tracing every point in between. I can typically make one small change to "crack things open" [1], follow GHC's guidance, and then go from there. I've been able to take multiple large Haskell projects that other engineers deemed unfixable (to the point where there were talks of rewrites) & just fix them mechanically and have them live & improve continuously for years to come.

The big thing with Haskell IME is you don't really need to have design patterns that everyone follows. I don't freak out when I see multiple different idioms used in the same codebase because idgaf about folk programming aesthetic. If an idiom is used, I follow it. It's all mechanical. I barely use my brain when coding professionally in Haskell. I save it all for the higher-level work. Wish I could say that about professionally programming in other languages of equal experience :/

So while it's just as susceptible (because good vs bad software architecture is more a function of time & effort) it's also typically pretty braindead to fix.

[1] A favorite technique is to add a new case to a key datatype and have its body be Void. Then I just follow the pattern match errors & sprinkle in `absurd`. I now have a fork in the road that is actually a knowably a no-op at runtime.

WAI is a great example on the sort of compat/interop interfaces that are more common and easier to rollout in Haskell than in non-(typed functional) languages.

https://github.com/yesodweb/wai

Like WSGI or RACK?

What things make WAI easier than the equivalent abstraction in $other_languages?

(Not going for a "gotcha" tone here, genuinely interested as a person who has tried and failed a few times to write "useful" software in Haskell. Would like to get there one day).

A WAI `Application` is defined as the following type alias:

  type Application =
    Request ->
    (Response -> IO ResponseReceived) ->
    IO ResponseReceived

...which is to say that WAI applications are “just” functions that accept an incoming request and a callback that turns that request into a response object (which may emit side effects), and which return a respond object (which may emit side effects).

This leads to a very nice definition for middleware as the following type alias:

  type Middleware =
    Application ->
    Application

...which says that any WAI middleware is just a function that turns one application into another.

This means that WAI applications have a nice and easy to understand top-level interface, and that complex chains of WAI middleware can be built up by chaining smaller middlewares together.

The potential benefit here (over other language frameworks) is that the “grammar” being used to describe applications and middleware is the same “grammar” that’s used in most other Haskell applications (i.e. function composition). Ideally, this should make it more easily understandable to a Haskell practitioner who might not be intimately familiar with the framework at first glance.

Not to be trite, but uh... like WSGI or Rack?

I think the specifications are functionally equivalent and differ only in their approach. I think WAI is influenced directly by WSGI/RACK.

You've got far more Haskell experience than I do, but I have done some pretty heavy refactoring on large java codebases. The process always seemed to be, tease out some interfaces and switch the implementation of those interfaces. Over and over and over. I could lean on javac and tests but some knots are hard to untangle and take a long time.

I believe you that the in the large it's still hard. It seems so much more pleasant day to day untangling that big ball of string with Haskell rather than Java.

That’s the whole point of functional programming: composition of small things to make bigger things.

Functional programming does it better - but it still suffers from the issue that when developing a programming solution we developers need to account for all edge cases (if we're doing it right) which requires a lot of decisions to be made. The important decisions for the use of the module will be carefully made - the less important decisions will be arbitrarily made. Almost no uses of the module will encompass a need for every edge case to be decided in a specific direction but when that module is reused the new consumer will probably have a slightly different requirement about which decisions go which ways - this, I think, is the central pain point of software reuse.

Completely agnostic problems do exist and modules to solve those can be very strong - but that is a small subset of all the problems we want modules for.

Careful decisions can scale with abstractions, if they're made with some rigor.

In Python, for example, whenever I'm doing operations on lists, I need to consider every function in isolation - will this break for an empty list (zip), or will it break when given a generator (anything that traverses twice)? If I pass a callback with side effects, how will it behave differently if someone calls it twice?

In a a more rigorous ecosystem, I can instead only worry about edge cases on classes of functions/data types - In Haskell, when doing the same operations, I can generally assume that traversal functions were written with consideration for functor/foldable/traversable laws, and those laws tell me how I can safely compose or swap them out without breaking expectations around those edge cases. Higher Kinded Types let code be constrained to work strictly with those abstractions, so I mostly just need to worry about "does this typecheck" and, very rarely, "is this an unlawful traversal". With things like linear and dependent types entering this mix, library authors can communicate even more subtle expectations at compile time instead of leaving users to try to anticipate them or find them at runtime - when you do need to explicitly consider edge cases, the turnaround time on discovering them is important.

I don't disagree - these sorts of questions can be worked out to an academic degree with rigorous proofs. Databases and data guarantees around them are very widely applicable and have been isolated from business logic in modern applications due to the heavy complexity of that logic - once upon a time it was common for applications to "roll their own database" i.e. build some custom data storage approach that worked well enough (hopefully) for their purposes. I worked on a MUD based off a legacy that began in the 80s that used flat-file storage as a primary data storage method and race conditions abounded.

However, databases are cost effective to build and distribute, but implementing that level of rigorous proofs for your e-commerce app is not only generally undesired but often increases the difficulty in reaching profitability and can sink a company. Working on system development isn't limited to academic concerns, if you're guiding project development you have to make really hard calls about correctness vs. cost and I say this as someone who likes to be a perfection and do things the right way whenever possible.

So I don't disagree that careful decisions can scale with abstractions - it isn't the case that it is impossible to build a well designed large system, but it will be expensive and at the end of the day we all (probably?) need to balance cost of investment vs. value of that investment - or are having someone higher up the chain making that decision for us.

I think learning to program for correctness has a cost, but it's a skill that stays with you. Once you know how to properly model things in a composable way you can definitely work just as fast or even faster as when you gave no care for correctness. And frankly, shipping an incorrect program isn't really necessarily a worthy tradeoff as you are simply deferring problems to the user or to later down the line. And you don't need rigorous proofs to enjoy the correctness protections from strongly typed languages like Haskell. The language does that for you, you just have to learn to model in them which is a one time thing.

I didn't need an academic degree to start working in Haskell and learn abstractions such as "Traversal" or any of the others. Most of them are painfully simple compared to the impression one gets from their names and the jargon that comes with the territory.

However the benefits of sticking with those names and jargon is that it only needs to be explained once. Analogies and metaphors help when you're starting out but you don't need to keep them around. It makes speaking precisely with colleagues in the ecosystem easier.

Proofs are on another level. I've also written proofs and they require much more rigor than you will find in Haskell. It can still be done without a degree but I agree -- not useful for most line-of-business applications.

However the power-to-weight ratio of learning the abstractions available in Haskell is smooth. It takes effort to acquire but it pays off in spades. That's where the "scale" comes from.

Polymorphism combined with composition means that once I know a type implements "Traversal" I can use the entire language of traversals with those data types without knowing anything else about the value I'm working with. The more things that implement traversal the more rich my program becomes.

You do get this idea of composition in the form of generics or template metaprogramming, not lost on me there. Type classes in Haskell, in my humble opinion, are better at consistency, keeping things coherent, and requiring less nominal boilerplate.

Yes but that's what composition solves. If the module as a whole cannot be used, you can just recompose the parts. As long as you've made clearly defined modules/functions all the way down with clearly defined inputs and outputs.

To be fair, that was also the major point of OO, and of structured programming before that.

Could you elaborate?

I'll go one further. Can you think of a single programming paradigm in which "composition of small things to make bigger things" isn't a fundamental design principle? A paradigm where making big things from small things is actually an anti-pattern?

Well if I were doing object oriented modeling I may have a `class Person` and some methods that operate on some Person data specific to my model. For example, I may model the person with name, age, job, and gender as a boolean... but in 2020 I may have to then reimplement the gender field entirely. If I later decide to have a `class Pet` it may share some common fields except for the "job" field. Having done this I may now do the opposite of composition in that I'm now factoring out the common properties of a Person and Pet and breaking them into smaller components rather than assembling them from smaller components. If I were doing this functionally and strictly typed I'd have started out with the leaf types of age, job, and gender that were agnostic to their owners (Person or Pet). They'd be implemented in pure way without dependencies or knowledge of a Person or Pet, can be tested and developed before any part of Person or Pet are implemented. Yes you could also compose classes, which are bundles of functions... but if you take that to the next level you'd get function composition.

It's not that you can't do composable software with OOP... it's rather that functional programming is all about composition.

You don't need haskell to make applications compose

See JVM (garbage collection), React, Datomic

Functions and scalar values is probably enough

Reply on news.ycombinator.com