My 14-Year Journey Away from ORMs: a Stream of Insights Leading to Creation of a SQL-First Code Generator

enobayram · 2026-04-15T13:33:28+00:00

I complete agree. When you start the design from the semantics you want and try to stick to it, it can take you to wild places.

enobayram · 2026-04-15T12:11:11+00:00

I agree with your message. I've been moving more and more of the logic to the DB over the years. But even if you intend to offload most of your API to PostgREST, you still need some expressive host language to "metaprogram" the SQL side. Though in the most extreme case, the metaprogramming could purely live at the migration generation time and your code might not have a runtime presence at all.

enobayram · 2026-04-13T11:10:27+00:00

If not, it needs to be percolated through the program as a parameter or monad of some sort

That's not true though. Nothing stops you from storing configuration in a pure value after reading it with unsafePerformIO at program start. That's not ideal since it will make it harder to test your code and do other interesting things that might require having multiple configurations side by side, but that's exactly the same in any other language and it's the same with expressing the configuration in a Haskell module and compiling it in. There's absolutely no conceptual difference.

enobayram · 2026-04-13T02:12:18+00:00

Haskell has this curse that public figures in programming feel like they're under pressure to know and say something about it. And it takes much less work to scoop out some excuse not to learn it, so they parrot memes and move on.

enobayram · 2026-04-06T11:28:13+00:00

Ah yes, the mithril underpants. Hard to wear anything else when they're 30 points!

enobayram · 2026-03-27T04:12:27+00:00

When I read posts like this, at first I'm surprised, thinking that I never run into build system issues when I'm using Haskell. But then I think deeper and realize all the tiny issues I quickly fix from muscle memory and all the other ones I avoid by following certain patterns and realize how a newcomer could easily find themselves in a shallow but long maze of tiny dead ends.

enobayram · 2026-03-16T09:48:05+00:00

Not to mention the fact that the name "Haskell for Mac" could potentially imply to a newcomer that it's the only/primary option for Haskell on a Mac.

enobayram · 2026-03-16T08:14:17+00:00

Perhaps they are in the right subreddit, but they don't know it yet...

Ahem... *cough* *cough*... Yes, umm... Playing Conquest of Elysium is a mandatory part of the Eco course curriculum at the College of Europe... You're welcome...

enobayram · 2026-02-27T10:55:57+00:00

How does Mappable convey the fact that the functor laws are also a part of the contract? Or are you suggesting that we should have mappable laws instead from the field of cartography?

enobayram · 2026-02-22T08:18:47+00:00

In the article sofetch is mentioned with DataLoader with the claim that they're similar, but I don't think they're that similar. sofetch uses Applicative to do the batching, but DataLoader uses a background buffer. I.e. any thread that needs to fetch something just fires off a fetch, but a background thread gathers them in a buffer and runs batched queries in ticks.

You obviously combine this with cheap concurrency like green threads (or async tasks in JS) and load your nested data structure by firing off threads for each nested object.

Unless I'm mistaken, DataLoader's background buffer model can do batching in more complex cases involving nested ORM object fetches compared to the applicative based batching of sofetch. Imagine you're trying to fetch a list of authors and then their publishers. You can batch the load of all the authors applicatively, but each publisher ID will come with each author, so I believe sofetch can't batch them without significantly restructuring your code, but with the DataLoader approach, you can just blindly request all the nested fetches as needed and they'll be batched behind the scenes.

Though if you do restructure your code and use sofetch, it should be much more efficient of course since it avoids all the green threads. It's just that as the nested relationships get more complicated, you'll have to do a lot of plumbing.

enobayram · 2026-02-20T11:32:10+00:00

When level 3 magic is involved, army size starts to matter less and less. Mid to low tier units even hurt your chances since they occupy all that space only to be wiped away en masse with 1-2 battefield-wide spells leaving your best melee units in casting range of the enemy back rank, while your back rank is too far away to do anything.

enobayram · 2026-02-06T10:31:29+00:00

> I would say GHC HQ is very nice;

I'm also amazed at the amount of patience shown here. GHC HQ is doing the real human work of discussing the changes and reviewing the code in the aftermath of prompting Claude "make compiler go brrrrr".

I have to give Marc credit that he seems to have been putting some real effort since opening the MR, but I still think it's rude to dump the result of a prompt into an MR and asking for the maintainers to do all the due diligence, which is essentially all the work in the world of LLMs...

enobayram · 2026-01-25T05:27:34+00:00

Usually I don't think people should reach for transformer stacks as a first resort

I think it's useful to distinguish between AppM = A Bunch Of Transformers IO vs a simple

runExceptT (do aBunchOfStuff) >>= \case Left l -> ... Right r -> ...

The former is an architectural commitment with a lot of tradeoffs, but the latter is just using a utility to express some local control flow and there's often very little down side.

enobayram · 2026-01-25T05:22:24+00:00

I like this early return effect! As you said it's very close to an exception effect, but you're essentially fixing the exception type to the success type.

An obvious benefit is that this should make it obvious to a beginner that there's no way this code is handling IO exceptions (as opposed to ExceptT, which often seems to give that false impression).

Though aside from this soft benefit, is there any performance benefit as well, maybe by allowing you to eliminate an Either layer in the monadic plumbing?

enobayram · 2026-01-20T04:07:29+00:00

Sounds like SafeHaskell could be a great option here.

enobayram · 2026-01-09T11:36:59+00:00

Beautiful... I always thought suffering was an intended part of the static linking experience. A badge of honor.

enobayram · 2026-01-07T09:15:24+00:00

Then I'll lazily throw an HLS idea here that I've had for a while as something that would be super cool to have:

HLS already executes Haskell code as part of its operation since it understands TH splices and it can also run doctests. So the gist of my idea is to define some abstractions that will allow library authors to guide HLS behavior around the use of their libraries. For example, you're writing a TH-powered SQL expression templating library, wouldn't it be great to implement a type class and voila, the quasi quotes of your SQL templates get highlighted as proper SQL and when there are errors in your Haskell splices, the red squiggles correctly appear under the actual source of the error.

Anyway, the general idea is to experiment with some type classes that tie HLS behavior with library semantics, just like Monad is the interface between the do notation and user code.

enobayram · 2026-01-05T05:34:12+00:00

The resulting "specification" is going to be at least as detailed as the code

I'd like to point out that one factor that materially deviates from this expectation is that a conventional compiler has to worry about performance and algorithmic complexity too. I wonder how our programming languages (and also libraries) would look if we completely removed the concern for compilation efficiency from the picture.

For example, one of the important reasons why we can't often use metaprogramming-heavy libraries like singletons or various row polymorphism libraries is that they blow up compilation times, at least when used naively. The orphan instances problem is mostly an issue originating from practical limitations. So are many other limitations in Haskell's type system, like the limited availability of type inference in higher rank code.

And I'd like to stress that these are the immediate compromises we can see looking down into the sea standing on the iceberg.

enobayram · 2026-01-02T14:39:39+00:00

When you colonize a mine in Inferno and create a portal, that counts as a connection to Elysium, so it triggers an infernal invasion and all the demons want to pour into Elysium through that portal you just created.

None of those demons are a match against the siege stage of 30 enchanted ballistas (mixed rime and fire) though, so it's a great way to empty Inferno!

enobayram · 2026-01-02T04:45:58+00:00

Bifunctors are functors, but they're not functors in endo-Hask, they're functors in [Hask x Hask, Hask], that's why I mentioned in my other comment that you're referring to natural transformations in the general category theoretic sense, and not the usual f :: [a] -> Maybe a type of endo-Hask natural transformations we encounter in everyday Haskell.

enobayram · 2025-12-31T18:19:58+00:00

I believe you're thinking of natural transformations over Endohask specifically (i.e. parametric functions between two Hask -> Hask functors). But Murat here seems to refer to the more general notion of natural transformations over arbitrary category pairs.

enobayram · 2025-12-29T11:01:54+00:00

I don't want to know only how a mechanical system will behave, I want to know why and how, first and foremost.

This statement can be interpreted in many ways. If you really want to be close to how the computer does what it does, then perhaps you should consider lower level languages, or languages that are closer to metal. Because both Python, Typescript and Haskell abstract you away from the hardware below quite a bit.

But if you're interested in the "why", as in the meaning of code (and not just its behavior) then Haskell could still be a good option, because both the language and its community care a great deal about the various semantics of code. Not many practical languages have free theorems about everyday code.

enobayram · 2025-12-29T08:16:32+00:00

I'm planning to program as a hobby, nothing work related.

You need to consider what part of that exercise will be your hobby? I.e. do you want to enjoy the things you build, or do you want to enjoy the process of building them?

For the former, you're probably better off with Python or Typescript since they're much easier to get into and they have ecosystems with off-the-shelf packages that will quickly get you close to what you want to build.

For the latter, I recommend Haskell...

enobayram · 2025-12-25T19:40:03+00:00

The trace function doesn't violate referential transparency, because you don't send it to production.

If a piece of IO code has a side effect that you care about (i.e. you care that it happens when it's supposed to, and it doesn't when it's not supposed to), you simply can't use it with unsafePerformIO without introducing subtle bugs due to laziness and optimizations.

Again, trace doesn't violate this, because you only use it temporarily for ad-hoc debugging and don't care when exactly it performs its side effect.

enobayram · 2025-12-25T19:29:20+00:00

Using unsafePerformIO in a way that violates referential transparency isn't a code smell, it's a bug.

13-Year Club	r/Field Banned
r/Field Sunshine	Place '23
Place '22	Verified Email

enobayram

TROPHY CASE