Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

431–440 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#431
post #345
post #262

Earlier quoted context omitted.

That function covers 2⁶⁴ inputs, not cases. It handles only one case: converting an angular value to (half of) a cartesian coordinate.

Sounds like you haven't ever tried to implement it. But if the "case" you're thinking of is the "case" narnarpapadaddy was referring to, that takes us to their clause, "Any fewer [cases], the additional abstraction is unneeded complexity." This is obviously absurd when we're talking about the sin() function. Therefore, that can't possibly have been their intended meaning.

The alternative and more charitable interpretation, of course, is that a single function like sin() is not what said GP meant when using the word "interface". But hey, don't let me interrupt your tilting at straw men, you're doing a great job.

Re: Clean Code vs. A Philosophy Of Software Design

#432
post #149

Crucial context here: Ousterhout is one of the great programmers who built the free software world we live in today, and Uncle Bob is a faker. Ousterhout is not without his problems (Stallman famously called him a "parasite" on the free software community, as well as fervently disagreeing with his technical taste) but he's written truly world-changing software. By contrast, Uncle Bob is a windbag book author who has…

I'ma big Tcl fan, but Ousterhout has created many other important things - see https://en.wikipedia.org/wiki/John_Ousterhout .

Re: Clean Code vs. A Philosophy Of Software Design

#433

Earlier quoted context omitted.

That's an interesting approach, I'd like to see an implementation of what you're talking about. What language are you using that has such an expressive type system? Oh, I agree that there usually isn't a scientific method to programming. I think there could be though. Not for everything of course, some things will always be up to personal taste and interpretation but the cursor could probably be moved with some effor…

Typescript is capable of dependent typing, union types, exhaustive matching and everything needed to achieve this style of programming. It's just not strict. The other language is rust. Though it's type system is not as expressive as typescript it is strict meaning nobody can really cheat their way out of it. In general Rust code requires less unit tests then typescript because of this. The other language is Idris an…

Thanks, I haven't touched Typescript in a while so it might be the occasion for that. When do you feel like you have a handle on the behavior, do you have complex integration tests then?

Re: Clean Code vs. A Philosophy Of Software Design

#434
post #409

> For me, the fundamental goal of software design is to make it easy to understand and modify the system. I use the term "complexity" to refer to things that make it hard to understand and modify a system. This explains everything that's wrong with modern software. When you design a Formula 1 race car engine, the purpose of engine design is not to "make the engine easier to modify". It's to win races. And that depend…

Software is unusual in that it's never finished. This makes ease of modification a critical quality of software in a way that it isn't for Formula 1 race car engines or most buildings. Ease of modification was one of the top priorities in the design of the Model T Ford, because cars break down and must be repaired, and a car that is difficult or impossible to repair will cost its owner large sums of money. Software d…

[deleted]

Re: Clean Code vs. A Philosophy Of Software Design

#435
post #325

Earlier quoted context omitted.

> Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? Not once in my 11 year career. But almost every codebase I've worked on has had debilitating maintainability issues because the only principle other engineers seemed to follow was DRY, at the sacrifice of every principle in SOLID.

Most code that i clean up is a lot easier to maintain after making it a lot DRYer. The point is not about being DRY, on itself, though. The point is that the code then has better abstractions which are easy to reason about. UB seems to take abstractions a lot too far, replacing e.g. 2 lines of very clear code with some cleartotals abstraction.

DRY is about ensuring that the same code doesn't have to change in two places because the engineer changing it in one place might not know that. But so many applications of DRY mindlessly violate the single responsibility principle and create coupling where there shouldn't be.

Re: Clean Code vs. A Philosophy Of Software Design

#436
post #323

Earlier quoted context omitted.

That's definitionally untrue. Shitty code doesn't run or doesn't do what the author thinks it's supposed to do. You can't write genuinely shitty code and be smart. I've seen smart people get caught in trying to write "clever" code. Abusing features of a language to make the code "look" smart. And I've never seen someone I've considered smart write completely unformatted code where it matters. I may not agree with all…

[flagged]

> Then you've never been around the smartest people. Likely you've been around smarter then average people.

This is totally unfalsifiable. I claim that the smartest people around always wear clown shoes to work. If you disagree, it's simply because you haven't met any of the people I'm talking about. QED

Re: Clean Code vs. A Philosophy Of Software Design

#437
Some software gurus really grind my gears, and Robert Martin is one of them. When confronted with bad advice he gave, he's quick to say it's not meant to be taken literally. Then, gurus like Kent Beck, say that you cannot criticize their approaches if you don't implement exactly as they say. So, while this is not exactly a paradox (different people with different opinions), I feel like gurus make their livings on unfalsiable claims while shaping the world of software engineering.

So, some kudos to Robert for accepting criticism and discussing it, but no cigar for downplaying his own advice when confronted - I also recall a different discussion, where someone confronts his statement "you don't practice tdd you're not a professional", and his answer "it was not meant to be taken seriously".

These people had great ideas but they should be more critical of themselves, eg "here's when not to apply this", "here's where to bend this", not "you're doing it wrong" or "don't take it literally".

Re: Clean Code vs. A Philosophy Of Software Design

#438
post #437

Some software gurus really grind my gears, and Robert Martin is one of them. When confronted with bad advice he gave, he's quick to say it's not meant to be taken literally. Then, gurus like Kent Beck, say that you cannot criticize their approaches if you don't implement exactly as they say. So, while this is not exactly a paradox (different people with different opinions), I feel like gurus make their livings on unf…

I don't understand how that works on people. Dog whistling, "Hey, hey, leave me to my grift."

Re: Clean Code vs. A Philosophy Of Software Design

#439
post #239

Lots of negative comments about Uncle Bob in this thread. I personally didn't like Clean Code and really enjoyed A Philosophy of Software Design, but I do think that some of his other books are really solid. I accept that non-fiction books on anything will oversell the value of their way, and try to take what I can at a more moderate level. Through that lens, Clean Code didn't give me much, but Clean Architecture did…

Uncle Bob has been a horrible influence on our industry, and we’re expressing that. He has not actually worked on anything but yet he’s been able to make some money selling his inexperienced opinions.

Re: Clean Code vs. A Philosophy Of Software Design

#440
post #35
post #31

Earlier quoted context omitted.

What's there to dislike so much in APOSD? The book struck me as giving mostly reasonable advice, none is which was overly prescriptive. None of the things I disagreed with struck me as egregious .

Here's mostly from what I wrote down after reading it. Indeed, the "reasonableness" is part of the problem. What's agreeable is mostly only so because it's such a straightforward platitude. "Things that are not important should be hidden, and the more of them the better. But when something is important, it must be exposed." Ok? Anyone want to argue to the contrary? This is not teaching or learning anything new or of…

If you dismiss all the parts of APOSD that you agree with as straightforward and trivial, then obviously the only parts left for consideration are the parts you disagree with. APOSD is not an academic paper, it does not claim to be wholly and truly original. You are presumably an expert programmer, so it makes complete sense that much of the content discussed in APOSD appears to be "straightforward platitudes". To you, the content is trivial and obvious. But to the new grad with one year of work experience, the content is novel and informative. Perhaps you should take your own advice and consider the context.
Post reply on HN