Live data from Hacker News

Coding Skill and the Decline of Stagnation

notch.tumblr.com

81–90 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#81
post #20

I think there's something to be said for starting out with this sort of confidence, especially when you're self-taught. That sort of confidence can provide some incredible motivation. If we realized how much it work it would take to become well and truly good at things like coding, would we start down the path with such fervor? Point is, SOPA sucks.

As a self-taught programmer I started out with completely the opposite level of confidence, and considered myself a really lousy programmer.

I always assumed there were all these "real", "professional" programmers out there that really knew what they're doing, pick crystal clear abstractions, had profound knowledge of security implications, database optimization, data structure usage, good use of object orientation, introduced no memory leaks, knew just what algorithm to pick and wrote great, clear and understandable code.

I still kinda think I suck, but at least now I know that I'm not alone :)

Re: Coding Skill and the Decline of Stagnation

#82
post #25

Earlier quoted context omitted.

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.

> 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 closer to ALGOL, Ruby is about as good as it gets: no public fields, "properties" are normal methods (setters have a little bit of syntactic sugar, but not much) and auto-generating a bunch of getters, setters or both is a class-level method call.

Re: Coding Skill and the Decline of Stagnation

#83
post #59

Earlier quoted context omitted.

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…

"In Java, it's considered best to just go ahead and add the getters and setters first" I don't think this is true. I'll concede that it may be a requirement for certain things like an ORM API, but in the general case, it's bad practice. The mere act of adding a getter violates immutability.

> 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 your internal state and return a copy, letting you keep your object immutable even if you have mutable fields (of course this assumes you can deeply copy all your mutable member objects)

Re: Coding Skill and the Decline of Stagnation

#84
post #73

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…

Your assumption that self taught programmers (ie one that did not get a "formal" education) do not understand fundamentals is utter bullshit. You could reverse your statements and they both still work. I've worked with people that have a masters in CS and in general it matters about 1% of the time. A programmer today has a wealth of information they can pull from that does not require a single ounce of formal educati…

I don't think I made that assumption in that post at all.

My point was more that a formal CS education is likely to give you a different perspective on programming vs being self taught.

I would imagine most self taught programmers focus on results oriented learning, when I first learned to program before doing any formal CS my approach was "I want to do X , what is the minimum set of stuff I need to learn in order to do that good enough", after learning more formal CS and being forced to consider things like abstraction and efficiency for their own sake I would always focus more on them in every program I write.

Not suggesting that you can't be completely self taught and learn everything you could from an academic education (you can) but you are less likely to spend a month learning a bunch of design patterns and algorithms unless they directly apply to something you need to do right now.

You are more likely to just start hacking away at something then think "oh, this code is a mess how can I fix that?" rather than reading the entire gang of 4 book to start off with.

Re: Coding Skill and the Decline of Stagnation

#85

Earlier quoted context omitted.

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…

Wait... why wasn't the sprite responsible for rendering itself from the beginning? sprite.render(context); or some such...

ssssshhhhhhh

(contrived example for making a point... visiting a draw() method with a solid renderer interface is the answer we usually use)

Re: Coding Skill and the Decline of Stagnation

#86
post #57

Earlier quoted context omitted.

Does anybody know if Notch is self taught? I thought he had a CS Degree from somewhere? I can't say with any degree of authority, but based on what I've read of his code, I'd guess he's self-taught. My bigoted preconception is that when it comes to abstraction in code, people with CS degrees err on the side of doing too much, creating extremely elaborate object frameworks that close down options as much as they help…

> 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

Re: Coding Skill and the Decline of Stagnation

#87

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…

"Does anybody know if Notch is self taught? I thought he had a CS Degree from somewhere?" The two are not mutually exclusive. I was talking with a friend recently who's working on her Ph.D, observing that everyone who thought I was so smart in college is now better educated, officially, than me. She was like "You're basically self-taught, but with a piece of paper that says you were willing to stick around in college…

This is interesting, when I studied CS at university I'd say there were 2 different types of people that got high marks.

There were people who were self taught , either before they started CS or once they learned some programming at university they identified other areas outside the course that interested them and they could apply their new programming skills.

These people typically got jobs in the software industry after graduation and become software developers.

The other group of people were people who were just generally high achievers and learned enough programming to pass the course with good marks but nothing much else. They got equally high marks because they were good at passing exams.

Most of them either retrained for a career in finance , went into academia or got management gigs at tech consultancy companies.

I can't think of anybody I know who is a working programmer who is not self taught to at least some degree.

Re: Coding Skill and the Decline of Stagnation

#88
I honestly don't see what about this post is Hacker News worthy. Is it just the fact that the post was written by the Minecraft developer? Or it it the (somewhat questionable) display of humility?

It's sort of like posting a long list of your accomplishments and then saying "but I don't consider myself special, and I have much more to learn". If the sentiment was true, you probably wouldn't say it, and almost certainly wouldn't say it this particular way.

Re: Coding Skill and the Decline of Stagnation

#89
post #78

Earlier quoted context omitted.

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.

C# allows it but but Java doesn't have this. Hence why it's standard operating procedure to just use setters from the beginning, because it might be nontrivial to update all references.

Play! framework allows you to use getters and setters with public members as you would in C#.

Not sure how this is implemented.

Re: Coding Skill and the Decline of Stagnation

#90
post #59

Earlier quoted context omitted.

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…

"In Java, it's considered best to just go ahead and add the getters and setters first" I don't think this is true. I'll concede that it may be a requirement for certain things like an ORM API, but in the general case, it's bad practice. The mere act of adding a getter violates immutability.

[deleted]
Post reply on HN