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

21–30 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#21

Post by lclarkmichalek »

jarrett wrote: post #13
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…

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…

A lot of languages have constructs that allow changing an attribute into a method call transparently (@property in python and D)

Re: Coding Skill and the Decline of Stagnation

#22

Post by jiggy2011 »

jarrett wrote: post #13
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…

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…

I think this idea is that you can use "properties" rather than public class variables.

Then you can convert your public vars into properties at a later date.

This means that you will not have to (necessarily) rewrite your code as the language knows that

a = myobj.myvar

now should call getmyvar() in the containing class and:

myob.myvar = a

should call setmyvar(a) , I know that C# certainly allows this.

Re: Coding Skill and the Decline of Stagnation

#23

Post by jarrettcoggin »

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.

Can you provide any examples? Was it the tools he was using, notes he was making, or diagrams he was drawing? I haven't seen him program, so I'm curious as to what makes him so much more productive.

Re: Coding Skill and the Decline of Stagnation

#25

Post by cstuder »

jarrett wrote: post #13
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…

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.

Re: Coding Skill and the Decline of Stagnation

#26

Post by angersock »

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…

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 position public members.

I then decide that all of my sprites draw slightly differently (different scales/glow effects/color tint/whatever).

Version 2: I pass the renderer my sprite, it gets the size and render settings members from the sprite, and then draws it.

Oops! I now decide I want a hierarchy of sprites, so that I can add hats.

Version 3: Same as version 2, but in the draw routine now the renderer asks the sprite for its parent to calculate its position and size, and now I've got more renderer code and more sprite code. I can't just use the exposed position member of the sprite--it has context and logic behind it that must be done.

Oh wait, I have a problem in which the sprite glow might change depending on how many times its been drawn.

Version 4: The renderer now has to keep track of how many times it's drawn a sprite. My renderer is getting a bit chunky now.

Did I mention scale should change according to time but also the sprite's velocity?

Version 5: Renderer grabs these variables directly, and does all that other stuff too.

...and that now I want to let that scale be overridden by a isConstantSize flag on the sprite?

Version 6: aaaaaargh

...and that now the sprite can decide it wants to defer to a parent sprite's settings sometimes?

Version 7: what did i do to deserve this?

~

Proper encapsulation and use of accessors is clearly a sign of paranoia. That said, as your code evolves, you might find that this paranoia is completely justified. Hiding queries behind interfaces lets you future-proof them and trivially add more advanced behavior and hooks.

Even when you are working by yourself on an internal project, you are never working alone. You are also working with your future self, and that person is guaranteed to want something different from you and to make assumptions that you are not.

Re: Coding Skill and the Decline of Stagnation

#27

Post by jebberjeb »

[deleted] wrote: post #16
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…

[deleted]

Who was talking about Scala?

Re: Coding Skill and the Decline of Stagnation

#28

Post by Sufrostico »

jarrett wrote: post #13
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…

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)

Re: Coding Skill and the Decline of Stagnation

#29

Post by angersock »

angersock wrote: post #26
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…

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…

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 your own code, or check your assumptions about variables, or track who is accessing what when.

(for what it's worth, I don't use protection for data members of Plain-Old-Data types [say, messages or vectors] very often--they're too dumb to deserve this sort of extensibility or cost)

Re: Coding Skill and the Decline of Stagnation

#30

Post by InclinedPlane »

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.

The way current C# does accessors / properties is just about perfect, I wish more languages would adopt it.
Post reply on HN