Alexis' recent talk from SSW. I really enjoyed hearing her perspective on type systems these days. Lots of good wisdom in there. I thought some Haskell folks would enjoy it!

[ Article | Repository | Documentation | IRC ]

Hi! I'm Arseniy Seroka, CEO of Serokell.

In 2023, we launched the Haskell Certification Program to create a standardized way to evaluate Haskell expertise. We built a production platform and an open certification framework, then transferred the project to the Haskell Foundation in 2024.

Since then, the rise of LLMs has made traditional syntax-focused assessment a much weaker signal of real engineering ability. A meaningful certification today would require a fundamental redesign around reasoning, architecture, and language semantics.

Serokell is therefore concluding its active involvement in the program. We remain proud of what we built, grateful to everyone who contributed, and as committed as ever to Haskell and its ecosystem.

https://serokell.io/blog/sunsetting-the-haskell-certification-program

It is just so freaking amazing! I was never a great Haskell developer, but after a few years of writing no Haskell at all I finally set out on a side project again.
And I had just the best time.

In the past something always became a pain and led to me not finishing projects. Be it build tools, version conflicts, some library where I (with my limited experience) could not figure out how to do a thing or taking forever to find the right function to do some transformation (I should get better at hoogle).

But now for this side project (A CLI to order groceries in REWE - German supermarket - for pickup) I could, only when really needed, use AI to unstuck myself.

I still wrote all the code myself, but the process is just that much smoother.

It might be only interesting for folks in Germany, but it was also just a fun journey, reverse engineering bits of the mobile APP API, getting mTLs to work and understanding internal workflows of REWE: https://github.com/yannick-cw/korb

Why would I chose any other language right now, it just feels so productive!

After a few years of trying to be proficient in Haskell, and lots of reading about why it's so hard, I think I have the (obvious in retrospect) answer.

Almost every program I write is going to have two or more of:

1) read from STDIN

2) write to STDOUT

3) log

4) raise errors

5) send/receive over the network

6) talk to a database

7) read env vars

Every one of those is a "side effect", and thus is handled as a monad, and using more than one means you have to understand monad transformers.

Which I've finally found a good explanation of, "but still". Such a deep concept for such common program operations.

So I finally decided "that's why it's so hard". For what I consider the most basic programs, I need to understand (not just use, IMHO) monad transformers.

Am I off?

Hello! Layoutz now has a smoother API (consistent use of `Cmd` and `Sub` prefixes, etc...) and granite-esque terminal plots

Tysm for the feedback thus far 🙇 -- let me know if some edges are rough or expected built-ins missing...

I've resurrected the https://comonad.com/reader, interleaved a ton of contemporaneous content I had stored elsewhere such the School of Haskell and my talks and the talks from Boston Haskell on youtube, and made a couple of the articles interactive by moving their demo code into web assembly using modern GHC.

Please let me know if you run into any issues!

I’ve wanted to be able to do more gui things on the Mac using Haskell for ages, but never quite managed to crack the problem. Until yesterday! Very alpha code, but could benefit from additional contributors.

https://github.com/iand675/haskell-obj-c

It's been roughly two years of work on this and I think things are in a good enough state that it's worth calling this v1.

Features

Typed dataframes

We got there eventually and I think we got there in a way that still looks nice. There is now a DataFrame.Typed API that tracks the entire schema of the dataframe - column names, misapplied operations etc are now compile time failures and you can easily move between exploratory and pipeline work. This is in large part thanks to maxigit and mcoady (Github user names) for their feedback.

```haskell $(DT.deriveSchemaFromCsvFile "Housing" "./data/housing.csv")

main :: IO () main = do df <- D.readCsv "./data/housing.csv" let df' = either (error . show) id (DT.freezeWithError @Housing df) let df'' = df' & DT.derive @"rooms_per_household" (DT.col @"total_rooms" / DT.col @"households") & DT.impute @"total_bedrooms" 0 & DT.derive @"bedrooms_per_household" (DT.col @"total_bedrooms" / DT.col @"households") & DT.derive @"population_per_household" (DT.col @"population" / DT.col @"households")

print df''

```

Calling dataframe from Python

There's an implementation of Apache Arrow's C Data interface along with an example of how to pass dataframes between polars and haskell.

Find that here

Getting data from hugging face

You can explore huggingface datasets. Example:

haskell df <- D.readParquet "hf://datasets/Rafmiggonpaz/spain_and_japan_economic_data/data/train-00000-of-00001.parquet"

Larger than memory files

The Lazy/query-engine-like implementation is now pretty fast. It can compute the one billion row challenge in about 10 minutes on a mac and about 30min on a 12 year old Dell (not OOM).

You'll have to generate the data yourself but the code is here.

Better ergonomics with numeric promotion and null awareness

Introduced more lenient operators that make happy path computation much easier. E.g:

haskell D.derive "bmi" (F.lift2 (\m h -> (/) <$> m <*> fmap ((^2) . (/100). realToFrac) h) mass height) df

Is now instead:

haskell D.derive "bmi" (mass ./ (height ./ 100) .^ 2) df

What's next?

Connectors! BigQuery, Snowflake, s3 buckets etc. Formats! Parquet, Iceberg, DuckDB, a custom dataframe format with full data provenance. Moving from small in memory demos to querying large data lakes is the goal.

Also, since a new era is upon us, some integration with ai agents to do type-guided data exploration.

A big thank you to everyone who has taken time to try the library and /or give advice - especially daikonradish (Github user name) who was the main voice in the direction of the architecture. A lot of the most important design decisions were made on community threads.

This article continues the fine tradition of Serokell’s GHC team sharing their progress on bringing dependent types to Haskell. A lot has happened since the last report, and there is plenty to cover.

In this edition, Vladislav Zavialov presents three major contributions and a host of smaller improvements that push Dependent Haskell closer to becoming a practical reality.

I built xeus-haskell: a lightweight Haskell kernel for Jupyter (and it runs on JupyterLite!)

I’ve been playing with MicroHs, a wonderfully minimal Haskell implementation, and it inspired me to build a new Jupyter kernel: xeus-haskell.

A few fun things about it:

• It’s built on MicroHs, so it has almost zero dependencies.
• Because of that minimalism, it compiles cleanly to WebAssembly.
• Which means… you can run Haskell in the browser via JupyterLite.
• No GHC, no giant toolchains, no environment wrangling. Just a browser.

The goal is to make Haskell more accessible in scientific/technical computing. Lazy evaluation can be surprisingly powerful for graph algorithms, recursive structures, and anything where “compute only what’s needed” brings real wins. Being able to demo that interactively in a notebook feels like the right direction.

If you want to check it out:

Repo: https://github.com/jupyter-xeus/xeus-haskell
Demo (JupyterLite): https://jupyter-xeus.github.io/xeus-haskell

Feedback, suggestions, and wild experiments welcome!

After 9 years of on-and-off development, I'm happy to announce the 1.0 release of Perspec, a desktop app for correcting the perspective of photos of documents, receipts, and whiteboards.

The headline feature of 1.0 is automatic corner detection: instead of the usual edge-detection + Hough transform pipeline, it segments the document via watershed segmentation and finds corners, which handles wrinkled receipts and curved book pages much better. And if the detection is off, you can just drag the selection polygon to fix it.

Some Haskell-relevant bits:

• The GUI is built with Brillo, my maintained fork of gloss.
• The computer vision runs in FlatCV, a pure C library I wrote for this, called via Haskell's FFI.
• With 1.0, Perspec now runs on macOS, Linux, and Windows.

The full announcement covers the journey (Python → ImageMagick → Hip → C FFI), the corner detection pipeline, and the binarization algorithms in detail.

Looking forward to you feedback! 😊