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

Coding Skill and the Decline of Stagnation

notch.tumblr.com

Post reply on HN
Print view View original

121–130 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#121

Post by hackinthebochs »

jiggy2011 wrote: post #69
pigs wrote: post #63

Earlier quoted context omitted.

The crux of the argument (and most of the book for that matter) is that you want to avoid mutability whenever possible. Adding setters for every field by default means mutability is the default mode for your application. Adding getters for every field by default means you lose any advantages of encapsulation. At one time, Java Beans were a heavily marketed pattern by Sun. Joshua Bloch came along and said "hey, this i…

Why does everything have a getter/setter by default? That is a pretty horrible anti-pattern, is it something to do with being able to serialise the state (including internal state) of the whole object?

It's about hiding implementation. If you access an object only through methods then the implementation can change without the client code having to know or care (aka be recompiled)

Re: Coding Skill and the Decline of Stagnation

#123

Post by grout »

figglesonrails wrote: post #46
Deestan wrote: post #38

Earlier quoted context omitted.

> Oh, and for good measure--everytime you force yourself to use an accessor, you are providing the opportunity for somebody down the line to add debug and validation code. So add it then . Don't pre-generalize everything just in case.

Accessors are hardly a pre-generalization. I believe he was simply telling various use-cases that can be applied. Yes, software requirements change and some things don't (in practice), but you won't know precisely what will and won't need them until you ship. And even then, you may not know what will be required years from now. It seems like the rational option is to sink a second or two more time into the developmen…

"The advantage of abstraction" is not always an advantage, which is the whole point of this whole thread.

Re: Coding Skill and the Decline of Stagnation

#124

Post by steverb »

doyoulikeworms wrote: post #120
jiggy2011 wrote: post #87

Earlier quoted context omitted.

This is interesting, when I studied CS at university I'd say there were 2 different types of people that got high marks. There were people who were self taught , either before they started CS or once they learned some programming at university they identified other areas outside the course that interested them and they could apply their new programming skills. These people typically got jobs in the software industry…

> They got equally high marks because they were good at passing exams. I don't understand how this makes sense, unless being "good at passing exams" means "cheating". Can anybody explain? I hear this said so often, and I usually chalk it up to the speaker rationalizing his own poor scores. My CS exams were always hard, and the only way to "get good" at passing them was to learn the material.

Different types of learning. I got very high grades in all my courses during college, but a number of them were due to the fact that I am really good at cramming and figuring out what to study and what to ignore. That's what it means to be good at passing exams.

Most of my CS courses I actually spent the time to fully understand and internalize the material. That was the material I truly learned.

Re: Coding Skill and the Decline of Stagnation

#125

Post by hackinthebochs »

humbledrone wrote: post #70
Dove wrote: post #57

Earlier quoted context omitted.

Does anybody know if Notch is self taught? I thought he had a CS Degree from somewhere? I can't say with any degree of authority, but based on what I've read of his code, I'd guess he's self-taught. My bigoted preconception is that when it comes to abstraction in code, people with CS degrees err on the side of doing too much, creating extremely elaborate object frameworks that close down options as much as they help…

> My bigoted preconception [...] Well, I would have called you on this, but I guess I don't have to. > The abstraction is just barely enough to get the job done [...] Or, in other words, the perfect amount...

I disagree. Abstraction is fundamental to programming. The more abstractions, the better. I'm not talking about design patterns here, but abstractions that hold explanatory power in your problem space. They necessarily increase code comprehension, reduce potential bugs, etc.

Abstractions reduce potential bugs by reducing the 'interaction-space' of a particular entity in your code. Think about a program that has 100 variables all in one function. That is potentially 100! interactions between entities in your code. When you make a change, you have to reason about all 100! interactions to be sure you're not introducing a new bug.

Abstracts greatly reduce this space. If instead you have 10 objects who each contain 10 variables, within the object you have 10! interactions to reason about. In the main function that ties each object together you now have 10! interactions to reason about. This is many many orders of magnitude easier than the original problem.

The more (natural) abstractions, the better your code.

Re: Coding Skill and the Decline of Stagnation

#126

Post by bitops »

pigs wrote: post #11

"I still stubbornly believe the whole “private members accessed via accessors” thing in java is bullcrap for internal projects. It adds piles of useless boilerplate code for absolutely no gain when you can just right click a field and chose “add setter/getter” if you NEED an accessor in the future." Is this a controversial stance? It seems like common sense, unless I'm misunderstanding something. EDIT: To clarify: I…

It's a bold stance, at least. From my experience, it's idiomatic Java and just one of those things you have to do.

In practice, it's useful because it allows more easily for instrumentation later on. And you can easily throw a "synchronized" on the method if necessary.

Re: Coding Skill and the Decline of Stagnation

#127

Post by stephth »

noonespecial wrote: post #115

There are two truths I try to keep in mind whenever I start feeling either extreme: 1. There are people who are so much better at programming than me, that I could work my entire life and never be as good as they are right now. 2. There are people who are so much worse at programming than me, that they could work their entire lives and never be as good as I am right now. Its a continuum, a hill. Feel the gradient, wa…

I empathize with not wanting to become cocky, but I feel like you're lying to yourself. I could see them as truths if we were talking about triathlon, but something intellectual and logical as programming? If you are able to reach the point where you find yourself enjoying programming, then I think there's good chances that it's only a matter of time - and rightly focused effort - until you are able to produce work of any level of quality, including the current level of the best programmer, and beyond. What sort of limitations make you think otherwise?

Re: Coding Skill and the Decline of Stagnation

#128

Post by cpeterso »

Dove wrote: post #105
humbledrone wrote: post #70

Earlier quoted context omitted.

> My bigoted preconception [...] Well, I would have called you on this, but I guess I don't have to. > The abstraction is just barely enough to get the job done [...] Or, in other words, the perfect amount...

Or, in other words, the perfect amount... Philosophically, I agree. I view premature abstraction in the same light as premature optimization. I believe both abstraction and optimization are incarnations of your understanding of the problem. You want them in important places, not necessarily everywhere, and hence you want them late enough in the engineering process that you understand which places are important. That…

A well-abstracted program can be easier to optimize because modules are more loosely connected and their internal implementations can be replaced/optimized without breaking the rest of the code.

Re: Coding Skill and the Decline of Stagnation

#129

Post by extension »

humbledrone wrote: post #70
Dove wrote: post #57

Earlier quoted context omitted.

Does anybody know if Notch is self taught? I thought he had a CS Degree from somewhere? I can't say with any degree of authority, but based on what I've read of his code, I'd guess he's self-taught. My bigoted preconception is that when it comes to abstraction in code, people with CS degrees err on the side of doing too much, creating extremely elaborate object frameworks that close down options as much as they help…

> My bigoted preconception [...] Well, I would have called you on this, but I guess I don't have to. > The abstraction is just barely enough to get the job done [...] Or, in other words, the perfect amount...

>> The abstraction is just barely enough to get the job done [...]

> Or, in other words, the perfect amount...

Well no, because the job doesn't end when it's "done". Minecraft is the perfect example:

In the earliest versions of the game, blocks were all basically homogenous cubes of some material, so they didn't need to be oriented. Later, blocks were added that did need to be rotated in various ways, e.g. torches, stairs. But each of these blocks had their own private system for choosing, storing, and rendering their orientation. These systems were often similar, but not identical. At this point, roughly half the blocks in the game are orientable in some way and there is still no generic orientation system. Such a system would have avoided massive amounts of redundant code, prevented many bugs, made the user experience more consistent, and made various 3rd party tools much easier to develop.

"You ain't gonna need it" is a cop-out. You are going to need some things. The trick is anticipating which things, and it will definitely pay off if you can guess correctly.

Post reply on HN