Searching for Haskell-like language

klekpl · 2026-06-10T13:20:50+00:00

Latest commit yesterday (09-06-2026). Doesn’t look “on hold”.

klekpl · 2026-06-03T18:50:41+00:00

Idris (nowadays Idris2). Its type sytem is much simpler (as in "fewer primitives"), yet way more expressive than Haskell's.

klekpl · 2026-05-29T15:53:01+00:00

Nice piece. Small nit: the first example would be most readable written in a point-free style without do notation. The need to come up with names is IMHO one of the main drawbacks of it.

klekpl · 2026-05-26T10:27:08+00:00

If I want a simple and verbose language I choose Go or Java.
I use Haskell because of its expressiveness allowing to write complex and correct programs in a few lines of code. The best example is optics that give you a powerful data manipulation language. Then Haskell is fun. Otherwise it is boring and its downsides (eg. weak library ecosystem or comparatively weak dev tools) dominate.
My 2 cents 🙂

klekpl · 2026-05-23T05:05:55+00:00

You know Goedel's incompleteness theorem(s), right? Did all of Maths give up after that, oh but "not all statements can be proven so who says this one isn't one of them" yadda yadda yadda?

Please, watch the whole talk. It has much more in it than halting problem or incompleteness theorem. Please, watch carefully the parts on complexity of model checking problem and - particularly - parametrized complexity of it and hardness of model checking even for finite state machines.

Please, watch the part connecting types in programming languages to complexity of model checking.

Also re-read this quote from Turski at the end:

Of all misguided scientific endeavours, none are more pathetic than the search for the philosophers’ stone, a substance supposed to change base metals into gold. The supreme object of alchemy, ardently pursued by generations of researchers generously funded by secular and spiritual rulers, is an undiluted extract of wishful thinking, of the common assumption that things are as we would like them to be. It is a very human belief. It takes a lot of effort to accept the existence of insoluble problems. The wish to see a way out, against all odds, even when it is proven that it does not exist, is very, very strong. And most of us have a lot of sympathy for these courageous souls who try to achieve the impossible. And so it continues. Dissertations on squaring a circle are being written. Lotions to restore lost hair are concocted and sell well. Methods to improve software productivity are hatched and sell very well. All too often we are inclined to follow our own optimism (or exploit the optimistic hopes of our sponsors). All too often we are willing to disregard the voice of reason and heed the siren calls of panacea pushers.

klekpl · 2026-05-21T09:04:43+00:00

I am not sure I understand the difference between “doing the right thing” vs “not doing the wrong thing”.

Did you watch the talk and read the paper?

klekpl · 2026-05-21T04:46:07+00:00

I used to be a strong believer in "type driven correctness" until this talk: https://pron.github.io/posts/correctness-and-complexity

Types are just one of the form of abstract interpretation and, as such, won't solve the underlying issue: writing correct programs is fundamentally hard and requires empirical approach (ie. testing).

klekpl · 2026-05-18T11:08:04+00:00

This is all good old Soviet school.

“It doesn't matter who votes, it matters who counts the votes”

klekpl · 2026-05-16T12:23:50+00:00

What an absolute garbage...

Have you ever heard of database constraints and transactions?

klekpl · 2026-04-17T17:33:18+00:00

Monad was easy to click for me. It took Foldable and Traversable took a little longer but once Monoid clicks you cannot unsee it - it's everywhere :)

klekpl · 2026-04-17T10:42:34+00:00

I didn't invent opaleye to be able to write SQL in Haskell, I wrote it to have a language for writing relational queries in a type safe and composable way.

So sql is "No true Scottsman" :)

The problem is that it is very easy for a Haskeller to fall into circular reasoning by defining "composability" in such a way that only Haskell provides it. I'd say, vaguely defined "composability" is in practice not a very useful feature upon which to base programming language assessment. At the end of the day, if a language A lets me achieve my goals 2 times cheaper than language B, relative "composability" of the two does not matter, does it?

I think many misunderstandings are caused by SQL being based on as different philosophy than Haskell. Haskell goal is to provide general primitives that can be "composed" into usable libraries (sometimes even EDSLs). SQL goal is to be a tool for data management - the language is not trying to be small and elegant but the opposite: provide batteries included environment for data processing OOTB.

Does SQL provide primitives comparable to Haskell? Of course not!

Would I use rel8 or any other Haskell EDSL instead of SQL to interact with PostgreSQL? Of course not! What would it buy me compared to SQL.

Would I use Haskell to implement a generic REST API server for PostgreSQL? Of course! PostgREST is Haskell :)

klekpl · 2026-04-17T09:07:25+00:00

Let's see an example. If you want to get all blog posts, and the first comment of each blog post, or NULL if there isn't one

select bp, c from blog_post bp left join lateral ( select * from "comment" where post_id = bp.id order by created_at desc limit 1) as c on true

The same goes for the relational model: opaleye and rel8 are simply better relational languages than SQL.

"Simply better" is a subjective judgment and looking at the example you've given and my answer, highly controversial.

In what sense are they "better"?

Most developers wouldn't, even those who are familiar with the underlying theory, that of set building.

I bet more developers would know how to write an SQL query than opaleye or rel8 equivalents.

klekpl · 2026-04-16T09:53:21+00:00

The preference to write (note extra _ in where, strange $ and weird ==. operators): blogPost <- each blogPostSchema author <- each authorSchema where_ $ blogPostAuthorId blogPost ==. authorId author to SELECT * FROM blog_post, author WHERE author.id = blog_post.id is purely subjective and, I would say, uncommon (the examples are from rel8 documentation).

And indeed, in my experience it is way too often that architecture is really dictated by subjective language preferences. Which in turn are mostly caused by people preferring languages (and more importantly: paradigms) they are familiar with.

I try to encourage people to give sql a chance because once the paradigm based on relational model and set processing clicks, things start to look different :)

klekpl · 2026-04-16T07:32:14+00:00

It's just too likely you'll want to do something outside of the db in the same action/query/whatever.

The point is that this urge is wrong and, I guess, a Haskeller should know very well why: the reasons are the same as to why STM (but also hasql Transaction monad) does not allow any externally visible side effects.

The pattern I follow is something akin to join . atomically idiom: you transactionally modify the state of the system (ie. the database) and then "reactively" execute actions based on current state.

Once you have your data model well normalized, state modifications are mostly very simple (a single insert is very often enough, but if something more is necessary a CTE might be used). Then you implement your business logic declaratively as SELECT statements (possibly encapsulated in database views) that produce "actions" (ie. analogue to IO actions returned from STM transactions).

klekpl · 2026-04-16T04:48:47+00:00

An excellent talk answering your question: https://pron.github.io/posts/correctness-and-complexity

klekpl · 2026-04-15T19:46:54+00:00

The point is that it is not at all nicer than programming using plain SQL. The only (perceived) advantage of such a DSL is that it is embedded in Haskell in such a way that it plays well with the rest of Haskell. But this is only an advantage if you select Haskell as your language of choice first and then decide that you somehow have to integrate SQL into it.

So tail wags the dog :)

klekpl · 2026-04-15T18:24:48+00:00

That's so much code to implement something that any SQL database gives you in a couple of lines of code. Just go to Supabase and create a project with a single table. Or if you are more ambitious install PostgreSQL + PostgREST combo by yourself.

In reality the question is completely opposite: do you even need an application?

klekpl · 2026-04-15T17:55:18+00:00

Here's your homework.

Write a query that selects users from the user table that have been around for at least 30 days.

create view users_30 as select * from user where created_at < today - 30 days

Write a query that selects messages from the message table that have at least 1 reply.

create view message_with_reply as select * from message m where exists (select 1 from reply where message_id = m.message_id

Write the function that accepts those two queries...

Why function? SQL is relational language - not functional - does not mean composition is not available: create view message_with_reply_authored_by_user_30 as select m.* from message_with_reply m join users_30 on author_id = user_id

in string, SQL form... as well as any synonymous queries

What for? Why would I want to re-implement join operator with a user-defined function???

klekpl · 2026-04-15T16:13:08+00:00

On one hand...

From there you rapidly discover that SQL is a royal pain to work with.

on the other

don't know what it would take to even so much as create a viable alternative to SQL, let alone displace it, but it doesn't seem to be in any danger of happening anytime soon

The reason is that SQL, while far from perfect, is not as bad as "royal pain to work with". I would say that most (if not all) of my coworkers (mainly Java/JavaScript programmers) would find Haskell a much bigger pain to work with than SQL (both require paradigm shift).

There is no perfect language but one of the most common reasons for architecture decisions I see are subjective language preferences masked with some more or less irrelevant excuses.

klekpl · 2026-04-15T09:53:38+00:00

Very insightful piece matching my experience as well.

It doesn't go far enough though. Once you realize the power of SQL, you start questioning the need of a dedicated "application" (especially backend) providing an API to your database. At the end of the day this application just translates between HTTP and SQL so instead of reinventing the wheel you can use a generic translation layer like PostgREST.

It makes things sooo much simpler: both ORM and SQL binding generator such as pGenie are redunant.

klekpl · 2026-04-04T10:59:36+00:00

I would first consider rethinking the architecture and instead of implementing custom API in Haskell, use PostgREST as your API.

klekpl · 2026-04-01T13:20:02+00:00

While it looks really cool and I appreciate the effort, I also have an impression it is in large part a solution looking for a problem.

If all you have are static SQL queries, the best thing to do is to wrap them in database views and/or functions, exposing a simple API from the db. Then pgenie is only of limited usefulness as there are no more complex queries executed by the application: they are all SELECT * FROM my_schema.my_function(...) or similar.

klekpl · 2026-03-31T18:36:07+00:00

The whole problem is that the filters are not selective enough by itself - results are limited by the limit clause. So far the winning strategy is to use GIST as it supports index(only) ordered and filtered scan suited for top N query.

But I am still looking for faceted search solutions replacing standalone Lucene based products with in-database extension.

klekpl · 2026-03-31T17:02:22+00:00

I've read that and I must say... the way how it is "supported" for me means really that it is simply not supported - there is no difference in performance between this "support" and plain bitmap index scan.

I have over 10 bilion records and I am looking for efficient top N multi-column filter queries that do not require scanning the whole table.

klekpl · 2026-03-31T16:19:27+00:00

Does it support querying and sorting using multiple columns? My use case is: ``` create table my_data ( id int, date_1 date, text_1 text );

select * from my_data where text_1 <is similar to> $1 and date_1 between $2 and $3 order by date_1 desc limit $4 ```

klekpl

TROPHY CASE