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

141–150 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#141

Post by haldean »

tikhonj wrote: post #34
jarrett wrote: post #13

Earlier quoted context omitted.

Controversial might be too strong a word, but there is a counterargument to be made. Suppose you have a member named "x." Someday, you might want to stop storing x, and instead make it a calculated value. At which point you'll need a method. Or, when setting x, you may someday want to increment a counter, or transform the input data, or take some other action. Again, you'll need a method. Yes, it's very easy to add a…

Gosu supports a property syntax that lets you use = to assign things to get/set method pairs. In fact, when you load existing Java code, it replaces getFoo() and setFoo(foo) methods with a property. This makes the code neater and enforces the abstraction--the user of the property does not need to know whether you've implemented it as a simple variable or a complicated method. A bunch of other language let you do this…

Python can do this: http://docs.python.org/library/functions.html#property

Re: Coding Skill and the Decline of Stagnation

#142

Post by eliben »

stephth wrote: post #127
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 o…

Project this onto math, and we all could be Ramanujan or Galois with the right investment of time, right? Of course not. People differ in level of intelligence, and this is a fact. Some programmers are just brilliant people - had they chosen math they would probably be professors churning out papers. Some others just don't have the mental skills required.

This isn't about race or gender or whatever - just innate difference between individuals.

Re: Coding Skill and the Decline of Stagnation

#143

Post by [deleted] »

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…

[deleted]

Re: Coding Skill and the Decline of Stagnation

#144

Post by eropple »

BoppreH wrote: post #96
angersock wrote: post #29

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. Or to add locking and critical sections. Or replace a dumb get and recalculation with caching. Or replace caching with a dumb get. Or a database access. This flexibility is not something you might think you need. You might also never need to debug yo…

For that I prefer the ActionScript3.0 solution: methods that imitate attributes. You replace public var myAttribute:int; with public function get myAttribute():int; The caller uses both with the same "object.myAttribute", so you can just replace one with the other when the need arrives, without changing any other code. This allows you to use all sort of syntactic sugar ("object.myAttribute++", "+=" and other assignme…

Sure, but Java doesn't have that. =) Some of the Java.next languages (Scala among them) do, though.

Re: Coding Skill and the Decline of Stagnation

#145

Post by humbledrone »

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…

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 abstraction will be needed? You create a bunch of unnecessary framework code that is harder to understand, likely less efficient, and worst of all, you wasted time writing code that you didn't need.

YAGNI is not a cop-out. 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. That guarantees that you don't waste time on things that you don't use. It also generally leads to better abstractions, because you have concrete use-cases to work from.

Anyway, back to the Minecraft story, who are you to say that the game would be better if Notch followed the premature abstraction strategy? Isn't it possible, perhaps, that he would have wasted enough time implementing ivory towers of abstraction that he might have left out the features that actually made the game fun?

Re: Coding Skill and the Decline of Stagnation

#148

Post by humbledrone »

hackinthebochs wrote: post #125
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...

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 v…

> The more abstractions, the better.

No. A hundred times no. If you have ever had to make sense of a complex program that was over-engineered with unnecessarily complex abstractions, you cannot possibly think that this is true.

> Think about a program that has 100 variables all in one function [...]

This isn't an example of code that is not abstract enough, it's an example of a basic failure to understand the principles of writing a program meant to be read by other humans. Sure, breaking that code up into understandable chunks is a form of abstraction, but it's not exactly the kind of abstraction that the grandparent was talking about. She was talking about "extremely elaborate object frameworks." I maintain that elaborate object frameworks are a bad thing, unless they are "barely enough to get the job done." Anything beyond that adds unnecessary complexity.

This beautiful and poignant quote sums things up much better than I ever could:

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

Re: Coding Skill and the Decline of Stagnation

#149

Post by humbledrone »

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…

Have you ever looked at a class named ObjectFactoryFacadeCollection and thought to yourself, "oh boy, this part will be fun to read?"

On one hand there's the complexity of the problem you're solving. On the other hand, there's incidental complexity. The ObjectFactoryFacadeCollection class squarely falls into the incidental complexity category. In other words, the moment you are writing a class of that sort, you have stopped working on solving the problem you set out to solve -- you're solving a problem that was invented by your tools, design, or limits of your understanding.

Rich Hickey gave an extremely good talk about trying to avoid this kind of incidental complexity: http://www.infoq.com/presentations/Simple-Made-Easy .

Re: Coding Skill and the Decline of Stagnation

#150

Post by humbledrone »

jiggy2011 wrote: post #111
Dove wrote: post #105

Earlier quoted context omitted.

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…

Philosophically, I agree. I view premature abstraction in the same light as premature optimization. It's usually easier to optimize later since optimisations are often just taking sections of code independantly and making them quicker. There is the whole 90/10 rule (or whatever it's called) that says it's better to highly optimise a few sections of bottleneck code rather than the whole thing. Trying to retrofit an ab…

> Trying to retrofit an abstraction to a piece of code is almost always a horrible experience frought with mess and compromise.

It is amazing to me that our experiences are so different: I have found the exact opposite of this statement to be true. The only way that I've ever come up with a good abstraction is by starting with something concrete (preferably two or more instances) and factoring out the commonality. Retrofitting a piece of code to an abstraction that was designed in a vacuum tends to be an exercise in frustration, due to the abstraction being shortsighted and insufficiently suited to the problem space.

Post reply on HN