ejflick

I read that book earlier this year. It made me rethink how we approach problem solving in team environments. I now aspire for code I write to be able to be played with as a child would play with a turtle. I find this lack of being able to play is what makes it hard for software developers to really understand each other’s work.

There’s also a section in that book that briefly talks about agentic modeling in the same way people use LLM’s today. I find it fascinating that this idea was already that old at that time.

I can’t decide if it’s obnoxious or beautiful irony that drives home the idea of the article.

Articles from this site pop up occasionally. Something about the background color causes me to see a medium-sized bright spot in my vision after a few minutes. Due to this, I have to remind myself not to click when I see the URL.

Was just looking at this article yesterday and it inspired me to try it myself. Trying it out today, my fingers became really sore from trying to navigate. Can't imagine using this for a modern development workflow where there's a lot of jumping around. To make it more ergonomic, I'd just be recreating configuration other window managers give me out of the box.

The author mentions in the footnotes he mostly uses this setup for note taking. That makes sense as he probably remains in one window for extended periods of time.

I've read his book "Domain Modeling Made Functional" without much prior knowledge of F#. He provides some compelling examples and some of it ended up inspiring how I write OO code. F# seems cool but it felt like it was close to being extinct.

> Basically your objects are data-only, so there's no benefit.

This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either:

1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers".

- or -

2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc.

The more I work in Java, the more I feel friction between the language, its identity(OO beginning to incorporate functional ideas), and how people write in it.

It is unfortunate that this field underestimates the importance of the "people" part in favor of the "computer" part. There's definitely a balance to be stricken. I do believe that languages that are designed for computers have done a pretty decent job at adapting features that are geared more towards the "people" part of the equation. Unfortunately, programmers are very tribal and are very eager to toss the wine out with the cork when it comes to ideas that may help but they've misapplied.

> APIs should not present nested objects but normalised data

If something is nested, let it be represented as a nested structure. I find flattening causes more mental overhead. If something is too flat, it becomes less obvious what data is exactly necessary to do what you want to do

> OOP is an industry of its own which generates a ton of incidental complexity.

Code in any form can generate a ton of incidental complexity. The issue isn't the tool rather than the education to properly wield those tools. Especially when you introduce the team dynamic where everyone has varying understandings of what is being built and how it should be built.

> 2. Separation of concerns is a myth

I don't fully understand the quote from Djikstra where he first talked about this but I'm sure he didn't mean it as it's interpreted today: "draw invisible boundaries in random places because best practices."

> View code in the back-end always looks like crap

That's probably the fault of the people writing it. People can also write crap looking code using frameworks too.

> and never able to achieve the interactivity the front-end can.

That's what small sprinkles of javascript is for. You don't need incredibly beautiful interactivity in every pixel.

I check every release hoping that they finally fixed rendering for HiDPI. Guess I'll have to keep waiting.