Coding Skill and the Decline of Stagnation • Hacker News Board

Re: Coding Skill and the Decline of Stagnation

#41

Post by angersock » Fri, Jan 13, 2012, 8:44 PM UTC

Deestan wrote: post #38

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…

> 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 mentioning--you just call the variable directly and behind the scenes you have replaced the variable name to be a function doing your magic instead.

If your fingers protest at the additional "get" in your function names, go and buy yourself a real IDE.

EDIT: Parent thread added clarification worth noting here. I'm not saying you should add accessors for every protected member--that's just as bad. I mean to say you should only expose members that absolutely require it (the fewer the better, generally), and only do so through function interfaces you can hook. :)

Re: Coding Skill and the Decline of Stagnation

#42

Post by bbwharris » Fri, Jan 13, 2012, 8:47 PM UTC

jiggy2011 wrote: post #35

bbwharris wrote: post #6

There is no "Gospel" when it comes to programming. There is a lot of code out there that isn't pretty, but it works and brings money into businesses. I think we can all agree that Notch didn't make any mistakes. Minecraft is a huge success. They are called "best practices", not "the only practices". But good for Notch to want to be like everyone else.

I think he wants to improve his design skills , not necessarily "be like everyone else" Just because minecraft is a success does not mean there are not going to be parts of it's codebase that could be improved in such a way that it would improve their ability to iterate and add more features quickly in future.

In my experience adding new features quickly is a loaded term. My guess is that Notch would know exactly how to add new features to Minecraft very quickly. He has intimate knowledge of the codebase. However, asking someone else to do so is where this ability to iterate will be lost.

I admire well written code, but a lot of times I see gold plating where is isn't really necessary, because "maybe one day we could add X". You still have to maintain the knowledge of where that easy addition could be plugged in.

Code is great, we can just throw parts of it away and refactor it to add new features. Which is possible if you follow best practices. ;)

Re: Coding Skill and the Decline of Stagnation

#43

Post by pigs » Fri, Jan 13, 2012, 8:48 PM UTC

kalak451 wrote: post #39

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…

The getter/setter stuff in java is a huge waste of space and time. However, at least in the enterprise space, all of the tooling and frameworks assume your code follows the java bean naming conventions. For this reason alone I always make sure all my classes follow the pattern and whenever I train new developers I make sure they get a large amount of experience building out bean definitions and understand how much ti…

Joshua Bloch in Effective Java argues that the java bean is an anti-pattern and should be avoided.

Re: Coding Skill and the Decline of Stagnation

#44

Post by InclinedPlane » Fri, Jan 13, 2012, 8:48 PM UTC

jb55 wrote: post #15

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.

He uses Java, there's only so much stink you can remove from Java code, mostly you just push it around and try to make it as small as possible. Java is still a decent production language for some tasks, but its lack of some basic features and syntactic niceties means you have to hold your nose while coding most of the time.

Re: Coding Skill and the Decline of Stagnation

#45

Post by adgar » Fri, Jan 13, 2012, 8:51 PM UTC

cstuder wrote: post #25

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…

No. C# and Objective-C (And I assume similar languages too) can have public accessors which are not used like function. No need to add ()'s everywhere.

You say "No." so defiantly, but the reality for Java - which is what everybody else was talking about in this thread and the article - the answer is quite often "Yes."

Re: Coding Skill and the Decline of Stagnation

#46

Post by figglesonrails » Fri, Jan 13, 2012, 8:53 PM UTC

Deestan wrote: post #38

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…

> 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 development in order to save potentially long and annoying refactors later. I've been using Visual Assist and I can actually get it to dump an accessor into the console faster than I can type out the full variable name (for variables name that aren't i,j,k).

On a more serious note, trivial accessors generally don't result in any more compiled code than direct field accesses, but do have the advantage of abstraction. If your development process is limited by the time it takes you type out the name of an accessor (or in my case, the first 3 letters), then you must be really productive or not do other things like documentation or testing.

Re: Coding Skill and the Decline of Stagnation

#47

Post by jiggy2011 » Fri, Jan 13, 2012, 8:54 PM UTC

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 like functional programming languages , systems with huge scalability , hardcore math problems and the finer points of memory management in the Linux kernel that you feel it is obvious that you should understand this stuff.

I have been trying to do some more book reading to improve, of course the issue is that whenever you read any book recommendation threads of HN there is always at least 30 or so recommendations of some pretty thick books and no chance I'd have time to read them all.

There is also a difference between having deep knowledge of the tools and libraries that you are using right now and having a deeper understanding of theory for example learning git vs learning graph theory etc.

Re: Coding Skill and the Decline of Stagnation

#48

Post by koenigdavidmj » Fri, Jan 13, 2012, 9:00 PM 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…

The problem is when those getters and setters have other effects (maybe invalidating a cache?). In Java, it's considered best to just go ahead and add the getters and setters first, so that when you need to add these side effects later you don't have to modify lots of code using your library (if that is even possible). Languages like Python make this unnecessary since they have first class properties:

  # Old
  class Foo(object):
      def __init__(self):
          self.x = 0
  foo = Foo()
  foo.x = 1

  # New
  class Foo(object):
      def __init__(self):
          self.__x = 0
      @property
      def x(self):
          return self.__x
      @x.setter
      def x(self, val):
          self.__x = val
          do_other_stuff()

Re: Coding Skill and the Decline of Stagnation

#49

Post by figglesonrails » Fri, Jan 13, 2012, 9:01 PM UTC

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's a pretty brutal stance. :|

I can't say I know the average shelf life of a software component in various languages, but I can say that at least things like Java have managed to justify their use of accessors by that metric. Maybe the focus should be on writing less throwaway code than deciding whether to "invest" a few extra minutes or not on accessors.

Re: Coding Skill and the Decline of Stagnation

#50

Post by jiggy2011 » Fri, Jan 13, 2012, 9:02 PM UTC

bbwharris wrote: post #42

jiggy2011 wrote: post #35

Earlier quoted context omitted.

I think he wants to improve his design skills , not necessarily "be like everyone else" Just because minecraft is a success does not mean there are not going to be parts of it's codebase that could be improved in such a way that it would improve their ability to iterate and add more features quickly in future.

In my experience adding new features quickly is a loaded term. My guess is that Notch would know exactly how to add new features to Minecraft very quickly. He has intimate knowledge of the codebase. However, asking someone else to do so is where this ability to iterate will be lost. I admire well written code, but a lot of times I see gold plating where is isn't really necessary, because "maybe one day we could add X…

Being able to hand of code to someone else is always going to be useful in any non trivial program. Very rarely are successful projects handled by one person in a vacuum.

I think the issue is in designing the initial structure you have to make decisions about which parts of the code will be important and how the relationships of objects etc will work. Sometimes if you have something that differs massively from your initial assumptions then you are in for an enormous refactoring job (as well as often a big data wrangling job if your app is already in production).

When I have done work for clients I have had fairly simple feature requests which I had not anticipated which have required fairly fundamental re-structuring of the codebase, if I had known these in advance I would have designed it differently.

Even if I had not known the specific changes in advance but I knew how much it would be likely to change then there are places where I would have also altered the design , but of course having said that there were areas where I spent allot of time creating code that allowed for flexibility where it was simply not required.