101–110 of 206 posts
When watching Notch code I noticed a lot of code smelly habits, relying on inheritance over composition is one example. But my god his level of productivity and ability to get shit done is lightyears ahead of your average programmer, and you got to respect that more than anything.
Show me someone who doesn't have code smelly habits and I'll show you a book author or a pedantic blogger -- not a production coder.
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.
What, is there some kind of run on parens in your neck of the woods? Running such a lean startup you can't afford a function invocation? This isn't premature abstraction or architecture astronautics--this is just good practice. If you are in a language like Java or C, your compiler should optimize away the call if it doesn't do something clever. If you are in Ruby, this is so easy to do that it doesn't even need ment…
Plus, no, often I can't afford a function invokation. Because it's yet another cache miss.
If all of those things don't matter (or you work on a large enough team that the benefits of abstraction are worth it), yes, add getters/setters everywhere. For the rest of us, we might have actual _reasons_ why we don't cargo-cult our code.
Earlier quoted context omitted.
Eh, using protected/private members is one of those things that makes sense only insofar as you are paranoid that you can't just access internals directly. That said, consider the following. I've got a renderer that accepts a sprite to draw. Version 1: I pass the sprite object to the renderer, and the renderer gets the texture contained in the sprite and draws it, scaling it according to the sprite's size and positio…
Wait... why wasn't the sprite responsible for rendering itself from the beginning? sprite.render(context); or some such...
You want sprites to be an array, and render that in one go.
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…
> Based on what I've read from decompiled Minecraft, I'd guess Notch is self-taught. The abstraction is just barely enough to get the job done How can you tell from decompiled optimized code? Not saying you can't, just interested. Haven't read much decompiled.
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...
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 said, within the comfort zone, there are high and low levels of abstraction. For example, in a project the size of Minecraft, I would expect CS major code to contain an ObjectFactoryFacadeCollection or two. Minecraft has nothing of the sort. It sticks almost exclusively to the Mob::HostileMob::Zombie inheritance we all grew up with. This is not bad or good[1], it's simply a reflection of the low-abstraction style of attacking problems that I associate with self-taught programmers.
On the other hand, its Magic Number to Constant ratio is downright scandalous . . . ;) Though it's possible that some of that is an artifact of the compilation/decompilation process.
[1] I'm lying, in this case it's a good thing.
I honestly don't see what about this post is Hacker News worthy. Is it just the fact that the post was written by the Minecraft developer? Or it it the (somewhat questionable) display of humility? It's sort of like posting a long list of your accomplishments and then saying "but I don't consider myself special, and I have much more to learn". If the sentiment was true, you probably wouldn't say it, and almost certain…
Does anybody know if Notch is self taught? I thought he had a CS Degree from somewhere? I can fluctuate between thinking I am a fairly competent developer to thinking that I am possibly the worst programmer there is. I'm not sure which is a better attitude to have, hopefully I am somewhere in the middle. I think the issue with reading some of the discussion on HN is that you get people talking in detail about things…
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…
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...
> > The abstraction is just barely enough to get the job done > Or, in other words, the perfect amount... ... until your first hire