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

Mastering Programming (2016)

tidyfirst.substack.com

Post reply on HN
Print view View original

111–120 of 123 posts

Re: Mastering Programming (2016)

#111

Post by PH95VuimJjqBqy »

randomdata wrote: post #109
PH95VuimJjqBqy wrote: post #108

Earlier quoted context omitted.

"you aint gonna need it" can be clarified as "you aint gonna need all those extension points". it can also mean you don't need functionality you're not using, including implementations for those extension points.

While I accept your definition, because, hey, programmer's can't agree on definitions at the best of times, that is not the definition that was used earlier. And is not the definition presented by the XP gang. John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't inv…

oh yeah, you're right, what the XP guys meant was "spend all your time building the architecture with all kinds of extension points just don't implement them... YAGNI!".

It's a mis-interpretation and it's not a reasonable one either.

Re: Mastering Programming (2016)

#112

Post by randomdata »

PH95VuimJjqBqy wrote: post #111
randomdata wrote: post #109

Earlier quoted context omitted.

While I accept your definition, because, hey, programmer's can't agree on definitions at the best of times, that is not the definition that was used earlier. And is not the definition presented by the XP gang. John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't inv…

oh yeah, you're right, what the XP guys meant was "spend all your time building the architecture with all kinds of extension points just don't implement them... YAGNI!". It's a mis-interpretation and it's not a reasonable one either.

Pretty much. Central to the YAGNI message is ensuring that your design brings test coverage to help you build the things you need when you need it. Kent Beck is credited with having invented TDD, so of course that's at the heart of their theorem.

You need those extension points to keep your tests sane. They come naturally as part of the testing process.

Re: Mastering Programming (2016)

#113

Post by PH95VuimJjqBqy »

randomdata wrote: post #112
PH95VuimJjqBqy wrote: post #111

Earlier quoted context omitted.

oh yeah, you're right, what the XP guys meant was "spend all your time building the architecture with all kinds of extension points just don't implement them... YAGNI!". It's a mis-interpretation and it's not a reasonable one either.

Pretty much. Central to the YAGNI message is ensuring that your design brings test coverage to help you build the things you need when you need it. Kent Beck is credited with having invented TDD, so of course that's at the heart of their theorem. You need those extension points to keep your tests sane. They come naturally as part of the testing process.

https://dhh.dk/2014/test-induced-design-damage.html

Re: Mastering Programming (2016)

#114

Post by beryilma »

bsder wrote: post #54

Your regular reminder that Kent Beck was part of the Extreme Programming brain trust behind the massive failure that was the Chrysler Comprehensive Compensation System: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Programming advice from him and his cohorts (Ron Jeffries and Martin Fowler) should be regarded with several large grains of salt.

I was about to post using the same words "grains of salt". Any programming advice from Agile and XP gurus should be basically ignored.

Re: Mastering Programming (2016)

#115

Post by petersellers »

bdcravens wrote: post #110
petersellers wrote: post #82

Earlier quoted context omitted.

How is that an appeal to authority?

Why submit it like that, but to indicate to readers why this article is worth reading? HN guidelines say to submit the title as is, without additional qualifiers or commentary. (Fortunately, the mods updated it)

I can't speak for the person who posted it. Seems like it could have been an honest mistake to me.

An "appeal to authority" means something more specific (e.g. the logical fallacy "argument from authority") and this is not happening here.

The whole point I'm trying to make is that we should evaluate the writing based on its content. The person I originally responded to was dismissing it solely because of the person who wrote it (which ironically an ad hominem is a fallacy very similar to an appeal to authority but for the opposite reason).

Re: Mastering Programming (2016)

#116

Post by randomdata »

PH95VuimJjqBqy wrote: post #113
randomdata wrote: post #112

Earlier quoted context omitted.

Pretty much. Central to the YAGNI message is ensuring that your design brings test coverage to help you build the things you need when you need it. Kent Beck is credited with having invented TDD, so of course that's at the heart of their theorem. You need those extension points to keep your tests sane. They come naturally as part of the testing process.

https://dhh.dk/2014/test-induced-design-damage.html

It's always strange when someone on a discussion forum defers to someone else for their thoughts. Why even bother?

It's even stranger when the deferral isn't even relevant.

Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH.

Beck's insight with TDD, over the testing that came before it, was really just that if you write the test first then you have certainty that the test fails. If you are writing tests for code that you have already written, there is no way to know if your test passes because your code is conformant or because there is a bug in your test.

But, whether your write your tests first or last, you do need extension points to keep your tests sane. Rails is no exception. In fact, I would argue Rails' success was directly related to it leaning into testing and it showing developers what extension points are most relevant for web applications as a result. Before Rails came along, throwing MySQL calls haphazardly into the middle of the HTML was the norm.

Re: Mastering Programming (2016)

#117

Post by GuestHNUser »

dharmon wrote: post #45
_hao wrote: post #29

Earlier quoted context omitted.

I think Martin has a lot more to answer for as far as the sorry state of software today goes. Watching his discussion with Casey Muratori on GitHub last year was great. Not many people saw it, but boy does he compare poorly to a truly capable and knowledgeable programmer - https://github.com/unclebob/cmuratori-discussion

I generally have a negative opinion of Martin, but did we read the same discussion? Martin was very gracious in letting many points slide (points where he was correct!), and was generously willing to end the conversation at a sort-of draw when it was clear that Muratori was not really prepared to discuss things at a detailed level (It was obvious to me from the start that Muratori thought "dynamic polymorphism" just…

> It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance

Inheritance hierarchies aren't exclusively what he meant though. Interfaces and the whole 'prefer composition over inheritance' style of programming has the same fundamental problem Muratori is getting at: both inherently constrain a program's structure for, what he argues (and I agree with), has no benefit to the program's performance or the programmer's time. In fact, he argues that the constraints imposed by the use of inheritance/interfaces only slow programmers down.

His raw device driver example, in pt2 of their conversation, illustrates the advantage of procedural code over inheritance/interfaces. His API requires users to provide a function pointer that will be called whenever an event is raised. This API user is expected to switch over the enum values that they care to implement. This design is better than an interface that requires its members to implement read(), and write() functions because it is both more performant (no vtable overhead + compilers can make more aggressive optimizations) and more flexible (a new event can be added to the enum without requiring all the old code to be updated if they don't need to handle the new event type).

Re: Mastering Programming (2016)

#118

Post by PH95VuimJjqBqy »

randomdata wrote: post #116
PH95VuimJjqBqy wrote: post #113

Earlier quoted context omitted.

https://dhh.dk/2014/test-induced-design-damage.html

It's always strange when someone on a discussion forum defers to someone else for their thoughts. Why even bother? It's even stranger when the deferral isn't even relevant. Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH. Beck's insight with TDD, ove…

this is all just a defensive mechanism to try and dismiss the point.

What's going to happen is that over time you'll eventually have the experience to understand what's being described here.

Because it turns out there's a lot of things that young people find weird that they later understand.

Re: Mastering Programming (2016)

#119

Post by randomdata »

PH95VuimJjqBqy wrote: post #118
randomdata wrote: post #116

Earlier quoted context omitted.

It's always strange when someone on a discussion forum defers to someone else for their thoughts. Why even bother? It's even stranger when the deferral isn't even relevant. Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH. Beck's insight with TDD, ove…

this is all just a defensive mechanism to try and dismiss the point. What's going to happen is that over time you'll eventually have the experience to understand what's being described here. Because it turns out there's a lot of things that young people find weird that they later understand.

> this is all just a defensive mechanism to try and dismiss the point.

I figured.

> What's going to happen is that over time you'll eventually have the experience to understand what's being described here.

I've been around long enough to be aware of the surface level motivation – accepting the point without defensive dismissal would cause harm to your ego. I just don't get the appeal. Who cares about the ego? If you have no thoughts to share, why post anything? Surely if DHH wants to share his thoughts here, he can come here himself?

> Because it turns out there's a lot of things that young people find weird that they later understand.

Curiously, older people almost universally state that getting older means caring about the ego less and less. Maybe what you are trying to say here is that you are still too young to understand that? Fair enough.

Re: Mastering Programming (2016)

#120

Post by PH95VuimJjqBqy »

randomdata wrote: post #119
PH95VuimJjqBqy wrote: post #118

Earlier quoted context omitted.

this is all just a defensive mechanism to try and dismiss the point. What's going to happen is that over time you'll eventually have the experience to understand what's being described here. Because it turns out there's a lot of things that young people find weird that they later understand.

> this is all just a defensive mechanism to try and dismiss the point. I figured. > What's going to happen is that over time you'll eventually have the experience to understand what's being described here. I've been around long enough to be aware of the surface level motivation – accepting the point without defensive dismissal would cause harm to your ego. I just don't get the appeal. Who cares about the ego? If you…

it'd be akin to someone arguing with a 10 year old about how they should feel losing someone they've been married to for over 40 years. That 10 year old just flat doesn't have the tools to understand so why bother.

or to quote a meme.

transparent poster is transparent.

Post reply on HN