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

181–190 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#181

Post by Garbage »

Sufrostico wrote: post #28
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…

IMHO most software 'service life' it's not long enough to justify the annoyance of the accessors. Most software are outdated after a couple of years. But I still think that accessors are a must if you know that the software will be immortal (like Internet banking applications)

That is an understatement. I am currently working on a code which was written at 10 years back. And that code is still running on production server.

tl;dr; Usually enterprise Java applications does have long "service life".

Re: Coding Skill and the Decline of Stagnation

#182

Post by hackinthebochs »

humbledrone wrote: post #148
hackinthebochs wrote: post #125

Earlier quoted context omitted.

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

He may have been referring to framework-level abstractions, but I was specifically referring to natural abstractions for the problem space. Blanket statements against abstractions in code is missing the point--abstractions are fundamental to programming. "Elaborate object frameworks" could mean a few different things. If you're referring to design pattern type structures, then I somewhat agree that the fewer the better. But in the general case it is not true that perfect is not being able to take anything more away. Not when humans are the ones writing and maintaining the code.

Re: Coding Skill and the Decline of Stagnation

#183

Post by jeffdavis »

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…

"Its a continuum..."

I don't think of it that way, at all.

Even if you are only moderately good, you'll have a unique combination of knowledge that allows you to see things that others can't, and that will enable you to do amazing things.

Of course you should always try to improve. But consider where you invest your time. If you know X well, and most people that know X well also know Y well; then maybe you should learn Z instead of Y. Don't always choose Z -- maybe X and Y are complementary and so it may make more sense to learn Y than Z -- but if you follow someone else's curriculum exactly, you will only be re-discovering what they already know.

Re: Coding Skill and the Decline of Stagnation

#184

Post by hackinthebochs »

dextorious wrote: post #170
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…

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

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

But this is simply framework-level abstractions.

Re: Coding Skill and the Decline of Stagnation

#185

Post by hackinthebochs »

humbledrone wrote: post #149
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…

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…

This isn't necessarily true. Sometimes you do in fact need these types of abstractions. This is why they've been made into patterns. The trick is to not use it before its necessary. The mere existence of it doesn't imply overengineered code.

Re: Coding Skill and the Decline of Stagnation

#186

Post by hackinthebochs »

Deestan wrote: post #173
angersock wrote: post #41

Earlier quoted context omitted.

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…

> If your fingers protest at the additional "get" in your function names, go and buy yourself a real IDE. If you can't see how abstraction layers affect performance, go buy yourself a real education. This isn't about premature optimization, it's about not applying premature generalization. Sometimes it immediately makes sense to add accessors. In that case I add them right away. Sometimes there is no apparent need fo…

This smells of bucking conventional wisdom simply for its own sake. Unless you have a good reason not to follow best-practices, you're a bad programmer if you don't (this doesn't always apply if you're writing a project for yourself).

Conventional wisdom is there for a reason--it was wisdom hard fought over many iterations from people who came before. Conventional wisdom has won out against many competing ideas, a survival of the fittest of sorts. You may not always fully comprehend the reasoning for a particular 'best-practices' rule, but you're foolish not to follow it for that reason.

Adding accessors is not 'premature generalization', it's just how you write well engineered code.

Re: Coding Skill and the Decline of Stagnation

#187

Post by dextorious »

hackinthebochs wrote: post #184
dextorious wrote: post #170

Earlier quoted context omitted.

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

>Just build what you need at the time, and make it flexible enough so that it can be refactored to something else later. But this is simply framework-level abstractions.

Well, flexible enough so that it can refactored to something else later != framework-level abstractions.

It could just be as simple: just don't make an untangleable mess out of it.

Re: Coding Skill and the Decline of Stagnation

#188

Post by ceol »

eliben wrote: post #142
stephth wrote: post #127

Earlier quoted context omitted.

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

> People differ in level of intelligence, and this is a fact.

Define intelligence.

Re: Coding Skill and the Decline of Stagnation

#189

Post by dextorious »

dunstad wrote: post #180
jgw wrote: post #12

Earlier quoted context omitted.

Yeah. A couple of times, I've met people who have "dabbled" in programming - maybe done it for a year or two professionally - and said they left the profession because they's pretty much learned everything there was to know about programming. I'm always impressed with their capacity to absorb so much, since I started programming when I was 8 (on a ship, in the middle of the Atlantic, without a computer) and I'm now 3…

How did you learn programming on a ship in the middle of the Atlantic?

Probably found some book or magazine about programming in some cruise ship...

Re: Coding Skill and the Decline of Stagnation

#190

Post by dextorious »

Sufrostico wrote: post #28
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…

IMHO most software 'service life' it's not long enough to justify the annoyance of the accessors. Most software are outdated after a couple of years. But I still think that accessors are a must if you know that the software will be immortal (like Internet banking applications)

"""Most software are outdated after a couple of years."""

You'd be surprised. Tons of code runs in production, even in the latest of shiny systems, that was written 10 and 20 and 30 years ago -- either in whole or in parts, refactored etc.

From 1986's NeXT OS that is now OS X Lion and iOS 5, to Bill Joy's TCP/IP, to Emacs.

And tons of enterprise/banking/financial/military systems use ancient code, even 70's COBOL...

Post reply on HN