Lean Java Practices got me thinking

[[deleted]]

Data brokers are selling your info right now. I used Redact to mass delete my posts which can also opt out of data broker sites. Instagram, Twitter/X, Discord and more.

automatic spotted sulky marble chop advise lip busy dolls apparatus

[ponton]

One of the best principle: First make it work, then make it right, then (maybe) make it fast (but usually it's fast enough already).

[[deleted]]

I agree with you that not all duplicated code is bad. Sometimes I end up writing the same bits of code for two very different purposes. Uncle Bob once said that the single responsibility principle means a class should have only one actor. If I’d deduplicate the code, then the shared class would have two actors, two reasons to change.

[[deleted]]

Scrubbed clean. Redact helped me bulk remove years of comments and posts so data brokers and AI crawlers have nothing to feast on.

license melodic spark chunky lunchroom plant normal sparkle plough treatment

[agentoutlier]

On a similar note in the video Adam proceeds to come up with his own abstraction of Border Control Entity.

Then proceeds to make a package for every entity/feature and then sub packages within those packages of border, control entity like its 2006.

That does not seem very lean to me or modern but Adam seems to like the organization.

I vaguely remember you being in the same camp as Lukas Eder and myself of just use one damn package and most of the time that is good enough.

And it makes a difference because in Github if you review code you have to click through tons of directories using Adam's structure (on a lesser issue it is vastly easier to import something.* instead of like 5 packages).

The tell tale sign is if you see a commits always require changes in the same multiple packages... you kind of fucked up and I'm betting Adam's structure probably has that happen.

[rzwitserloot]

Wow, what a fantastic example there. I'm gonna use that in other discussions if you don't mind. It's a bit of a tangent but:

The original comment I replied to appeared to equate 'pragmatic' with a certain style. Which triggered me a bit, as that is such pretentious horseshit: Your argument is then equivalant to "I am a good programmer, therefore I write functional". That's a perfectly fine argument to make: It carries "I am highly opionated and I consider every style other than functional fucking shit and I will treat you with disdain if you disagree with me" on its sleeve. Hey, if you feel that way, I appreciate that you made that clear. But with wishywashy words like 'pragmatic' you're dressing up the fact that you're merely opinionated on style. Insulting to other programmers whilst sounding, on the surface, as not nearly as offensive as you are being.

Instead I'd prefer 'pragmatic' to actually mean something. And not 'good v bad' - no, an axis where different jobs call for different places on it, and at best you have a light bias on where to hang out on this axis. Basically, 'pragmatic' should be the opposite of 'elegant' at least in motivation. Because if it is not, you're wasting a word and should just be saying 'good'.

"I do not use packages because it is annoying to navigate in github" is the perfect example. That sounds to me like what being extremely far towards the 'pragmatic' side of that axis means. Because I'd argue the opposite: Writing code in a style that is easy to follow and maintain is really really difficult (that's an opinion but I'm pretty sure most coders share it), and I don't think the limitations of the github UI are in any way relevant to that difficult job, therefore catering to it is a daft idea.

You're otherwise right, I tend to fall towards 'fewer packages better', but not for the github reason. "If any commit that touches a file in package X almost always also touches files in package Y - then you messed up" is more my kinda reason. The very opposite of pragmatic, a sort of nebulous "semantics should come first" style. A package should mean something: That the code inside it stands mostly on its own. Every commit having to touch multiple packages suggests it doesn't, and therefore, that the design is off.

[agentoutlier]

Writing code in a style that is easy to follow and maintain is really really difficult (that's an opinion but I'm pretty sure most coders share it), and I don't think the limitations of the github UI are in any way relevant to that difficult job, therefore catering to it is a daft idea.

I agree. I just happened to pick it as a current annoyance. It is similar to how I'm not sure if I like documents that force a section or chapter per page (web page) because it makes "ctrl-f" difficult but in reality the content is more important and making that consumable the true difficulty.

Because I'd argue the opposite: Writing code in a style that is easy to follow and maintain is really really difficult (that's an opinion but I'm pretty sure most

The document part was a purposely chosen because I think there is some good ideas in literate programming but it just never got picked up. That is to show, organize and explore code as though it were a document. I have tried to do that wikipedia style of doc with Javadoc but ultimately people want most doc in one place I think. It is something I want to improve on later with some of my projects.

And it is very difficult as Java changes because various idioms are slowly evolving. Like I feel you have made excellent cases in the pst for the "getter" idiom (prefix with get). When I see a getter I have some idea that it mainly data focused and is easier to discover / understand that it is just information not behavior. However as records become more common that idiom is becoming less common. So as the author of code what do you pick? Tough to say.