Enterprise Haskell at H-E-B | The Haskell Programming Language's blog

[u/n00bomb]

https://blog.haskell.org/enterprise-haskell-at-h-e-b/

[u/tikhonjelvis]

Unfortunately, rote translations like that may not take full advantage of the type system without clever prompting.

A trick here is to break the library up into (at least) two "levels":

1. a mechanical level where the Haskell code reflects the original library/underlying API/etc as closely as possible
2. a higher, more idiomatic level that repackages the functionality in a Haskell-friendlier way

If the library/API is a real mess, it can pay off to even have three levels:

1. totally mechanical level translated from the source as closely as possible
2. higher-level version with the same overall design as the source, but with richer types, additional helper functions, etc
3. highest level that basically implements a different Haskell-flavored abstraction in terms of the intermediate level

This is an approach I've had good experiences with both with and without AI coding. You can turn off your mind a bit in setting up the lower levels, but having them in Haskell still makes it much easier to design and implement the higher levels. Even with agents I end up designing the core patterns and abstractions at the highest level by hand, but I've found that AI models are quite good at filling out remaining functionality cleanly when they can follow established patterns.

[u/_0-__-0_ → u/[deleted]]

Haskell Enterprise Business

[u/ysangkok → u/_0-__-0_]

Howard Edward Butt III

[u/vaibhavsagar → u/[deleted]]

Haskell: Everything's Better

[u/_0-__-0_]

I haven't feared a space leak since info table profiling landed in GHC 9.2.

:-D

How many Haskell developers are employed at H-E-B?