Huge themes of my personal state of software engineerig art:
* (pure) FP in back-end and front-end
* the Onion architecture
* REST
LLMs used to help a knowledgable engineer amplify and accelerate his own work is the way to go. Not the other way around.
borar retweeted
The foldl hackage.haskell.org/package/… package is one of the most remarkable bit of the Haskell ecosystem. Turns out, we can make it better. I mean worse. I mean… maybe? 1/11
borar retweeted
New blog post by @alfredodinapoli announcing Hypha: an experimental Haskell CLI tool for exploring project dependencies, reading documentation and using LLMs without hammering Hackage or Hoogle well-typed.com/blog/2026/10/…
borar retweeted
discourse.haskell.org/t/muta…
Someone is giving a talk about my Mutation testing in Haskell. If you're in Melbourne next month, go enjoy it!
(and someone please record it for me :D)
P=NP "only" means that the classes are equivalent, but the problems still vary wildly in complexity. In particular, it does not mean that an NP problem can literally be computed significantly quickly, because it has huge coefficients compared to another problem in the same class.
A simple example: suppise we "hide" and IO value like this inside of a data structure which is opaque:
data D = D (IO Int)
and we want a function on D do something with the Int. It is impossible for the function to have type
D -> Int.
It must be D -> IO Int.
LLMs are such a great opportunity to do more engineering in software, but it is so easy, tempting and low-effort to move even more away from engineering discipline in software than before.
The caller may not be able to see the representation of a newtype, but the IO type will always pop up in the API for working with it.
Nothing of the above even requires monads. It's just the command pattern extended with the notion of the "result" of the command: the Y in the 'IO Y' type. Monads are about the capability of combining these commands into larger commands in a particular way.
Even if an IO value is hidden in a private field, it cannot be discharged invisibly. Any function which does soemthing with this private field working with the data type it isnpart of will surface the IO type again.
Closer to your example, the function type would be X -> IO Y. That is, given an X, we can obtain an IO value. This does not perform any I/O, i.e. the function is pure. It has to be "run" separately which will do I/O and then yield an Y.
In Haskell it is wctually like this, but... simpler. A value of type 'IO Y' means 'Y' is computed possibly involving I/O but we don't know what exactly happens. There is also no way of getting Y out without performing the required I/O steps, if any are required.
