Live data from Hacker News

Notch, WebGL, Dart, and ramping up quickly

blog.tojicode.com

201–204 of 204 posts

Re: Notch, WebGL, Dart, and ramping up quickly

#201

Earlier quoted context omitted.

I've also spent time examining Notch's coding habits. He is a terrible, terrible coder. Minecraft was (and still is) an unoptimized, poorly designed piece of crap when he handed it off to the rest of Mojang. The DCPU-16 he designed had many flaws and his assembler for it threw out assembly convention. He makes very basic mistakes very frequently and his core designs are flawed. I say this as someone who has spent a c…

> He is a terrible, terrible coder. I've had an idea brewing in my head for quite some time, and while I still don't quite have the words to express it completely, it more or less boils down to this: There isn't necessarily a correlation between being a good programmer and shipping a successful product. Now of course we can argue over the definition of "good programmer" and "successful product". I started as a hobby…

To me the real question is not about shipping products vs good programmers. There is is a much more important question when it comes to writing ugly or pretty code:

Does it work and will you maintain it?

In my experience I often had to often fix dozens of critical bugs of "getting things done" programmers.

I often hear "I will fix this later", "I will refactor it later", "but it works", "we can write tests later", "I will comment/document later", "I will clean up later" from these people giving it to maintenance programmers who rewrite the stuff, cause it is too ugly to deal with.

That's a big problem. People write code and other people have to fix this "but it works" code. Great, when you have a node.js application only running cause there is try catches around things hiding all the errors, killing the logging back end.

If you are the only one to read the code than it's fine to do whatever you want with it, as long as it works. But usually code that really works is well-written, well-commented, tested, etc.

Re: Notch, WebGL, Dart, and ramping up quickly

#202

Earlier quoted context omitted.

No, he really is terrible. I'm dead serious. I am responsible for working with his crap all the time, and I probably know more about the technical workings of Minecraft than even he does. Notch writes terrible code.

Sorry to break it to you, but this is the reaction of most people working on others code. It all looks like a bunch of crap held together with duct tape and string when you are the one trying to maintain it or make it do something that wasn't thought about when it was designed.

You're right that reading code is harder than writing, but I think your statement is too extreme - it implies crap code does not really exist or everything is crap. However, we all know that only 90% of everything is crap.

Personally I maintained various codebases (not written by me) and some of them were really terrible, utter mess, while some others were pretty nice to work with, even if I had to refactor sometimes. If programmers thought about code design at least for a while before writing it, and then the code is well-organized (= good separation of concerns, no global state, no copy-paste, complex parts isolated from the simple parts) - it doesn't matter that much that they didn't think of a new feature you're now adding to it.

Re: Notch, WebGL, Dart, and ramping up quickly

#203

Earlier quoted context omitted.

Can you give a couple of concrete examples of why he's so terrible? Or at least the areas in which he is not strong. Because it's clear to me that Minecraft was a fun and stable experience from the end users perspective, at least when I bought it (which was probably a good 18 months after the initial launch).

I'll put this out there that I'm more in the "I'm a maintainer" group, so my lens when looking at code is very much in the "how can I maintain this" sense. There were a few articles written up about a year ago [1] from interviews with Notch. He does stuff like direct variable access instead of using setters/getters because it "gets in the way" which when it comes to encapsulation and separation of concern, etc. it th…

get/set can be added with a single click in most IDEs and all the references to the private variable are fixed for you. However, having a public getter and public setter for a private field is not really that much safer than a public variable. It is still shared, mutable state and anyone holding a reference to the object can mess with its state.

Re: Notch, WebGL, Dart, and ramping up quickly

#204
post #161

Earlier quoted context omitted.

Very well said. Nothing -> something that works (in any way possible, spaghetti code, written quickly) -> something that works (clean refactored code that can be maintained/improved/changed). You can't skip step 2. If you do, you will likely spend more time overall.

If you can skip step two without spending an unjustifiable more amount of time, you're best. Possible? Not for everyone. A great goal? Sure thing.

Who skips step 2 without spending a lot more time on a non trivial project? How did you measure this skipped time in real world cases? And what makes it justifiable or not? Where do you get that information that this person(s) does?

Basically; almost all IT projects are delivered too late and for too much money (including games) (and usually they are still crap code); spending any more time on skipping 2 is clearly not justifiable.

I don't think anyone in a real life scenario can actually get this done; I know plenty of (open source) projects where step 2 is skipped, but not in time realistic for any commercial project. Note that I don't think step 2 is a bad thing to do; prototyping something and rewriting/refactoring is not a bad thing as long as you don't ship it as the actual product.

Post reply on HN