chreke

chreke

@chreke.com

Functional programming enjoyer Co-founder of https://functionalsoftware.se Personal website: https://chreke.com Sometimes I write stuff here: https://blog.snork.dev/

298 followers286 following754 posts

What is a null coalescing operator but a poor man’s monad? What is a pipeline operator but a poor man’s method call?

The Func Prog Podcast is back with another episode! I sit down with Adam Tornhill, the founder of CodeScene, to discuss technical debt, Clojure, and why it’s so hard to write good code. Listen below! 👇

People on twitter will really be like "you believe in writing raw SQL? that pales in effectiveness to my strategy, using a model abstraction layer so I can switch RDBMS at any time" and then never switch RDBMS

What better way to start your weekend than a new episode of the Func Prog Podcast? In this episode I talk with @giacomocavalieri.me about the @gleam.run programming language—we had a great time and covered a bunch of interesting topics! Links in comments 👇

Hot take: We need to rethink how we build distributed systems (read: web apps). The old three tier model of client–app server-database needs to go. For basic use cases it works well enough, but as soon as you introduce complex transaction logic, or high load, it breaks.

View full thread

Since the database code can't "see" the application code (and vice versa), it's very easy to introduce deadlocks, race conditions, etc. Static analysis is of little help here.

Here's my modest proposal: Stop moving data between your application and the database; instead, move the database into the application. Use a low-level store (e.g. RocksDB) for persistence and language-level primitives for concurrency control (a good use case for Rust?)

Hot take: We need to rethink how we build distributed systems (read: web apps). The old three tier model of client–app server-database needs to go. For basic use cases it works well enough, but as soon as you introduce complex transaction logic, or high load, it breaks.

SQL is convenient for fetching data, but its concurrency primitives are lacking. What's worse, the application and the database need a shared understanding of what resources are owned by whom. This creates a lot of ugly, brittle code.

Can we replace SQL with functional programming? We take it as a given that relational languages are used to query databases, but there’s no reason we couldn’t use a language based on the lambda calculus!

The most important property of a query language is that we can rewrite an expression to a more efficient one, and get the same result back—this is the core of query planning. The simply typed lambda calculus supports this as it’s referentially transparent

it’s interesting that you could basically emulate type classes with explicit dictionary passing and row typing. i guess you could also implement monad transformers like this?

apropos something @welltypedwit.ch told me back on cohost—you really want some kind of polymorphism if you’re going to implement an effect system. so you could probably use row-typed dictionaries for this as well?

chreke reposted

You’re absolutely right — you are Pagliacci. It would certainly be difficult for you to attend your own performance! I should not have given such paradoxical advice, and I apologize deeply for the error. There is no excuse for my failure.

New episode of the Func Prog Podcast! This time I’m chatting with Robert Kreuzer from Channable about using Haskell in production, getting a job as a Haskell programmer and an epic Haskell VS Rust showdown! Listen to it in your favourite podcast player—links below!👇

> be me, an europoor > buy soda in plastic bottle > tear off the cap because I’m My Own Man, brussels goons can’t tell me how to live my life > immediately lose the cap, can’t close bottle > fuck my eurochungus life

Are you a Django wrangler looking for your next adventure? Then I have the job for you! If you’re looking for a new adventure and are based in or around Stockholm, Sweden, send me a DM!