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.
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."
> "yeah I have a User, but I don't know if it's a valid User".
This, imo, is one of the big reasons people so easily dismiss OOP. They put whatever data _they think they probably need_ in an object using setters/builders/what have you. This leads to abstractions of data that don't accurately reflect state. They will then let an external entity (service or whatever pattern) manipulate this data. At this point people might as well use something analogous to a C struct where anything can be done to the values. Objects are not managing their own invariants. When you rip this responsibility from an object, then nothing becomes responsible for the validity of an object. Due to this, people wonder why they get bugs and have trouble growing their software.
This also leads to things like "isValid". People don't understand that an object should be constructed with only valid data. The best example I've found of protecting variants and construction of valid objects to be this strategy in F#:
I've wanted to spend time on Pharo for over a year now but the blurriness gives me a headache. Occassionally I'll check back during a new release to see if they fixed the hidpi issue. Really surprised they haven't.
This is the one thing I found that prevented me from getting far with Clojure. I love the language and the concepts...but there's no stable well-documented go to tool that I can use to hit the ground running. Instead, I spent so much time looking at blog posts and random videos trying to cobble together some sort of system of various libraries to form the basic functionality of a web framework just to get to a point where I could actually start working on the meat of the application. Luminus is extremely helpful but I'd also end up having to learn about the individual pieces and found it hard to add libraries after I started my project.
The pervasive "compostable library" mindset also completely ignores the other benefits of having a standardized framework such as Rails that people can rally around:
1. Standardized documentation
2. Being able to create community that can provide support when you're having issues
3. Easily google-able solutions to common issues
4. A standard that can be iterated upon. I feel like Clojure libraries do this somewhat already so they can work with each other so what's the harm on standardizing these interfaces?
Would you mind iterating on how it could be improved and how these changes relate to the context in which you've worked?
I've used it a bit for simple game development(Love2D). It's an okay language but it seems only suitable for building anything beyond small systems. No good IDE support and needing to emulate OOP was a bit annoying to me.