Coding Skill and the Decline of Stagnation • Hacker News Board

Re: Coding Skill and the Decline of Stagnation

#161

Post by extension » Sat, Jan 14, 2012, 9:48 AM UTC

humbledrone wrote: post #145

extension wrote: post #129

Earlier quoted context omitted.

>> 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, s…

Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an a…

But what happens if you incorrectly predict that an abstraction will be needed?

Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules.

The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out.

It's nice when things go that way, but it's not the general case. Often, by the time there is a concrete use for abstraction, the damage is done. For example, adding network multiplayer to a game that has been architected for single player is a nightmare of hacks and duplicated code (Notch has explicitly lamented about that one).

Anyway, back to the Minecraft story, who are you to say that the game would be better if Notch followed the premature abstraction strategy?

Notch himself seems to be saying as much in that blog post. But that aside, I'm a fellow game developer who has spent dozens of hours reading and modifying the Minecraft code. Even after a round-trip of obfuscation, it tells the story of its creation quite vividly, and the theme of the story is "hack around it!" Though I still have tremendous admiration for the game and its developers.

Re: Coding Skill and the Decline of Stagnation

#162

Post by teyc » Sat, Jan 14, 2012, 10:02 AM UTC

extension wrote: post #161

humbledrone wrote: post #145

Earlier quoted context omitted.

Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an a…

But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out…

Multiplayer mode can be extremely hard and can take any fun out of being an indie game developer. I'm still not sure if it is the right abstraction to work in on day one.

Re: Coding Skill and the Decline of Stagnation

#163

Post by liquidcool » Sat, Jan 14, 2012, 10:03 AM UTC

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…

We just discussed this at our local JUG meeting last night. My take is that accessors are popular in Java because most popular frameworks (esp. Spring) have a heavy reliance on JavaBeans. Once you start using objects everywhere as JavaBeans, you've no choice but to add them. And the IDE makes it trivial. Yes, there's constructor instantiation in most DI containers, but it's not frequently used.

I do agree that most modern languages have a much more elegant solution for this.

Re: Coding Skill and the Decline of Stagnation

#164

Post by jeremysalwen » Sat, Jan 14, 2012, 10:19 AM UTC

esrauch wrote: post #79

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.

Except there are cases where it will be way more pain later and no perceptible loss ahead of time. Imagine you are debugging something and you want to know where your public variable is getting set to 3. If you are using java and public members you will have to check every single call site, whereas if you have a setter you can just add a single if(x==3){} and put a breakpoint in there and you have done in 30 seconds…

Eclipse can add a breakpoint to a variable. Any time that variable is accessed or set, the breakpoint is tripped. That's less than 30 seconds, that's like 5. You literally just click to the left of the variable definition.

Re: Coding Skill and the Decline of Stagnation

#165

Post by humbledrone » Sat, Jan 14, 2012, 10:35 AM UTC

extension wrote: post #161

humbledrone wrote: post #145

Earlier quoted context omitted.

Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an a…

But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out…

Regarding the construction of abstractions from day one:

http://en.wikipedia.org/wiki/Opportunity_cost

Re: Coding Skill and the Decline of Stagnation

#166

Post by humbledrone » Sat, Jan 14, 2012, 10:38 AM UTC

extension wrote: post #161

humbledrone wrote: post #145

Earlier quoted context omitted.

Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an a…

But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out…

> Then you made a mistake and hopefully learned something.

Perhaps you learned that prematurely abstracting things is a waste of time?

Re: Coding Skill and the Decline of Stagnation

#167

Post by goblin89 » Sat, Jan 14, 2012, 11:00 AM UTC

extension wrote: post #161

humbledrone wrote: post #145

Earlier quoted context omitted.

Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an a…

But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out…

I think the point was that the source code doesn't make the game better or worse.

A nightmare of hacks is fine as long as the product is great.

IMO writing such code is sometimes even better, especially for a solo developer. If you aim to write beautiful code, it might eventually outweigh everything else, while giving a false impression that you're doing the right thing. Your goal is the product, not code. I'd argue that you can't focus on both (it's called ‘focus’ for a reason).

Re: Coding Skill and the Decline of Stagnation

#168

Post by fbru02 » Sat, Jan 14, 2012, 11:35 AM UTC

Dove wrote: post #57

jiggy2011 wrote: post #47

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…

Can you point to resources/books where I can read more about design as is taught in CS degrees? I'm curious on their problem solving strategies compared to mine.

Re: Coding Skill and the Decline of Stagnation

#169

Post by richardk » Sat, Jan 14, 2012, 11:53 AM UTC

It's comforting to see that other people fluctuate between thinking they're awesome and thinking they're awful.

Experience has taught me this:

Never build your self-esteem on comparison with another

And by that I mean, you should never judge your own programming abilities based on other peoples' apparent abilities. If you're programming new stuff regularly, enjoying it and listening to what other programmers have to say, then the chances are you're getting better at it, and that's enough.

Re: Coding Skill and the Decline of Stagnation

#170

Post by dextorious » Sat, Jan 14, 2012, 12:04 PM UTC

extension wrote: post #129

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...

>> 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, s…

"""Well no, because the job doesn't end when it's "done"."""

By definition, it does.

"""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 (...)"""

So you are suggesting that they should have set up a system to allow that from the beginning.

Have you sat and thought how adding things like that could delay the initial release?

Also, have you sat and thought that if the initial release was not successful at the marketplace, all that extra work would have been in vain?

[downvote? Thanks, parent]

Just build what you need at the time, and make it flexible enough so that it can be refactored to something else later.