Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

Post reply on HN
Print view View original

471–480 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#471

Post by lmm »

MrJohz wrote: post #176
lmm wrote: post #128

Earlier quoted context omitted.

Yes, I've worked on a couple of codebases like that. It's glorious, you break everything down little by little and every step makes sense and can be tested individually. Best jobs I've had.

But are those steps actually doing anything that can be tested? My experience with these sorts of codebases was always that most of the functions aren't doing much other than calling other functions, and therefore testing those functions ends up either with testing exactly the same behaviour in several places, or mocking so heavily as to make the test pointless. Or worse, I've seen people break functions apart in suc…

> testing exactly the same behaviour in several places

I think that's actually fine. Particularly if you're doing a testing pyramid style approach where you do a lot of tests of some piece of low level logic and then a few tests of the higher level piece that makes use of that lower level logic, I don't see any problem with the higher level test covering a codepath that's also used in the lower level test. If anything I find it makes it easier to understand and debug failures - you know that the behaviour of the lower level piece hasn't changed because otherwise the lower level test would have failed, so the bug can only be in the higher level component itself.

Re: Clean Code vs. A Philosophy Of Software Design

#472

Post by kridsdale3 »

arcanemachiner wrote: post #304
brianmcc wrote: post #300

Earlier quoted context omitted.

>> ... TDD is unlikely to help you solve problems that are beyond incremental changes. Thank you for expressing this niggling problem with TDD. Personally I just cannot use it for "new stuff", I need to explore and create direct with "real" code for anything non-obvious.

I'm more of a DTT man myself: Develop, Then Test.

I've had a long and thriving career with the DSTYBYTD process.

Develop, Ship, Tell your boss you tested and documented.

Re: Clean Code vs. A Philosophy Of Software Design

#473

Post by kridsdale3 »

soulofmischief wrote: post #450
cluckindan wrote: post #447

Earlier quoted context omitted.

Invest in the Vision Pro. It will change your life.

I was also looking at the XREAL Air 2 Ultra, seems more practical for travel, but the idea of an ultrawide screen sounds really nice. I might take your advice.

There's no comparison in terms of text rendering resolution. Vision Pro is the only set on the market today that is close to 20:20 vision.

Re: Clean Code vs. A Philosophy Of Software Design

#474

Post by Jach »

WillAdams wrote: post #184
Jach wrote: post #35

Earlier quoted context omitted.

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…

What definition of complexity in the context of discussing software development and architecture would you put forward instead?

Complexity: things twisted together.

You can count the things, and count the twists. When a set of things has fewer twists (or even knots) than another set of things, it's simpler. When you pull on something, if it's attached to other things by twists, you are dealing with complexity. When you intentionally entwine things, you are creating complexity. You might say you are "complecting" things together, and once done they are "complected" together.

This is relevant from the smallest details of programming like state (being a more complex twist of value and time, compared to simpler immutable values that are timeless) to the largest issues of modularity (being a property of systems composed of smaller things; when you can disconnect such things without needing to untwist them from each other, you have achieved a simpler design).

This is separate from being easy or hard, though one could assert that a simpler system will tend to be easier to change, because you don't necessarily have to deal with as many things twisted together at the same time. But this isn't a given, because we programmers learn and get better at complex things such that they can feel quite easy, and we also love making tools to try and wrangle sources of complexity, either those inherent to a problem domain, or those we unnecessarily inflict on ourselves, and it can be quite easy to make changes to really complex systems once you've learned some of these tools. Complex things can also be very helpful from time to time, especially when they claim to solve a problem and you just want the problem solved yesterday without caring so much how. But regardless, whether something is simple or complex is a property that remains the same no matter who looks at it. Under APOSD's definition, something basic like immutable collections in a program would make it harder to understand because most people aren't taught about them as part of basic education, and many languages don't offer them as part of the standard library. They're unfamiliar, essentially. Even when you do get used to them, they can still be a bit difficult to work with depending on what you're trying to do. But are immutable collections more complex than mutable ones? No.

Recommended watching: https://www.youtube.com/watch?v=SxdOUGdseq4

Re: Clean Code vs. A Philosophy Of Software Design

#475

Post by kragen »

cmacleod4 wrote: post #432
kragen wrote: 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 .

I don't think Magic and Raft are anywhere close to the importance of Tcl, though I've probably at some point used a chip that was designed in Magic. And, while I like Tk and find it inspiring, the number of Tk apps I can remember ever using (that I didn't write myself) is maybe three, and they weren't very important to me.

As for Sprite-LFS, I really enjoyed the Sprite LFS paper and found it inspiring, but my conclusion was that Seltzer's followup BSD-LFS paper falsified some of its more surprising claims, and ultimately the underlying predictions about the relative trends in RAM size and disk size turned out to be wrong, undercutting the key advantages of the LFS approach overall. Vaguely LFS-like approaches are important to SSDs and SMR disks, but WAFL was already about that LFS-like in 01995 (which is admittedly after Sprite-LFS), and SSD FTLs also do some not-very-LFS-like things. So ultimately I don't think Sprite-LFS turned out to be that important.

Sprite as a whole I'm less able to evaluate. I've never been an OS researcher, but I've spent a fraction of my life reading SOSP and HotOS papers and systems dissertations, and I don't remember seeing anything that came out of Sprite except Sprite-LFS. I was thinking maybe doors in Solaris did, but no, that was Sun's Spring, not Sprite. Other side of the Bay, where Ousterhout took Tcl eventually. So it's possible Sprite was a great achievement, but I haven't noticed it. But I think more likely it's one of those things where we tried the "obvious" thing (SSI across a bunch of workstations) and found out why it was bad, which influenced later efforts like PVM, MOSIX, Beowulf, distcc, MapReduce, Ceph, etc., because Sprite stepped on the mines so they didn't have to. There's a nice retrospective (by Ousterhout, natch) at https://web.archive.org/web/20150225073211/http://www.eecs.b....

So I don't think Tk, Magic, Raft, and Sprite-LFS really have the same level of significance as Tcl. Sprite maybe.

I don't think it's bad to spend a lot of time and effort on things that turn out to not be very significant, for two reasons. One is that, after a long enough time, very little indeed remains very significant. (Who, today, can recount the disappointments of the Minoan queens?) The other is that things you could do that are significant—even for a little while—are usually things that will probably fail. So if you spend a lot of time doing things that might be significant, you'll fail at most of them.

But in Ousterhout's case, one of those things did succeed brilliantly, and it was Tcl.

Re: Clean Code vs. A Philosophy Of Software Design

#476

Post by wglb »

igouy wrote: post #359
wglb wrote: post #341

Earlier quoted context omitted.

It is a bit weird. However, a friend of mine was a professional Smalltalk programmer. He claims that his median line count of methods, over his 17 year career, was 4. It is harder to do in other languages--it seems that C would be on the order of 10. Clearly it is a rule that can lead to complexity of too many methods, compromising whatever gain smaller methods give you.

> median line count of methods Auto-generate getters and setters for every instance variable and that will drag the average down. (Maybe a lot of those getters and setters should not have existed.)

Not part of smalltalk.

Re: Clean Code vs. A Philosophy Of Software Design

#477

Post by valenterry »

Kerrick wrote: post #353
valenterry wrote: post #265

Earlier quoted context omitted.

> So, imagine the sentence "the customer canceled the order." > - Customer is the subject noun And this is wrong. Because the customer did not cancel the order. The customer actually asked for the order to be canceled. And the order was then canceled by "the system". Whatever that system is. And that is the reason why it is not expressed as customer.cancel(order) but rather system.cancel(order, reason = "customer ask…

> The customer actually asked for the order to be canceled. This is why many object-oriented programmers prefer to talk about message passing instead of method calling. It is indeed about asking for the order to be canceled, and the order can decide whether to fulfill that request.

> the order can decide whether to fulfill that request.

In my world of thinking, orders don't make decisions. If I go to the business team and say "the order decided to" they'll look at me funny. And for good reasons.

Re: Clean Code vs. A Philosophy Of Software Design

#478

Post by overgard »

nvlled wrote: post #86
overgard wrote: post #67

Bob's comments on... commenting.. are so bizarre that I can't help but think that he just refuses to concede the point rather than admit he might have been wrong about it. Like, the paranoia around incorrect/stale comments is fairly absurd, I've been coding for 20 years across many code bases, and I can't even recall a time when I've been significantly mislead by a comment which caused a significant waste of time. Ho…

> I'm not unfairly clipping context away from it Yes you are, you didn't attach the surrounding code where this comment was found. That comment would make a lot of more sense even just with the function name.

If you need the code to understand the comment, the comment is a failure. I guess what I meant is there wasn't any additional meat to the _comment_, you had to read the code to know what the comment even meant

Re: Clean Code vs. A Philosophy Of Software Design

#479

Post by ebcode »

crabbone wrote: post #278
ilitirit wrote: post #145

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

Professionals in other industries don't "just" write books. In a sense that usually the field has several acclaimed authors and they put some solid work into ensuring their books make sense. While there are disagreements in other fields, or some nonsense conventions, the conventional wisdom is usually at least good enough to make you a good professional. In programming it's the Wild West. Many claims are made based o…

> It's very rare to see any kind of sensible research when it comes to the science part of CS.

Have you discovered the work of Victor Basili?

Post reply on HN