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.
> 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.
Java was the first popular language to push static analysis for correctness. It was the "if it compiles, it runs" language of its day, what meant that managers could hire a couple of bad developers by mistake and it wouldn't destroy the entire team's productivity.
I'm not sure that position lasted for even 5 years. But it had a very unique and relevant value proposition at the time.
OCaml would like to have a word with you. In 2005 it already had better static analysis and correctness on object oriented stuff than what Java struggles to approach today.
OCaml is also from 1996. And I say 2005 because that's when I started using it, not when it started being useful.
By that time it supported parametric generics, multiple inheritance, named parameters, optionals instead of nulls everywhere, compile to machine code and quite a few extra things that I couldn't understand at the time.
A lot of that is down to how people rely on frameworks that force them into "convenient" abstractions. Like Spring and Hibernate. But those are not the language. They represent a (vocal) subset of programmers.
You don't need an ORM or an overgrown dependency injection framework to create a webapp in Java.
Service classes are the thing I hate most. They’re just namespaces for functions. They’re a product of Java not being able to have top level functions.
Not everything can be associated to a single entity. Many operations work on two or more entities where none of them are the "master". Otherwise you end up with "coordinators".
Users.create(...) is the easy case. Try transfer_permissions(user1, user2, entity) while retaining transactionality and the ability of either user to cancel the transfer.
I'm not sure why having a global function by the same would make this any easier or harder to implement. But it would pollute the global namespace with highly specific operations.
It doesn't have to be a class. It can be an interface. And regardless of what it is, it has to go somewhere. Whether it's in assorted_functions.c or Permissions.java makes little difference.
I mean it makes sense to group "like" things together. Whether that's in a module, a class, an interface, or a namespace. Having a huge number of things globally is just confusing pollution.
Yes, but going as a static method into a class that goes into a module is overkill vs just putting it in the module.
> Having a huge number of things globally is just confusing pollution.
I don't know what language you use, but modern programming languages allow specifying what to import when importing a module. You don't have to import everything from every module.
OO conflates many different aspects that are often orthogonal but have been conflated together opportunistically rather than by sound rigor. Clearly most languages allow for functions outside classes. It's clearly the case today especially with FP gaining momentum, but it's also clear back then when Java and the JVM were created. I think smalltalk was the only other language that had this limitation.
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.
Honestly one of the best books I've read about programming. It's inspired me to try the language out just for fun things, think I'm going to use it for Advent of Code this year. I think it does benefit from being interoperable with C# so you can use it where it makes sense and still have C# to fall back on. Kind of like Scala/Kotlin with Java.
Java is a waste of time for the reasons you said. People use it for legacy reasons. Back then, the alternatives like JS just weren't there yet in several spaces like backend. Your alternatives were even more cumbersome like C++.
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."
You want cuis smalltalk. It's a heavily-simplified smalltalk (like pharo, it was also forked from squeak), with a redesigned morphic system - which is ENTIRELY vector graphics based (plus a few other niceties).
Yes, even the fonts themselves are vector graphics. You can use a fancy cursive font, rotate a text window, and then zoom it in or out - with total clarity.
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.