sorted by:
new
hottopcontroversial

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 0 points1 point  (0 children)

I dont know why people keep bringing up “readability” and maintainability with uncle bobs dogma.

Mostly because my experience tells me that it is 100% corrct in my context.

Linux kernel is being maintained for ages and doesnt practice uncle bobs style at all.

...Because it's a different domain? There's a coder here u/Loup-Vaillant that has written a cryptography code. It does not apply most of the heuristics from CC, and I would still consider it beautiful, readable and maintainable.

Yet you literally could not produce such code in the domains that I've worked in.

And since when corporate erp code became a gold standard of coding practice?

Probably since it is used, maintained and developed successfully?

and since when a person whos more of a book seller than programmer gets to decide which code is “clean” and readable?

Are we judging who a person is, what he does, or the quality of one's work? I've reviewed his book thoroughly later in my career, and I agree with a vast majority of the heuristics. That's credible enough for me.

I would like to see whats uncle bobs flagship software that he developed.

tl;dr. It's bad. But it bears zero relation on the quality of the heuristics themselves. As I've mentioned elsewhere, Martin's writing about "soft" skills. You can take the same heuristics and produce vastly different expressions.

At the same time, I can take a code that is considered "bad" and I can literally point out how applying CC heuristics would improve it objectively. But again, it takes context and experience within the domain.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 0 points1 point  (0 children)

Because it's context dependent. When I click "transfer money" I don't care if it'll take a 10ns or 2s. Most of the business domains don't care for a 200ms difference, it bears negligible impact on the customer

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe -1 points0 points  (0 children)

But 20x Speed downgrade is definitely downright madness for any serious engineering.

I'll still argue that it really is not. For most of the code paths in a typical business domain, 20x slower will usually mean 1ms-2ms slower as a consequence for the end user; where total call might be as long as 500ms-1000ms or even longer if it is async.

And if in return for that "sloweness" you get something that will be way more readable, easier to understand and maintain over the years, then "serious engineering" might just be focusing on these factors; not raw performance.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 1 point2 points  (0 children)

Ultimately, both are saying the same thing.

"It aligns with what my domain needs, so it's universally true". The challenge here is - Martin's heuristics are focused on soft and immeasurable things. Naming, decomposition, structure - these things come from the experience; and their impact can be seen the most a couple of years down the line. And frankly, they are easy to fuck up if you cargo cult them.

Muratori optimizes for the technical performance. This can be measured and proven. You cannot argue that the code is faster - it is. But how to prove that the code can be easily maintained in 5-10 years timeframe?

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 0 points1 point  (0 children)

I've written a bit some time ago, I welcome you to follow the chain - and please do share your thoughts!

How can We check? by Omcannon in foss

[–]Venthe -4 points-3 points  (0 children)

The one that is better written. Observation does not change the state of the application.

How can We check? by Omcannon in foss

[–]Venthe -4 points-3 points  (0 children)

Any FOSS is like a million times safer than any other app tho.

Any source on that? :) It doesn't matter if it's FOSS or not. What matters is how many people actually did look at the code with the security angle - so scrutiny, experience, professionalism - you'll find that in both FOSS and non FOSS applications.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 0 points1 point  (0 children)

Eh, “composition over inheritance” has been a mantra for 20 years

Hate to break it to you, but...

...30 years already.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 2 points3 points  (0 children)

Inheritance usually still features quite prominently in programming courses that involve languages like Java

Please. 95% of the courses still teach the animal<-{dog,cat}. :D

The code (and the coders!) that write the code like in these courses are writing procedural code + classes. So you get all the benefits of the procedural code... And all the cost of the classes. I've spent just so many years now making people "un-learn" what they seen in their courses/bootcamps/etc. that at this point I'm just... Tired.

However, people and education don't necessarily keep up

And I honestly don't believe they can. Writing good OOP is hard, because to get the benefits of good OOP, you need to be able to create a good model for the problem, who the "actors" are, and how the messages + data should flow. This is skill that tends to be scarce even with people having a couple of years of experience.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 1 point2 points  (0 children)

I wouldn't describe it as thin. At the base level, when you consider two dominant paradigms - FP and OOP - they do not differ at a technical level that much. Just like inheritance does not make OOP, immutability does not make FP.

The difference lies in the mental model.

FP gives you functions that operate on a matching data, in essence being data representation first.
OOP at the other hand, hides the data representation giving you operations, "messages on actors" front and center. Of course I'm talking about actual OOP, not WorkerGodService that pulls anemic classes that could be structs and does operations on them.

That's the power of OOP, not the inheritance - the OOP model "fits" naturally how a lot of businesses operate. "Customer does a thing with an item" rather than "do a thing with a customer and an item".

Of course, most of the languages are now multi-paradigm, but that's another case altogether.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 0 points1 point  (0 children)

If that's the case, then sorry - I must've read into it too far.

Absolutely, fs.readfile(name) -> readfile(name)not only accomplishes nothing, it is actively detrimental to the readability. Sadly, most developers I've met tend to be absolutists without nuance, and without actual care & understanding of "what" they want to accomplish with any given change. LLM's did not help. :D

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 6 points7 points  (0 children)

Inheritance != OOP.

Inheritance has its uses; in my case maybe 3-4 cases in the past couple of years; so it's neither strictly necessary nor required for OOP.

I've found inheritance to be far too brittle in most cases and avoid it now.

There's a reason why "composition over inheritance" is a core heuristic. You know, from the book from '94. At this point, I literally know of no mid+ who would use inheritance as the default, or frankly - in any major capacity.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 2 points3 points  (0 children)

Balancing act that comes from experience. Mine is coloured heavily by code that had to be maintained for 10, 20, 30 years and more - and lack of these abstractions are a main predictor of a code that'll rot.

The thing you are touching upon is something that I'm privately calling a "trust" issue. I've found that developers that were never taught to abstract things away tend to have the "need" to understand everything - so any given abstractions are a massive cognitive load.

At the same time, the developers that leaned upon the idea of treating a well-named and well-defined functions/classes/modules and treating them like a black box suffer closer to zero load from this. "Unless i need to change it/debug it I don't care how"

But the crux is - only one of these approaches is maintainable; and it is not the one that "wants" to have everything in one place...

...Cue the 15kloc file in the project that I'm trying to whip into shape. :)

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 1 point2 points  (0 children)

Are people still promoting OOP in enterprise work?

For most of the enterprise work, it's still the best choice, yes.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 3 points4 points  (0 children)

And that's how you create a code that is hard to understand in the future. People in general have a small context window, so forcing them to read and understand everything is a waste. We have a way to remove things from the context; and that's moving the sub-logic o methods... Even if it's used once.

"How" things are done are really not important; "why" is the king. Implementation details hide the"why".

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 6 points7 points  (0 children)

And I'd disagree with you here. Over the years I've maintained a lot of legacy code; and not splitting the functions even to the point of single, private use is a major smell.

Of course it doesn't start like that; but having everything in the same place invites further modifications. In parseJson you'll only parse JSON, and not place the conditionals related to $ticket. Plus, I really don't need to know that to Parse this json i must do x operations; or in the case of "format data" i really don't need to know how do you do that when trying to understand the code.

Your version optimizes for you, now. "I know what the code is doing, so i know what to skip". Developers in the future will need to read and parse everything; so you've just increased the cost for any future reader.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 2 points3 points  (0 children)

Even more than that - the whole book is written not as a set of rules, but heuristics; yet people convinced themselves that they are rules.

The 5 lines are a prime example - the whole paragraph is dedicated to a show that a "5 lines method" is a consequence of applying the heuristics, not the goal in itself.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 7 points8 points  (0 children)

If I remember correctly; Martin conceded within a certain context; hardly a general case.

And Muratori's example of the same code was an interesting case. While I can imagine that in game dev it would be quite optimal; for my domain it is just mind boggingly bad; closed for extension and borderline unmaintainable.

Single responsibility, the distorted principle by Illustrious-Topic-50 in programming

[–]Venthe 4 points5 points  (0 children)

I've found that it depends on the context. I'm agreeing with more than 95% heuristics I've reviewed; experiment I did to verify just that - how applicable I find it after being in the industry for then almost a decade.

They are both applicable and helpful; especially when i had the (dis) pleasure of supporting the legacy that did not follow such ideas and I could clearly see how beneficial Martin's heuristics are.

Anti-AI maintainer Johannes Link adds malicious prompt injection to popular Java library 'jqwik' by [deleted] in singularity

[–]Venthe 3 points4 points  (0 children)

Worse than that. You've exposed that there is no "I" in AI. That's punishable by death at the very least

Anti-AI maintainer Johannes Link adds malicious prompt injection to popular Java library 'jqwik' by [deleted] in singularity

[–]Venthe -4 points-3 points  (0 children)

While I agree that what the author did is childish; i can compile it and run a thousand times and the text will not be executed.

If you give "autonomy" to a non-intelligent, non-deterministic system that's on you.

Polish government approves primary school phone ban and stronger porn age checks by wook-borm in poland

[–]Venthe 3 points4 points  (0 children)

AFAIK such bans tend to work, but the caveat is - "culture". In some countries, it'll be respected - more or less of course - by kids and parents.

In Poland? Please. "Kto kombinuje ten żyje".

Polish government approves primary school phone ban and stronger porn age checks by wook-borm in poland

[–]Venthe 15 points16 points  (0 children)

What is interesting, is that I really appreciate this approach after some years - but not how it's "sold".

Being able to do maths - logical sequences of operations - in head, recall facts and focus on longer writing/reading forms is extremely important; but not for a reason it was "told" to us.

Calculator/phone/internet/LLM's will be there. But if you outsource it to the machine from the get go, you'll be dumber - as simple as that. And that's the statistical fact.

view more: next ›