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

151–160 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#151

Post by teyc »

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…

ObjectFactoryFacadeCollection eh?

I know of a lot of people who'd code like this saying that it makes their code more testable et c, but they couldn't show me any test code.

Re: Coding Skill and the Decline of Stagnation

#153

Post by humbledrone »

dustingetz wrote: post #86
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... ... until your first hire

In my experience as a person who has been hired before, I can say that I would absolutely prefer well-factored, but rather concrete code over towering abstractions. Sure, if something is a general feature, it should be abstract. There's nothing more frustrating, though, than wading through layers of abstractions, only to find that hidden behind them is a singular concrete implementation.

Re: Coding Skill and the Decline of Stagnation

#154

Post by teyc »

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…

Not that controversial in Python. GvR's attitude is use conventions, and "after all, we are all consenting adults. :)"

I found this worked very well in real life.

Re: Coding Skill and the Decline of Stagnation

#155

Post by teyc »

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…

Abstractions reflect a persons understanding of the problem space. Iterative game development is exploratory. There is some trade off between redundant code and ease of local modification without worrying about global impact.

Re: Coding Skill and the Decline of Stagnation

#156

Post by teyc »

jquery wrote: post #64
jiggy2011 wrote: post #62

Earlier quoted context omitted.

I think that's because university teaches abstractions and pretty much nothing else. A project that is done in the average CS class will be presented as a way to teach a design pattern rather than teaching how to solve a problem. Also the marking scheme will tend to favour a broken solution that is an attempt at an elegant abstraction rather than a more basic abstraction that is well tested and works. There is a cert…

> I think that's because university teaches abstractions and pretty much nothing else. Maybe my CS degree was unique (I don't think it was), but at the 400 level we had specialization choices including security, graphics, web development, databases, operating systems, embedded, software engineering, etc. > A project that is done in the average CS class will be presented as a way to teach a design pattern rather than…

+1 reminds me of j2ee pet shop. Beautiful abstractions; low as a dog.

Re: Coding Skill and the Decline of Stagnation

#157

Post by rckclmbr »

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…

> I could see them as truths if we were talking about triathlon

Nobody can beat Chrissie Wellington. Nobody.

Re: Coding Skill and the Decline of Stagnation

#158

Post by teyc »

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…

Engineering has been always about trade offs. Every time I'm raced to use reflection to get to private members, I'm reminded that these abstractions are never free.

Re: Coding Skill and the Decline of Stagnation

#159

Post by masklinn »

de90 wrote: post #91
masklinn wrote: post #82

Earlier quoted context omitted.

> The way current C# does accessors / properties is just about perfect As far as I'm concerned it's quite far from it, because C# still allows public fields, properties and fields are incompatible, properties and methods are separate and Microsoft specifies different naming conventions for fields on one hand and properties & methods on the other. Perfection is Smalltalk's way of doing it. And in a syntactic line clos…

What is wrong with different naming conventions for fields vs. properties, and methods? It makes it immediately obvious what is what at a glance. *Honest question - I first learned programming with C#, and so those conventions seem 'correct' to me.

> What is wrong with different naming conventions for fields vs. properties, and methods? It makes it immediately obvious what is what at a glance.

Which is precisely one of the problems of properties in C#, it makes fields and properties look and feel extremely different from the outside which violates the uniform access principle.

As I noted, ideally C# should not have public fields in the first place.

Re: Coding Skill and the Decline of Stagnation

#160

Post by masklinn »

pigs wrote: post #92
masklinn wrote: post #83

Earlier quoted context omitted.

> The mere act of adding a getter violates immutability. Uh what? No it does not. Writing stupid getters (or classes) might, but writing getters does not "violate immutability". Naturally, getters are not of much use if all your fields are final and hold immutable objects , but the latter can be tricky in many OO languages. Getters significantly improve the situation there, by providing a point at which you can clone…

Oops, meant to say "adding a setter violates immutability"

Bean-type setters, definitely.

On the other hand, you could have "setters" using the same naming convention which do a clone-and-replace (and return the new object), that would not violate immutability (and would be easier than building objects from scratch every time from the outside) e.g.

    Type setFoo(FooType foo) {
        return new Type(
            this.field0,
            this.field1,
            this.field2,
            foo, // bam
            this.field4);
    }
many functional languages have that behavior when manipulating "records".
Post reply on HN