New blog post is up. It discusses a graphical notation to describe and understand various kinds of optics, like lenses and prisms
https://marcosh.github.io/post/2025/10/07/the-mondrian-introduction-to-functional-optics.html
New blog post is up. It discusses a graphical notation to describe and understand various kinds of optics, like lenses and prisms
https://marcosh.github.io/post/2025/10/07/the-mondrian-introduction-to-functional-optics.html
I wrote another blog post on several ways to declare an interface in #Haskell
https://marcosh.github.io/post/2025/07/22/four-ways-of-declaring-interfaces-in-haskell.html
Today I probably implemented the most useless #php class I could think of
https://github.com/marcosh/lamphpda/blob/master/src/Unit.php
I'm back to blogging after a fairly long time with a blog post on how to combine effects using natural transformations
https://marcosh.github.io/post/2025/03/10/combining-monads.html
Really interested to know what people think of it
A couple of posts recently reminded me of this article by Frank Quinn
https://www.ams.org/notices/201201/rtx120100031p.pdf
about, in part, how math education is stuck in the 19th century meaning: there was a huge shift in math in the early 20th century to make definitions precise and self-contained and proofs more rigorous so that they made no appeals to intuition about the physical world. This results in definitions that may seem more opaque at first, but that one can understand by working with them, and that are equally usable by everyone.
The way that math is usually taught, it is not even clear which things are definitions and which things follow from them. I defected from physics to math because I could never understand what "appealing to physical intuition" meant which is a common refrain in mechanics classes (less in quantum mechanics :)).
Only semi-relatedly: it's a shame that, through the beginning of college, math is taught as an unwavering march to calculus when high school students could easily learn basic group theory and topology and, I'm sure, would love it. "You can study tiling patterns using algebra?! Cool!!"
Anecdotally, it seems like a decent number of functional programmers do not particularly like math in school, but fall in love with the math they encounter in fp. It is such a missed opportunity that they have to stumble into it that way.
To reprise one of my common refrains: I think everyone, especially software engineers, and extra especially functional programmers, should learn some algebra by which I mean: sets and functions, the basics of linear algebra, and the basics of group theory. Here are some references I like, then I'll stop going on about this for a little while and go on about other stuff.
Chapter 0: Preliminaries in Dummit and Foote (googlable pdf) is 8 pages including exercises and covers sets, functions, equivalence relations, modular arithmetic, and gives some previews of group theory. Skimming Chapters 1-3 would make a good introduction to groups. Harvard's entire abstract algebra course is also free on youtube[0].
As I mentioned recently: the first chapter of Strang's Linear Algebra and Its Applications (googlable pdf) is about solving systems of linear equations with previews of the linear algebra to come. Very nice book. For a good more general/theoretical book, Axler's Linear Algebra Done Right[1] is fantastic.
That's it! Enjoy!
[0] https://youtube.com/playlist?list=PLelIK3uylPMGzHBuR3hLMHrYfMqWWsmx5&si=IuahUS2GKPrG3c9c
[1] free pdf: https://linear.axler.net/
Okay, it's time for a toot after a long time of lurking
At the moment I'm learning a bit of Scheme and while reading "Simply Scheme" I've found this passage which explains functional programming
It says that functional programming focuses on the value not the actions like in imperative languages. So basically one doesn't care how the program calculates for example the power of 2 of some integer. I just want to get the value/result of it.
But, somehow the program needs to know how to do a power of 2, right? I mean… the value doesn't appear out of the sudden, right? Does this mean that the language hides those "action" details from me
? Could someone shed some light upon my rumination, please
?
PS: Apologies for this long toot!
Is there any programming language which fully leans into refinement types and flow-sensitive typing, without involving an SMT solver? Niche is fine.
I was writing TypeScript code today like:
```
arr: Array<{ x: number, y: Maybe<string>}>
arr.filter(({ y }) => y.isJust())
.map(({ x, y }) => ({ x, y: y.value }))
```
where `value` only exists when `y.isJust()` returns true.
This sort of thing doesn’t typecheck in TS, and the only way to make it do so is with heavy handed type coercions. TS is smart enough to be able to split a discriminated union based on a conditional, but it’s clunky when doing so based on a method call and impossible when doing so nested inside an object inside an array method.
This feels like the kind of thing a language like Dafny would solve, but I found Dafny really frustrating because I had to make guesses about the internal logic of an opaque SMT solver. I found my brief forays into Coq and Isabelle really fun and rewarding, but Dafny was brutal.
Am I looking for dependent types? I don’t want to pay the cost of proving my programs correct; I want to not have type safety vanish as soon as I want to perform a multi-step algorithm.
#programminglanguages #plt #typescript #dependenttypes #functionalprogamming
Just finished writing a #blog article about my #langdev #functionalprogamming #rust #compiler project. Got too long for a toot-chain, so blog it is.
Will be posted later today on @[email protected] and boosted from this account.
That account is a writefreely instance, where I cannot reply to comments because writefreely does not have that feature... So make sure to reply to the boost on this account 😉