Notch, WebGL, Dart, and ramping up quickly(blog.tojicode.com)
blog.tojicode.com
Notch, WebGL, Dart, and ramping up quickly
http://blog.tojicode.com/2013/12/notch-webgl-dart-and-ramping-up-quickly.html
203 comments
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 considerable amount of my life [1][2][3] figuring out this terrible crap and working around it. Notch is a very bad programmer, and people only revere him because he made Minecraft.
To reply to you all at once: regardless of his ability to create or ship a game, which is not in question, his ability to write good code should not be idolized. His failures have tangible reprecussions that have long plagued the Minecraft hacking community and Mojang itself.
[1] https://github.com/SirCmpwn/Craft.Net
[2] https://github.com/SirCmpwn/Tomato
[3] https://github.com/SirCmpwn/organic
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 considerable amount of my life [1][2][3] figuring out this terrible crap and working around it. Notch is a very bad programmer, and people only revere him because he made Minecraft.
To reply to you all at once: regardless of his ability to create or ship a game, which is not in question, his ability to write good code should not be idolized. His failures have tangible reprecussions that have long plagued the Minecraft hacking community and Mojang itself.
[1] https://github.com/SirCmpwn/Craft.Net
[2] https://github.com/SirCmpwn/Tomato
[3] https://github.com/SirCmpwn/organic
> 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 programmer in my childhood and teens, then went to college, and since then have written code for various companies. For several of the earlier years (including college), I had this wide-eyed fantasy of the brilliant, beautiful code that I would work on once I became a "Real Programmer" (whatever that means).
My hopes and ambitions shattered once I got into the workplace and discovered some of the slop that I had to maintain. Then for a few years I was on a crusade to banish all ugly code from whatever project I happened to be working on at the time.
Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. I don't really know much about the internals of minecraft, but I do know that nearly half of the teenagers in my neighbourhood spend hours and hours playing minecraft.
I have to admit that I'm still an idealist at heart, and of course the best situation would be to have a project that is both externally successful and well-designed (making it simple to fix bugs and add new features and such), but I'm constantly having to remind myself to stop trying to get everything perfect and just write code.
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 programmer in my childhood and teens, then went to college, and since then have written code for various companies. For several of the earlier years (including college), I had this wide-eyed fantasy of the brilliant, beautiful code that I would work on once I became a "Real Programmer" (whatever that means).
My hopes and ambitions shattered once I got into the workplace and discovered some of the slop that I had to maintain. Then for a few years I was on a crusade to banish all ugly code from whatever project I happened to be working on at the time.
Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. I don't really know much about the internals of minecraft, but I do know that nearly half of the teenagers in my neighbourhood spend hours and hours playing minecraft.
I have to admit that I'm still an idealist at heart, and of course the best situation would be to have a project that is both externally successful and well-designed (making it simple to fix bugs and add new features and such), but I'm constantly having to remind myself to stop trying to get everything perfect and just write code.
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.
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.
The great is the enemy of the good.
Aka "worse is better," aka "New Jersey style"
> Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use.
It depends on the use case and business model of your software.
If you want to ship a single version of something then don't worry about code quality. If you're market testing and will get resources for a rewrite if the product takes off then again speed to market is more important than code shape.
But if you want to enhance the software or tune its performance then you need good code structure.
It depends on the use case and business model of your software.
If you want to ship a single version of something then don't worry about code quality. If you're market testing and will get resources for a rewrite if the product takes off then again speed to market is more important than code shape.
But if you want to enhance the software or tune its performance then you need good code structure.
Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a bad thing. Like you say, the amount of sloppy code that you can get away with depends on what you are doing.
There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.
There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.
Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.
I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
I've seen this way, way more often and with far worse overall cost than any kind of perfectionism.
I'm not intending to be some sort of advocate of purportedly bad code, but I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed: You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world, while perfectionists are still busy arguing over trivia.
This is the survivorship bias at play. Organizations accumulate "technical debt" because the only code that gives that any assets has such realistic downsides.
And while you account for the cost, you say absolutely nothing about the benefit/"earnings", which is a typical analysis of people who work on other people's code.
I have created a lot of terrible code in my career, almost always doing greenfield development.
This was code that was spun out under incredible conditions, where we had no idea what our product was going to be, the parameters of the data or the conditions that it would be used in, etc. We had changing dev environments and assumptions, libraries getting tossed and new ones added, etc.
And those projects built companies. And it was always novel hearing someone ranting about technical debt years later, when they were hired in a position and on a team and in a company that only continued to exist because of that solution. Debt indeed.
I'm not intending to be some sort of advocate of purportedly bad code, but I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed: You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world, while perfectionists are still busy arguing over trivia.
This is the survivorship bias at play. Organizations accumulate "technical debt" because the only code that gives that any assets has such realistic downsides.
And while you account for the cost, you say absolutely nothing about the benefit/"earnings", which is a typical analysis of people who work on other people's code.
I have created a lot of terrible code in my career, almost always doing greenfield development.
This was code that was spun out under incredible conditions, where we had no idea what our product was going to be, the parameters of the data or the conditions that it would be used in, etc. We had changing dev environments and assumptions, libraries getting tossed and new ones added, etc.
And those projects built companies. And it was always novel hearing someone ranting about technical debt years later, when they were hired in a position and on a team and in a company that only continued to exist because of that solution. Debt indeed.
I've worked with good code and bad code. Where there was good code, programmer turnover was low and the original programmers were still around.
Where there was bad code, turnover was high and the original coders were long gone, the impression I often got was they'd coded themselves into a corner and it was too much for them.
I honestly think places with bad code just have to keep burning out more and more programmers until someone good enough to dig them out of the hole comes along.
The most successful company had the worst code written by incredibly incompetent programmers who didn't even know basic things. One of their products the programmer was so clueless he'd created a new project and DLL for every single class. Every single class. Still made millions.
There are very few coders who can write and design a large product from scratch. Hence far more bad code than good. I think that's the more likely explanation.
Where there was bad code, turnover was high and the original coders were long gone, the impression I often got was they'd coded themselves into a corner and it was too much for them.
I honestly think places with bad code just have to keep burning out more and more programmers until someone good enough to dig them out of the hole comes along.
The most successful company had the worst code written by incredibly incompetent programmers who didn't even know basic things. One of their products the programmer was so clueless he'd created a new project and DLL for every single class. Every single class. Still made millions.
There are very few coders who can write and design a large product from scratch. Hence far more bad code than good. I think that's the more likely explanation.
Your post has many implied dichotomies and correlations that simply aren't true. For example:
I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed
Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs companies a fortune in maintenance, client dissatisfaction and employee turnover rates.
You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world
Uh, again, no. Bad code often begets bad UI, confusing process for the users, botched transactions and a never-ending stream of database tweaks and patches. I've seen plenty of projects whose overall value to the company was negative. Problem is, that negative was spread throughout large period of time, whereas a proper update or replacement of the system would be concentrated in a much shorter time span. This is where "debt" analogy works very well. Some code is like that credit card you maxed out, but only have enough money to do minimum payments.
I have created a lot of terrible code in my career, almost always doing greenfield development.
Whether you created horrible code is largely irrelevant. What's important is what is your overall trend. Some developers pull the code quality up over time, and them maintain it at some reasonable level after that. Others slowly turn anything they touch into radioactive waste.
I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed
Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs companies a fortune in maintenance, client dissatisfaction and employee turnover rates.
You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world
Uh, again, no. Bad code often begets bad UI, confusing process for the users, botched transactions and a never-ending stream of database tweaks and patches. I've seen plenty of projects whose overall value to the company was negative. Problem is, that negative was spread throughout large period of time, whereas a proper update or replacement of the system would be concentrated in a much shorter time span. This is where "debt" analogy works very well. Some code is like that credit card you maxed out, but only have enough money to do minimum payments.
I have created a lot of terrible code in my career, almost always doing greenfield development.
Whether you created horrible code is largely irrelevant. What's important is what is your overall trend. Some developers pull the code quality up over time, and them maintain it at some reasonable level after that. Others slowly turn anything they touch into radioactive waste.
FYI - You replied to the wrong post.
I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code.
And those same developers almost universally declare the majority of code they come in contact with to be toxic waste. Terrible code that brings down companies and kills careers (this whole hilarious discussion began with someone lamenting about the code that Notch burdened Mojang with. The code that is the sole reason for that company existing. What a horrible burden).
These claims do not mesh. At all. There is a reality that is profoundly different from what people say.
I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code.
And those same developers almost universally declare the majority of code they come in contact with to be toxic waste. Terrible code that brings down companies and kills careers (this whole hilarious discussion began with someone lamenting about the code that Notch burdened Mojang with. The code that is the sole reason for that company existing. What a horrible burden).
These claims do not mesh. At all. There is a reality that is profoundly different from what people say.
This reminds me of how some people argue that morality is hard, because everything is relative, while doing thing they themselves clearly do not consider "right".
Aside from a few inexperienced or delusional engineers, most people I've seen in my professional life are cognizant of the quality of code they produce. The main difference is in how they respond to the cases when that quality dips below a certain level.
Aside from a few inexperienced or delusional engineers, most people I've seen in my professional life are cognizant of the quality of code they produce. The main difference is in how they respond to the cases when that quality dips below a certain level.
[deleted]
I might say that Notch is the best kind of coder, for what his goals are. Notch is, really, a game designer. The goal of a game designer is to iterate a set of rules and mechanics until something fun is tracked down ("fun" is sort of the "product-market fit" of game development.) in the process, they may create prototypes that allow them, or others, to play-test the rules/mechanics, but that prototype is not the output product of the game-designer's work, the ruleset itself is.
Now, frequently, a game-designer may also be a game-developer (someone who takes a ruleset that's already known to be fun, and builds a solid game engine to enshrine its behaviors), and a game UX designer besides. But this doesn't have to be the case. Miyamoto doesn't code or do UX. Will Wright doesn't code or do UX. And Notch should be in roughly the same category.
Obviously, there might be some dysfunction at Mojang that results in prototypes getting shipped instead of developed—but that's a separate issue.
Now, frequently, a game-designer may also be a game-developer (someone who takes a ruleset that's already known to be fun, and builds a solid game engine to enshrine its behaviors), and a game UX designer besides. But this doesn't have to be the case. Miyamoto doesn't code or do UX. Will Wright doesn't code or do UX. And Notch should be in roughly the same category.
Obviously, there might be some dysfunction at Mojang that results in prototypes getting shipped instead of developed—but that's a separate issue.
"Will Wright doesn't code"
Probably not much now, but Will Wright did code his early games (eg. Raid on Bungeling Bay , SimCity, etc).
Probably not much now, but Will Wright did code his early games (eg. Raid on Bungeling Bay , SimCity, etc).
>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.
Notch is inspiring to me the way people like Carmack are not, because I know I'll never be a Carmack -- he's operating on an entirely different level than me. But Notch was able to change the world as a regular programmer plugging away. What he does not seem hopelessly out of reach of my capabilities. You can have a huge impact just being 'good enough'!
(and 'terrible' is hyperbole -- certainly most of the programmers around me at work could not get a 3D engine with Dart up and running in a week, or design a cpu and assembler -- even bad ones.)
Notch is inspiring to me the way people like Carmack are not, because I know I'll never be a Carmack -- he's operating on an entirely different level than me. But Notch was able to change the world as a regular programmer plugging away. What he does not seem hopelessly out of reach of my capabilities. You can have a huge impact just being 'good enough'!
(and 'terrible' is hyperbole -- certainly most of the programmers around me at work could not get a 3D engine with Dart up and running in a week, or design a cpu and assembler -- even bad ones.)
>(and 'terrible' is hyperbole -- certainly most of the programmers around me at work could not get a 3D engine with Dart up and running in a week, or design a cpu and assembler -- even bad ones.)
Fuck, most of those I know couldn't get a basic CRUD app up and running in a week...
Fuck, most of those I know couldn't get a basic CRUD app up and running in a week...
Speaking as a harmonica player, this is a bit like the difference between listening to Toots Thielemans and Stevie Wonder.
When I listen to Toots, I'm thinking, "This is amazing, and wonderful! Aw man, I could never do anything like that."
When I listen to Stevie, I'm thinking, "This is amazing, and wonderful! Wait a minute... It's not that complicated. Maybe I'll never have the soul Stevie does, but if I can't do exactly that, maybe I could do something like that!"
When I listen to Toots, I'm thinking, "This is amazing, and wonderful! Aw man, I could never do anything like that."
When I listen to Stevie, I'm thinking, "This is amazing, and wonderful! Wait a minute... It's not that complicated. Maybe I'll never have the soul Stevie does, but if I can't do exactly that, maybe I could do something like that!"
Sir_Cmpwn's assessment of Notch was harsh, but not wrong.
Notch isn't in the same league as a John Carmack, for example. The most recent release of Minecraft saw massive changes to the underbelly of the game, all of which is being done by Mojang staff other than Notch. The game does have a ton of warts, especially where modding is involved, which can be traced to some of Notch's technical decisions.
Does that mean that Notch is a bad person? A fool? No, neither. Notch had a vision for Minecraft, followed it, and because of that work is now a very rich man who can afford to play with whatever technology he wishes. I wish I was like Notch.
Let's not shoot the messenger here.
Notch isn't in the same league as a John Carmack, for example. The most recent release of Minecraft saw massive changes to the underbelly of the game, all of which is being done by Mojang staff other than Notch. The game does have a ton of warts, especially where modding is involved, which can be traced to some of Notch's technical decisions.
Does that mean that Notch is a bad person? A fool? No, neither. Notch had a vision for Minecraft, followed it, and because of that work is now a very rich man who can afford to play with whatever technology he wishes. I wish I was like Notch.
Let's not shoot the messenger here.
>especially where modding is involved
The modding API consists of decompiling the entire thing and monkey-patching it. Does anyone else see a problem with that?
It's such a fantastic game but it's really unfortunate.
The modding API consists of decompiling the entire thing and monkey-patching it. Does anyone else see a problem with that?
It's such a fantastic game but it's really unfortunate.
And there are plugin developers making good money, server operators doing nothing but running Minecraft servers and living on donations and other monetization schemes. Was he supposed to make the best selling indie game in history and make it easy as pie for the modders to make a living too? He was one guy.
Also hindsight is a wonderful thing
Notch tweeted this in, I'm assuming, response to this thread:
> "Just saw a nerd flamewar debating if I'm a bad programmer. I'm self-taught, prefer working along, and program for fun. Don't learn from me."
Take it for what you will.
https://twitter.com/notch/statuses/408011329237049344
> "Just saw a nerd flamewar debating if I'm a bad programmer. I'm self-taught, prefer working along, and program for fun. Don't learn from me."
Take it for what you will.
https://twitter.com/notch/statuses/408011329237049344
>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.
So, he's a pragmatic programmer that gets shit done -- to the point of being able to design his own toy CPU architecture (which already puts him above 90% of the programmers out there, including people that HAD hardware architecture classes at university).
Sorry if he doesn't live up to your standards...
So, he's a pragmatic programmer that gets shit done -- to the point of being able to design his own toy CPU architecture (which already puts him above 90% of the programmers out there, including people that HAD hardware architecture classes at university).
Sorry if he doesn't live up to your standards...
> to the point of being able to design his own toy CPU architecture
Not sure what the CS curriculum is in other countries but back where I'm from they had basically taught us enough by the middle of the second year for one to be able to design something like DCPU16 using only that knowledge.
In other words, it isn't that hard, especially when you're surrounded by examples. I would expect a second-year undergrad to be able to accomplish that.
Not sure what the CS curriculum is in other countries but back where I'm from they had basically taught us enough by the middle of the second year for one to be able to design something like DCPU16 using only that knowledge.
In other words, it isn't that hard, especially when you're surrounded by examples. I would expect a second-year undergrad to be able to accomplish that.
>Not sure what the CS curriculum is in other countries but back where I'm from they had basically taught us enough by the middle of the second year for one to be able to design something like DCPU16 using only that knowledge.
Same with us. That doesn't mean that 90% of the graduates out there, that even have taken such as class, will be able to do it.
Heck, a surprising majority of them (like 30% or more), even fails writing FizzBuzz ( http://www.codinghorror.com/blog/2007/02/why-cant-programmer... ).
Same with us. That doesn't mean that 90% of the graduates out there, that even have taken such as class, will be able to do it.
Heck, a surprising majority of them (like 30% or more), even fails writing FizzBuzz ( http://www.codinghorror.com/blog/2007/02/why-cant-programmer... ).
Not disagreeing with you but as far as I know most (all?) of the CPU in 0x10c was designed by Romero
And if he had spent his time first becoming the perfect programmer (according to your standards) he probably wouldn't have bothered writing Minecraft in the first place. This type of attitude, and the lack of tact it's usually accompanied by, is by far the biggest issue with the programming community at large. I say this as a "terrible, terrible coder" who entered the field despite the fear of being labeled one.
A terrible terrible coder? That's a really insulting negative tone. Maybe he is not the best but he is clearly not terrible. Out of all the programmers in the world my guess would be that he is easily in the top 1-5% even if he leaves messy code behind.
>No, he really is terrible. I'm dead serious.
Yes, but then you are also dead wrong.
Yes, but then you are also dead wrong.
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.
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.
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.
Not being familiar with his programming abilities or style at all, if we took all of the code ever written, is Notch's code at the very bottom of the pile? That is what I take terrible to mean.
According to some links posted elsewhere in this discussion, Notch admits himself that he is not the world's best programmer, but can we honestly say his code is bad enough that we can consider him one of the world's worst programmers?
Or are you really trying to say his code is average to good, with some mistakes made along the way?
According to some links posted elsewhere in this discussion, Notch admits himself that he is not the world's best programmer, but can we honestly say his code is bad enough that we can consider him one of the world's worst programmers?
Or are you really trying to say his code is average to good, with some mistakes made along the way?
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 throws off some red flags.
I've looked at some of his (at least I believe they were his) projects when attempting to learn a game library (libGDX) and was kinda grossed out by the code. You can say that it's because it was from a Ludum Dare perhaps, but you have to think that he kinda does this all the time. So what would be different from his production stuff.
Pretty much don't look at him as a programming idol, he's simply too cowboy for that. That's fine, cowboys have built tons of stuff, but if you are trying to learn something you may want to avoid their stuff cause it's probably running against the grain in a bad way.
[1] The Article -- http://notch.tumblr.com/post/15782716917/coding-skill-and-th...
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 throws off some red flags.
I've looked at some of his (at least I believe they were his) projects when attempting to learn a game library (libGDX) and was kinda grossed out by the code. You can say that it's because it was from a Ludum Dare perhaps, but you have to think that he kinda does this all the time. So what would be different from his production stuff.
Pretty much don't look at him as a programming idol, he's simply too cowboy for that. That's fine, cowboys have built tons of stuff, but if you are trying to learn something you may want to avoid their stuff cause it's probably running against the grain in a bad way.
[1] The Article -- http://notch.tumblr.com/post/15782716917/coding-skill-and-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.
> instead of using setters/getters because it "gets in the way"
In my opinion it genuinely does get in the way. I want to add a member variable to an object - in many languages (JS, C#, Python for example) you can just declare it and move along, knowing that you can switch it to a property later if you need special handling.
In Java, however, for future maintenance I have to write a `public int getPaula()`, `public void setPaula(int brillant)`. This not only violates YAGNI, it slows things down in the physical "I have to type more" sense.
In my opinion it genuinely does get in the way. I want to add a member variable to an object - in many languages (JS, C#, Python for example) you can just declare it and move along, knowing that you can switch it to a property later if you need special handling.
In Java, however, for future maintenance I have to write a `public int getPaula()`, `public void setPaula(int brillant)`. This not only violates YAGNI, it slows things down in the physical "I have to type more" sense.
While it would seem that getters and setters vs public fields are very similar, there's a catch at least in the C# world - if you have a raw public field and later decide to change it to a property, that breaks your public interface and you have to rebuild stuff against your library.
Thankfully C# makes declaring getters and setters easy from the start, so it's not an issue to use them:
public int SomeField { get; private set; }
That gives you a public property called SomeField which can be retrieved, but which can only be set privately by the class. I'd hate having to write GetBlah and SetBlah; it's damn ugly.
Thankfully C# makes declaring getters and setters easy from the start, so it's not an issue to use them:
public int SomeField { get; private set; }
That gives you a public property called SomeField which can be retrieved, but which can only be set privately by the class. I'd hate having to write GetBlah and SetBlah; it's damn ugly.
[deleted]
get/set went the way of the dodo when eclipse got refactoring.
Its a single-app code-base. Its not an API anyone consumes. Using get/set boilerplate really is just getting in the way.
Its a single-app code-base. Its not an API anyone consumes. Using get/set boilerplate really is just getting in the way.
I mentioned some in a response to a similar comment: https://news.ycombinator.com/item?id=6842944
There's a pattern to your complaints, which is that they are most impacting to long-term external contribution.
That's the area where architecture is driven by philosophy. It's whether or not you _choose_ to study the problem, search for best practices, and work out contingencies during the design phase, or go forward with a simplistic, unknown solution and study it by driving trucks over it[0]. With most exploratory programming - of which games are a prime example - you want to drive trucks because your design is likely to be reworked many times regardless.
As well, independent creation not driven by clients and markets has to be done entirely selfishly. When taking this to heart, one naturally moves towards an exploratory style, because selfish, truck-driving code will satisfy your urges more quickly.
[0] http://www.gocomics.com/calvinandhobbes/1986/11/26
That's the area where architecture is driven by philosophy. It's whether or not you _choose_ to study the problem, search for best practices, and work out contingencies during the design phase, or go forward with a simplistic, unknown solution and study it by driving trucks over it[0]. With most exploratory programming - of which games are a prime example - you want to drive trucks because your design is likely to be reworked many times regardless.
As well, independent creation not driven by clients and markets has to be done entirely selfishly. When taking this to heart, one naturally moves towards an exploratory style, because selfish, truck-driving code will satisfy your urges more quickly.
[0] http://www.gocomics.com/calvinandhobbes/1986/11/26
That's just plain rude.
The perspective of this is so wrong. Minecraft was a Plaything for notch, he wrote the beginnings of it in his free time while working for a different company. He certainly never thought of or even optimized it for being a massive world wide hitgame that needs a consistent modding API. If he did that, i am sure that Minecraft would probably never have seen the light of day as he would have lost interest in it, because most of all it was a sideproject to creatively explore an idea.
Coming in years later when everything has grown tremendously and saying that many of the early design decision were wrong, is so ignorant it infuriates me.
Coming in years later when everything has grown tremendously and saying that many of the early design decision were wrong, is so ignorant it infuriates me.
What kind of a person even idolizes someone for writing great code? Steve Jobs couldn't code at all. Facebook was written in PHP. GroupOn started on WordPress. According to this Slashdot article, Sergey and Larry aren't great programmers.
http://tech-beta.slashdot.org/story/13/11/01/1324209/larry-p...
The Instagram founders didn't have a programming background:
http://thenextweb.com/2012/04/10/instagrams-ceo-had-no-forma...
My take away is that beyond getting the job done, joining the priesthood of programmers is pretty low on what's important.
If you want to be successful, focus on the other things then hire a bunch of programmers to continue your dream once you hit it big. By the way, make sure the interviews are insanely difficult and keep your geeks out of the weeds (e.g. HN). Geeks love to play in the weeds!
http://tech-beta.slashdot.org/story/13/11/01/1324209/larry-p...
The Instagram founders didn't have a programming background:
http://thenextweb.com/2012/04/10/instagrams-ceo-had-no-forma...
My take away is that beyond getting the job done, joining the priesthood of programmers is pretty low on what's important.
If you want to be successful, focus on the other things then hire a bunch of programmers to continue your dream once you hit it big. By the way, make sure the interviews are insanely difficult and keep your geeks out of the weeds (e.g. HN). Geeks love to play in the weeds!
> What kind of a person even idolizes someone for writing great code?
Are we on the same site? I've been reading HN since it was called Startup News, and I have never felt such a disconnect before.
> The Instagram founders didn't have a programming background
Instagram could be worth a trillion dollars and I wouldn't give a shit about it. Show me the code. Satisfy me intellectually. Not everything is about money, and that is part of the reason I call myself a hacker--coding for the sake of coding and what not.
Are we on the same site? I've been reading HN since it was called Startup News, and I have never felt such a disconnect before.
> The Instagram founders didn't have a programming background
Instagram could be worth a trillion dollars and I wouldn't give a shit about it. Show me the code. Satisfy me intellectually. Not everything is about money, and that is part of the reason I call myself a hacker--coding for the sake of coding and what not.
It's not about money, it's about providing value. Beautiful code that solves the wrong problem is just broken, because it doesn't do what it sets out to do. I don't see much beauty in code that's broken like that.
"For every complex problem there's an answer that's clear, simple, and wrong."
"For every complex problem there's an answer that's clear, simple, and wrong."
I don't disagree with what you are saying, but I think you are saying something different than the person I replied to.
To me, the statement "What kind of a person even idolizes someone for writing great code?" suggests that programming is not an art, not worthy of further consideration, a mere means to an end to whatever product to be sold. To me, that statement is like saying "Who even idolizes <insert great painter here>? The guys who sold this art didn't even know how to paint!"
I am not saying that is an invalid viewpoint. I just think it's a weird viewpoint to have on Hacker News. For me, mathematics, code, etc is not a means to an end, but its own reward. To me, that is part of what it means to be a hacker. I wish there was a place where everyone felt the same way. Hacker News used to be that place for me, but the demographic has changed a lot. That is sad.
To me, the statement "What kind of a person even idolizes someone for writing great code?" suggests that programming is not an art, not worthy of further consideration, a mere means to an end to whatever product to be sold. To me, that statement is like saying "Who even idolizes <insert great painter here>? The guys who sold this art didn't even know how to paint!"
I am not saying that is an invalid viewpoint. I just think it's a weird viewpoint to have on Hacker News. For me, mathematics, code, etc is not a means to an end, but its own reward. To me, that is part of what it means to be a hacker. I wish there was a place where everyone felt the same way. Hacker News used to be that place for me, but the demographic has changed a lot. That is sad.
Hmm, you're probably right that the other poster meant his disparaging remark about code quality literally. I also enjoy writing great code for the sake of it (artisanship), but from a business perspective bad, insecure, unreliable code typically won't hold you back much. Treating your employees badly is often good for business too. I'd much rather live in a world where great products win and doing the right thing matters, but we don't.
I also agree that the tone of the community has shifted a lot in the past years. Still, given how much HN has grown the community has survived surprisingly well. It's a bit meaner and nit-pickier than it used to be, though.
I also agree that the tone of the community has shifted a lot in the past years. Still, given how much HN has grown the community has survived surprisingly well. It's a bit meaner and nit-pickier than it used to be, though.
I've been here over 4 years. And I certainly appreciate good coders, and there are times when they do make a difference. e.g. Bill Atkinson...
http://folklore.org/StoryView.py?story=Negative_2000_Lines_O...
However, what was really important is that Bill helped to make the Macintosh great. However, I don't think people will be studying his 68000 assembler in the future like a great math formula or a great painting. We are talking about him because of the results of his work.
http://folklore.org/StoryView.py?story=Negative_2000_Lines_O...
However, what was really important is that Bill helped to make the Macintosh great. However, I don't think people will be studying his 68000 assembler in the future like a great math formula or a great painting. We are talking about him because of the results of his work.
Beats me. I guess someday when you're an old man, right before you close your eyes for the last time, you can imagine all that cool code that you wrote, and say what a great life you had. You were a hacker.
Steve, Larry, Notch, and the Instagram guys can know what they did made a difference. The world is a different place because they lived. They connected the important dots and hacked life...
Steve, Larry, Notch, and the Instagram guys can know what they did made a difference. The world is a different place because they lived. They connected the important dots and hacked life...
There are lots of ways to live a great life and relatively few of them involve fame and fortune.
Also there are many people who make a big difference without achieving fame and fortune. Even within the tech industry I would argue that, for example, Dennis Ritchie's contributions were far more fundamentally important than any of the people you listed, yet he never achieved the massive wealth or mainstream fame of those you've mentioned.
Also there are many people who make a big difference without achieving fame and fortune. Even within the tech industry I would argue that, for example, Dennis Ritchie's contributions were far more fundamentally important than any of the people you listed, yet he never achieved the massive wealth or mainstream fame of those you've mentioned.
I didn't say that you had to achieve massive wealth or fame. I said being that "idolizing someone for writing great code" isn't a worthwhile goal. Dennis Ritchie created two important products that are still used today: C and Unix. I think you'd find plenty of people would have a lot of bad things to say about C, for example, but it did solve a problem and help move the world forward.
By the way, why wouldn't you mention Bertrand Meyer or Niklaus Wirth?
By the way, why wouldn't you mention Bertrand Meyer or Niklaus Wirth?
> I guess someday when you're an old man, right before you close your eyes for the last time, you can imagine all that cool code that you wrote, and say what a great life you had. You were a hacker.
I'm also a researcher, and I like to think that the ideas I discover will outlast me and will make a difference.
Your implication is that those who think of software as a 'product' to be sold are making a difference, and those who think of creating software as its own reward are not. Maybe you are right. I just wish there was a place for those of us who appreciate the craft to hang out. Hacker News, for a long time, was that place for me.
I'm also a researcher, and I like to think that the ideas I discover will outlast me and will make a difference.
Your implication is that those who think of software as a 'product' to be sold are making a difference, and those who think of creating software as its own reward are not. Maybe you are right. I just wish there was a place for those of us who appreciate the craft to hang out. Hacker News, for a long time, was that place for me.
>> I just wish there was a place for those of us who appreciate the craft to hang out. Hacker News, for a long time, was that place for me.
I still don't get what you're talking about, you like to look at and admire code like it's art? Can you give an example of code that gives you satisfaction to just look at it regardless what it does?
I still don't get what you're talking about, you like to look at and admire code like it's art? Can you give an example of code that gives you satisfaction to just look at it regardless what it does?
Since we're talking about Carmack in this thread.... Fabien Sanglard does some excellent reviews of code from ID... see for example:
http://fabiensanglard.net/doom3/
There's actually a movement that studies code in the way you'd examine a literary work (Critical Code Studies). Sure it's very abstract, but it can be fun, see for example this book:
http://10print.org/
You could also look at livecoding - they treat coding as a performance art. For example:
http://www.youtube.com/watch?v=GSGKEy8vHqg
http://fabiensanglard.net/doom3/
There's actually a movement that studies code in the way you'd examine a literary work (Critical Code Studies). Sure it's very abstract, but it can be fun, see for example this book:
http://10print.org/
You could also look at livecoding - they treat coding as a performance art. For example:
http://www.youtube.com/watch?v=GSGKEy8vHqg
This: http://fabiensanglard.net/rayTracing_back_of_business_card/i... is a perfect example of what you're asking for (for me of course).
Contrary to what that article is saying, the Instagram founders did have a programming background. I was at a talk given by Kevin Systrom - he said something about having gotten a B in a programming class at Stanford, so he had at least an intro-level knowledge of coding (which is honestly a better start than something like Codecademy).
Mike Krieger got a degree in Symbolic Systems, which requires quite a few CS courses.
Mike Krieger got a degree in Symbolic Systems, which requires quite a few CS courses.
Personally I couldn't care less about a bunch of ceos or company managers, as a programmer I look up to people like dennis ritchie, linus torvalds, bjarne stroustrup, rob pike, brian kernighan.. etc etc
> The Instagram founders didn't have a programming background
If you spend your evenings learning to program, as the article claims, how do you not have a programming background? John Carmack, who is considered a programming god by many, which can even be seen in this very discussion, also has very little formal training. I don't think that means he doesn't have a programming background.
If you spend your evenings learning to program, as the article claims, how do you not have a programming background? John Carmack, who is considered a programming god by many, which can even be seen in this very discussion, also has very little formal training. I don't think that means he doesn't have a programming background.
So, uhm... how many blockbuster games have you shipped, just out of curiosity?
Not an ad hominem attack. Just, curious, because someone with such confident opinions as yours about notch's abilities must surely have shipped a few.
> Not an ad hominem attack
I don't think just saying that makes it true
I don't think just saying that makes it true
It's not attacking a person to ask them to back up their qualifications to judge.
How many movies or tv shows have you made? Have you ever told someone that a tv show was bad? I bet the answers are zero and plenty, respectively.
The kind of argument you're making is a very big fallacy.
The kind of argument you're making is a very big fallacy.
That's not really a rational analogy. That would be analogous if we were discussing someone consuming minecraft (i.e. playing it), not someone working on it.
I think he may have a point: Notch doesn't need to be an amazing developer but an effective one that delivers.
I don't know Notch's abilities, but from one of his LD videos I can tell he's very focused and knows his craft.
I don't know Notch's abilities, but from one of his LD videos I can tell he's very focused and knows his craft.
I wouldn't call Britney Spears the pinnacle of contemporary arts. But she certainly shipped.
Not the same at all! We're talking about Notch's process. I don't think there's any disagreement about his product being top notch (sorry). The product of BS is well, BS, and her process be damned.
None. I didn't say Notch can't ship a blockbuster game (and he can ship exactly one). I said he can't code worth a damn, and should not be idolized for his prowess.
"I said he can't code worth a damn"
Go and get developers at various companies. Not necessarily game companies, get someone that is payed a salary for "coding".
Give them some rough specifications (for example, a simple maze, simple lighting) and ask for Dart/WebGL to be used, and a timeframe of one month.
See what happens.
Based on my experience, 5% of developers may present something like it.
So, ok, Notch may produce spaguetti code, bugs, etc, but he's probably in that top 5% of developers. (Which is also debatable because someone may be good at, let's say, web development but couldn't code a game to save their lives)
Go and get developers at various companies. Not necessarily game companies, get someone that is payed a salary for "coding".
Give them some rough specifications (for example, a simple maze, simple lighting) and ask for Dart/WebGL to be used, and a timeframe of one month.
See what happens.
Based on my experience, 5% of developers may present something like it.
So, ok, Notch may produce spaguetti code, bugs, etc, but he's probably in that top 5% of developers. (Which is also debatable because someone may be good at, let's say, web development but couldn't code a game to save their lives)
Very few folks are idolizing him for his code correctness, but for his ability to prototype and ship.
I've worked with developers like Notch. I like them because they can create rapidly iterate apps/sites/ideas that normal people/users understand and critique. Then developers like me come in and polish the turds under the covers so we can ship and maintain.
He's not writing SQLite or Space Shuttle code, it's a amusement.
I've worked with developers like Notch. I like them because they can create rapidly iterate apps/sites/ideas that normal people/users understand and critique. Then developers like me come in and polish the turds under the covers so we can ship and maintain.
He's not writing SQLite or Space Shuttle code, it's a amusement.
Notch's code is worth $150 million dollars. What's the going rate for "a damn" these days?
As amusing as your wordplay might be, the point being made is that Notch's coding skill should not be idolized or used as a reference for writing good code. A tangible consequence of his inability is that Minecraft takes up far more resources than it reasonably should and is very difficult to maintain, which has been echoed by several Mojang devs who have since picked it up.
Do you think they'll ever move away from Java?
Do you think Minecraft requires a complete rewrite to be maintainable?
Do you think Minecraft requires a complete rewrite to be maintainable?
I don't think they'll ever move away from Java. I don't think Minecraft requires something quite on the scale of a complete rewrite, but perhaps starting from scratch and pasting in bits and pieces of the original to save time would help things.
They are working on rewriting substantial portions of the codebase, but unfortunatley Notch didn't hand it off to the most skilled maintainers and they aren't making things much better.
They are working on rewriting substantial portions of the codebase, but unfortunatley Notch didn't hand it off to the most skilled maintainers and they aren't making things much better.
they have already moved away from Java via JNI for some aspects of the game, like openGL 2.0 support.
I think this line of thought is a big problem in the development community.
There is a clear separation between code quality and shipping a successful products. Ideally you would want both if possible, but a product is not just code.
There is a clear separation between code quality and shipping a successful products. Ideally you would want both if possible, but a product is not just code.
Ideally both, but if I had to sacrifice code quality for a successful product I would sort in exponential time if it meant getting a working product out the door faster. It doesn't need to be good, just good enough. (IMO obviously)
[deleted]
99% of game and webdevs are like this.
He's your tech co founder when you want to flip fast. Not your first engineer hire.
everyone wants another Carmack, but while productive, he is not (yet?)
anyway, i haven't shipped any blockbuster game (it is not even my job to do so) so i will see myself out now.
He's your tech co founder when you want to flip fast. Not your first engineer hire.
everyone wants another Carmack, but while productive, he is not (yet?)
anyway, i haven't shipped any blockbuster game (it is not even my job to do so) so i will see myself out now.
I started this way. I could iterate on new game prototypes quickly because I made many games then threw them away.
Might be worth noting his game plays and looks like minecraft.
After getting burned by my own design decisions, which each game I made I produced stronger abstractions and decoupled code. Aka learning from mistakes.
Devs who only write protoslop or devs who only maintain and clean code up are rarely effective on their own.
Might be worth noting his game plays and looks like minecraft.
After getting burned by my own design decisions, which each game I made I produced stronger abstractions and decoupled code. Aka learning from mistakes.
Devs who only write protoslop or devs who only maintain and clean code up are rarely effective on their own.
No, it's close to an appeal to authority fallacy. The person you've replied to has reimplemented the Minecraft server along with a few other frameworks.
It would be a fallacy if I had a point, and an argument to make. I have neither. Only a question, with the purposes of placing the comments in some kind of context.
Couldn't agree more. Notch his success has nothing to do with being good at programming. It's about being creative and able to create good game play.
Because he programmed game play routines a lot and dealt with everything involved (i.e graphic rendering and such) more than the average Joe it looks like he is a good programmer because he just shakes it out live on some streaming website. Those concepts are language-agnostic and you can remember them.
Because he programmed game play routines a lot and dealt with everything involved (i.e graphic rendering and such) more than the average Joe it looks like he is a good programmer because he just shakes it out live on some streaming website. Those concepts are language-agnostic and you can remember them.
Jonathon Blow had a great talk on the topic of programming indie games, http://the-witness.net/news/2011/06/how-to-program-independe...
One part he mentions how when he was a more novice programmer and looking at the Doom1 source code he thought they made some horrible programming choices - but only once he actually started to try to make commercial products himself did he realize none of that mattered. When the goal is to make good products with very little resources (which is the defining aspect of being indie) being pragmatic is the most important thing.
what you would consider 'good code' wasn't Notch's goal, doesn't mean he isn't capable of it
what you would consider 'good code' wasn't Notch's goal, doesn't mean he isn't capable of it
I remember you also slated my own programming ability for no reason what so ever, after seeing one tiny script that I wrote in 45 seconds.
You sir, are the kind of person who honestly believe that you're better than everyone else, and quite frankly mate, you aren't.
Are you a multimillionaire? Sometimes it's not about the code quality, it's about the ability to produce a product.
I don't revere Notch, but I do think he's a better developer than most, especially you.
You sir, are the kind of person who honestly believe that you're better than everyone else, and quite frankly mate, you aren't.
Are you a multimillionaire? Sometimes it's not about the code quality, it's about the ability to produce a product.
I don't revere Notch, but I do think he's a better developer than most, especially you.
Yes good code can be commended, but initially it was his small project he worked up to be his golden ticket, never expecting it to be such a huge success. I'd say he did enough good to get it shipped, in the end that is the metric. But in terms of maintenance and clean code, I am a big proponent of it and good architecture. I can't say that this makes a project successful or not but it does make it easier to deal with after it is successful and sometimes largely determines how far it can go. There is always a battle between shipping and quality and here Notch was just shipping, in terms of the end product he is a good coder and a product shipper.
I don't know what standards you are used to but I would really like to know who you consider to be a good programmer. Are you a good programmer? If Notch is a "terrible, terrible coder" then what are the people (ie: normal programmers) who can barely build a standard web CRUD app?
can you elaborate on what's so terrible about his coding style?
There are lots of problems with it. Here are a couple:
He uses poor OpenGL practices, and sees poor performance as a result. He also designed the entire product in a way that makes it cumbersome to mod, without a consistent interface or a logical way for mods to work together. Modding Minecraft as a whole is one big hack.
I'm more familiar with the networking side of things. The Minecraft networking protocol is a mess. There are 9 or 10 different ways to encode a vector in the protocol. He made up "Named Binary Tags", a dictionary serialization format, which could have better been served with existing tech. He frequently misuses signedness in the protocol. He made up another obtuse dictionary format for describing entity metadata. He screwed up backwards compatibility for the only thing that needed to be backwards compatible - three times. His colleagues later screwed things up even more.
He uses poor OpenGL practices, and sees poor performance as a result. He also designed the entire product in a way that makes it cumbersome to mod, without a consistent interface or a logical way for mods to work together. Modding Minecraft as a whole is one big hack.
I'm more familiar with the networking side of things. The Minecraft networking protocol is a mess. There are 9 or 10 different ways to encode a vector in the protocol. He made up "Named Binary Tags", a dictionary serialization format, which could have better been served with existing tech. He frequently misuses signedness in the protocol. He made up another obtuse dictionary format for describing entity metadata. He screwed up backwards compatibility for the only thing that needed to be backwards compatible - three times. His colleagues later screwed things up even more.
You don't seem to understand or have experience with how game code is written.
It's not written to be "modified". It's not written with a specific modular outcome in mind. It's more often than not a one-off messy code that gets the job done, because that's the requirements and the pace of the industry.
And, especially for something like Minecraft, it has to be original and even explore the problem space and ideas in the process of building it. It's not something you do based on a design carved in stone, with some cushy strict waterfall method or what have you.
Building games, and especially such games, is an explorative process, and one-off process, and a war on many fronts (e.g with time, or with tons of competing gameplay ideas).
You are only able to say what you say, because you look at the code in hindsight.
It's not written to be "modified". It's not written with a specific modular outcome in mind. It's more often than not a one-off messy code that gets the job done, because that's the requirements and the pace of the industry.
And, especially for something like Minecraft, it has to be original and even explore the problem space and ideas in the process of building it. It's not something you do based on a design carved in stone, with some cushy strict waterfall method or what have you.
Building games, and especially such games, is an explorative process, and one-off process, and a war on many fronts (e.g with time, or with tons of competing gameplay ideas).
You are only able to say what you say, because you look at the code in hindsight.
I guess it's a balance between over and under-engineering. The thing is, more often that not the person coming along to do 'external modifications' to that code is actually you, a few months after you wrote it.
You can adopt some good coding practices that ensure that the code isn't a spaghetti mess that's hard to understand when you come back and look at it. That's different than designing a system to be pluggable from the start.
So, I haven't watched any of Notch's livecoding videos, but for those who have, what kind of bad is the code? Is it bad "this is a mess and I won't remember what these variables do in 3 months" or is it just simply designed to handle the most immediate case (coded well but not with plugins in mind)?
You can adopt some good coding practices that ensure that the code isn't a spaghetti mess that's hard to understand when you come back and look at it. That's different than designing a system to be pluggable from the start.
So, I haven't watched any of Notch's livecoding videos, but for those who have, what kind of bad is the code? Is it bad "this is a mess and I won't remember what these variables do in 3 months" or is it just simply designed to handle the most immediate case (coded well but not with plugins in mind)?
As you build and explore, you find patterns, see repetitive code, or get frustrated at the hassle it takes to add a new feature.
This is when you refactor. It's that moment of realization when coding and you say to yourself "ah, if I had a compositional object model instead of a god object inheritance nightmare I could introduce new objects so much faster and without destroying the interface of CEntity."
You quickly also realize this means re-writing your inheritance tree, decomposing all of your object classes and reconstructing each one as a bundle of components like renderable, effects, behavior, physical (position), that communicate and interact through messages.
You finally have the flexible buildable adaptable object system to meet your building and maintenance needs. But you had to rewrite 30 classes to get there.
My take is badasses in that moment take the 20 hours and do it right. Many like Notch simply didn't bother. Everyone pays for it later.
"But it's not necessary" they say. What's necessary about being great? Nothing, but being great is Awesome. That said, one would need that attitude to bite into 20 hours of extra unnecessary work with a smile. But it's the starting recipe for a great programmer.
This is when you refactor. It's that moment of realization when coding and you say to yourself "ah, if I had a compositional object model instead of a god object inheritance nightmare I could introduce new objects so much faster and without destroying the interface of CEntity."
You quickly also realize this means re-writing your inheritance tree, decomposing all of your object classes and reconstructing each one as a bundle of components like renderable, effects, behavior, physical (position), that communicate and interact through messages.
You finally have the flexible buildable adaptable object system to meet your building and maintenance needs. But you had to rewrite 30 classes to get there.
My take is badasses in that moment take the 20 hours and do it right. Many like Notch simply didn't bother. Everyone pays for it later.
"But it's not necessary" they say. What's necessary about being great? Nothing, but being great is Awesome. That said, one would need that attitude to bite into 20 hours of extra unnecessary work with a smile. But it's the starting recipe for a great programmer.
>What's necessary about being great? Nothing, but being great is Awesome.
Not really. It's rather pointless, time consuming, and often deleterious to one's work/life balance. Not to mention it can mean that the end result might never ship at all, in an endless pursuit of "greatness".
Not really. It's rather pointless, time consuming, and often deleterious to one's work/life balance. Not to mention it can mean that the end result might never ship at all, in an endless pursuit of "greatness".
Sure. My whole point is you have to believe its the right thing, and be good enough to execute on a large refactor like that without getting stuck in the never-ship mud, or endless pursuits.
Being great is overcoming the reasons you are giving not to do it. Being great is having the vision to see how these decisiosn impacts your ability to deliver in the future.
Being great isn't necessary. And you've pointed that out. Your attitude ensures that the code you write meets your standards. Your standards, aren't "great."
Being great is overcoming the reasons you are giving not to do it. Being great is having the vision to see how these decisiosn impacts your ability to deliver in the future.
Being great isn't necessary. And you've pointed that out. Your attitude ensures that the code you write meets your standards. Your standards, aren't "great."
While Minecraft was never originally designed to be modified by outsiders, unlike most games it was also never just intended to be a one-off release that would ship and that would be it either. From the start, it was always advertised as something that would get substantial new features and improvements over the years.
These all seem like issues that are obvious in hindsight but may not have been obvious at the time. It's much easier to look at an existing, established codebase and point out all the flaws that it is to anticipate all the future challenges. In other words, you're monday-morning quarterbacking.
Maybe Notch didn't start building it with the idea that anyone would want to mod it. Heck, maybe he didn't even anticipate that it would be popular enough to require great performance. If he expected the game to be played primarily by him and a few friends then he could forego performance for beefier machines.
If he started out trying to build a game that would need to be extremely easy to mod and be performant on millions of machines of varying performance capabilities, he probably wouldn't have gotten around to actually writing it in the first place. It's called over-engineering, and it kills more projects than anything else, IMO.
Maybe Notch didn't start building it with the idea that anyone would want to mod it. Heck, maybe he didn't even anticipate that it would be popular enough to require great performance. If he expected the game to be played primarily by him and a few friends then he could forego performance for beefier machines.
If he started out trying to build a game that would need to be extremely easy to mod and be performant on millions of machines of varying performance capabilities, he probably wouldn't have gotten around to actually writing it in the first place. It's called over-engineering, and it kills more projects than anything else, IMO.
Definitely the case. The great programmer, the moment they realize that modding is the future, make their next release to get the modding interface done right. They don't decide "eh, I'll just add a bunch of items I've been thinking about instead."
Was minecraft supposed to be modable from day 1?
I know from my own experience that if you design a large monolithic application and then decide afterwards that you want a pluggable system, it's never easy if you don't have time to refactor the whole thing.
Also network programming and game/graphics programming are different disciplines with their own challenges. Big studios might assign different people to these tasks, so I wouldn't expect somebody to be amazing at both.
Also network programming and game/graphics programming are different disciplines with their own challenges. Big studios might assign different people to these tasks, so I wouldn't expect somebody to be amazing at both.
No, it wasn’t written that way at all. Notch never intended it to be moddable and he had no idea at all that modding would be such a big deal for Minecraft. In the very beginning Notch was even (slightly) opposed to modding. I think it was more like a gut reaction: People are doing things with my stuff I didn’t expect and I don’t like it. (Not that he ever even began to consider taking legal steps against it or something awful like that.)
He came around to it, though. By the time he handed Minecraft off he was fully in the “modding is great for Minecraft” camp. But the game was never developed for that. A real modding API has been in the works for quite some time now, but it seems to be quite hard to pull that off.
He came around to it, though. By the time he handed Minecraft off he was fully in the “modding is great for Minecraft” camp. But the game was never developed for that. A real modding API has been in the works for quite some time now, but it seems to be quite hard to pull that off.
Could you provide more specific examples and possibly detail how you would do it better? If Notch is making these errors you speak of, other programmers probably are too. You've got the perfect platform here to correct the problem.
It's very simple:
-Don't make up things where existing tech would do (ala NBT, entity metadata, etc)
-Don't use a signed number if negative values don't make sense in that context
-Include versioning if something needs to work across versions
-Choose consistent scemantics for data encoding (and anything else you can)
All of this will make it easier for you, too. Focus on reducing internal code reuse, maximizing external code reuse, and simplifying things.
-Don't make up things where existing tech would do (ala NBT, entity metadata, etc)
-Don't use a signed number if negative values don't make sense in that context
-Include versioning if something needs to work across versions
-Choose consistent scemantics for data encoding (and anything else you can)
All of this will make it easier for you, too. Focus on reducing internal code reuse, maximizing external code reuse, and simplifying things.
If Notch was trying to write an API, then sure. If he's trying to write fun games (which he is) then you are dead wrong. Not all code is written for the same purposes.
Most code, even more for a sandbox game, is made to be modified.
If it's not well made, it will be hard to modify it, you will add mistakes to mistakes and it will become harder to develop. The last Minecraft update is probably a sign of that (they remade everything if I understood correctly).
Terraria is currently a good example to compare with the situation of Minecraft. I don't know how both is made (except some stuff that my friends told me about Minecraft) but all I know is that most Terraria player made fun of Minecraft in the last big updates because they had SO MUCH content added when Minecraft had nearly nothing more.
If he's trying to write fun games that won't be updated, yeah, it's fine. Except that it's not the goal of Minecraft (at least I hope it's not...).
Terraria is currently a good example to compare with the situation of Minecraft. I don't know how both is made (except some stuff that my friends told me about Minecraft) but all I know is that most Terraria player made fun of Minecraft in the last big updates because they had SO MUCH content added when Minecraft had nearly nothing more.
If he's trying to write fun games that won't be updated, yeah, it's fine. Except that it's not the goal of Minecraft (at least I hope it's not...).
I'm hoping that one day, Minecraft gets completely open source and is ported away from Java. I've tried and failed to write a plugin for Bukkit and the whole ecosystem is horrible. When your modding toolkit involves importing craptons of JARs and decompiling the rest, something's really wrong.
To be fair, the difficulty of modding isn't necessary directly correlated with the fact that it was written in Java.
If it wasn't written in Java it would be even harder to mod, with them not officially supporting it. The only reason it's working so well now is because Java can be decompiled rather easily.
>He makes very basic mistakes very frequently and his core designs are flawed.
In the interest of my own self-improvement, could you elaborate a bit on this?
EDIT: I see that you've already talked about this a little bit, but if you'd like to elaborate further I'd be OK with that.
In the interest of my own self-improvement, could you elaborate a bit on this?
EDIT: I see that you've already talked about this a little bit, but if you'd like to elaborate further I'd be OK with that.
I remember liking the AI - all these different objects, complex, emergent behaviours, expressed usually in less than 40 lines of code. Clean, effective, with great bang to buck ratio.
If modding was high on their list of priorities, I'm pretty sure they would get it right.
If modding was high on their list of priorities, I'm pretty sure they would get it right.
This line from the readme file of his Craft.Net project neatly sums up Sir_Cmpwn's presence within the notchverse:
"Minecraft is not officially affiliated with Craft.Net."
"Minecraft is not officially affiliated with Craft.Net."
>He is a terrible, terrible coder.
Oh come on.
Oh come on.
Notch is a very bad programmer
I despise this sort of single-dimension haughty evaluation of programming "goodness": It is garbage, and is the dismissive grenades that a particular type of maintenance programmer tosses to feel better about themselves as they try to feed the family with sloppy seconds.
I single out maintenance programmers because there is a stark difference between creating something out of nothing, and being the guy who looks at that something and -- with all that is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident -- can say "Oh clearly you should have A->E->Z: What a dummy!".
All novel works can be improved in countless ways, iteratively. This is a given of software development, and the fear of having to go through this inevitable process has stopped most projects before they've ever begun.
"His failures have tangible reprecussions that have long plagued the Minecraft hacking community and Mojang itself."
There is so much irony in this statement. Do you even realize?
I despise this sort of single-dimension haughty evaluation of programming "goodness": It is garbage, and is the dismissive grenades that a particular type of maintenance programmer tosses to feel better about themselves as they try to feed the family with sloppy seconds.
I single out maintenance programmers because there is a stark difference between creating something out of nothing, and being the guy who looks at that something and -- with all that is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident -- can say "Oh clearly you should have A->E->Z: What a dummy!".
All novel works can be improved in countless ways, iteratively. This is a given of software development, and the fear of having to go through this inevitable process has stopped most projects before they've ever begun.
"His failures have tangible reprecussions that have long plagued the Minecraft hacking community and Mojang itself."
There is so much irony in this statement. Do you even realize?
Agreed. A programmer maintaining a new project is going to feel frustrated when the application cannot be easily extended in a way that they expect, but the original author should be forgiven for not predicting every possible future permutation of their existing code base. The best design decision might seem obvious from the maintainer's perspective, but given 100 different maintainers, you'll end up with 200 different solutions, half of which will make the original application seem ridiculous when framed in the context of a massive rewrite that takes into account every business decision that time and experience has yielded since the start of the project.
Further, there are times when a good programmer must deliberately exclude forward thinking solutions because a non-functioning product precludes a successful business. Yes, it should still be a secure solution. Yes, a TODO label may be warranted, but a surefire way to get yourself labeled as a bad programmer is to spend weeks working out "future proof" solutions while the competition is shipping an application that can be successfully executed.
Further, there are times when a good programmer must deliberately exclude forward thinking solutions because a non-functioning product precludes a successful business. Yes, it should still be a secure solution. Yes, a TODO label may be warranted, but a surefire way to get yourself labeled as a bad programmer is to spend weeks working out "future proof" solutions while the competition is shipping an application that can be successfully executed.
Though there are some good points here, my experience has been that this "just get it done" above all else principle has sunk just as many projects as it has launched.
Getting it done is a bare necessity of a good programmer, but what separates the mediocre programmer from a good programmer is whether they get it done in a more maintainable fashion.
It is completely ridiculous to say as long as one can get a product launched, they are a good programmer, because you're likely praising a group, half of whom are good programmers, and half of whom are sinking the product more and more over time. This is a common happening I see with praise of engineers from a management perspective, and why so often companies sink without knowing where exactly they went wrong.
You can judge if a programmer is good, not by tearing apart and poking at the mistakes they made in a new project, but if they proceeded to code using strong abstractions and decoupled code. The easiest programmers to fire are the ones who don't ship, and the programmers that tend to be the costliest to a business are the ones who ship crap code.
Getting it done is a bare necessity of a good programmer, but what separates the mediocre programmer from a good programmer is whether they get it done in a more maintainable fashion.
It is completely ridiculous to say as long as one can get a product launched, they are a good programmer, because you're likely praising a group, half of whom are good programmers, and half of whom are sinking the product more and more over time. This is a common happening I see with praise of engineers from a management perspective, and why so often companies sink without knowing where exactly they went wrong.
You can judge if a programmer is good, not by tearing apart and poking at the mistakes they made in a new project, but if they proceeded to code using strong abstractions and decoupled code. The easiest programmers to fire are the ones who don't ship, and the programmers that tend to be the costliest to a business are the ones who ship crap code.
I didn't say above all else, but I take your point. Of course, this is a balancing act, and I suspect we're both facing some selection bias, but I have to disagree that creating maintainable code is necessary for being described as a good programmer. At the end of the day, all programs are maintainable, as long as the source can be read and understood by a programmer. There is a huge advantage to having a well designed application structure, but there is no replacement for an application that meets its functional specification.
I would replace your "Getting it done is a bare necessity of a good programmer, but what separates the mediocre programmer from a good programmer is whether they get it done in a more maintainable fashion." with, "Getting it done is a bare necessity of a good programmer, but what separates the great programmer from a transcendent programmer is whether they get it done in a more maintainable fashion."
If you're looking for new opportunities I have openings on my team.
People who complain about crap code usually aren't complaining about this.
Obviously no-one can see the future. The problem isn't when code can't be easily extended, the problem is when code is easily broken.
Obviously no-one can see the future. The problem isn't when code can't be easily extended, the problem is when code is easily broken.
The problem isn't when code can't be easily extended, the problem is when code is easily broken.
I'm not sure if there is much of a distinction there. I can extend your code with very little effort if I'm permitted to break it in the process.
I'm not sure if there is much of a distinction there. I can extend your code with very little effort if I'm permitted to break it in the process.
Well if we're singling out maintenance programmers, lets also talk about programmers who use "maintenance" as a dirty word. They tend to be the type to vomit out whatever immediately comes to their head and ship when it just barely works, with no thought or consideration for maintainability. Because, hey, they're going to move on to their next project anyway, and "getting things done" in the short term is far more important than little details making sure your project, and your business by extension, is sustainable in the long term. Thats someone else's' problem.
There is a middle area here, where one doesn't worry about perfect code, but still takes a moment to consider design. However, you don't hear that often on HN, because it loves a good "Such coding, so productive!" circle-jerk. The reality is that a lot of "get it done fast" programmers could use a maintenance project or two, and develop the habit of actually thinking about what they write.
But no, lets hate on maintenance programmers and people who want some thoughtfulness in their development. They're just not agile enough. eye roll
There is a middle area here, where one doesn't worry about perfect code, but still takes a moment to consider design. However, you don't hear that often on HN, because it loves a good "Such coding, so productive!" circle-jerk. The reality is that a lot of "get it done fast" programmers could use a maintenance project or two, and develop the habit of actually thinking about what they write.
But no, lets hate on maintenance programmers and people who want some thoughtfulness in their development. They're just not agile enough. eye roll
There is a middle area here, where one doesn't worry about perfect code, but still takes a moment to consider design.
Who said otherwise? The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted. Yet he did build a large product from nothing, that has provided millions of hours of enjoyment to users. A product that built a community and a company. To see him disparaged like that is just so laughably typical.
Everyone is the world's greatest programmer in their own imagination.
And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.
Who said otherwise? The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted. Yet he did build a large product from nothing, that has provided millions of hours of enjoyment to users. A product that built a community and a company. To see him disparaged like that is just so laughably typical.
Everyone is the world's greatest programmer in their own imagination.
And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.
>Who said otherwise?
Apparently a lot of HN posters. Looking at the siblings, you see the exact circle-jerk I criticized: "Only launching matters. Builders are so much smarter and more talented than maintainers. Code quality is a secondary concern that can be addressed later." And lets be honest, your comment itself did not really hint at any sort of balance -- it was highly insulting to anyone not writing code from scratch. "... tosses to feel better about themselves as they try to feed the family with sloppy seconds." Really? REALLY? That's horribly dismissive to anyone who has to work in an existing code base. Its shamefully dismissive.
> The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted.
Said poster did not make the claim solely on the lack of mod-ability, but also on things like poor use of OpenGL APIs and extreme duplication of code. Some point between version 0.1 and release, one should take a step back, refactor, and clean up with an eye for maintainability.
Also, the fact that something is version 0.1 is not really an excuse for things like writing code that duplicates functionality. Its entirely possible to write an initial version that has passable code quality -- I've done it many times (and had coworkers comment on how easy it was to maintain). You just have to keep in mind that if you're writing throwaway code, it must be thrown away, and if that's not acceptable that you need to spend a little extra time on a maintaining a minimum level of quality.
> And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.
Said programmers are often interested in improving the quality of the code-base. Your disparagement is misplaced. They are the people that take an unmaintainable mess and mold it into a reliable system. But of course, since the work" is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident" that's work that anybody can do. And that statement is not horribly dismissing and insulting at all. Right.
I've had more sleepless nights due to "special snowflake" developers than the maintenance programmers you disparage.
Apparently a lot of HN posters. Looking at the siblings, you see the exact circle-jerk I criticized: "Only launching matters. Builders are so much smarter and more talented than maintainers. Code quality is a secondary concern that can be addressed later." And lets be honest, your comment itself did not really hint at any sort of balance -- it was highly insulting to anyone not writing code from scratch. "... tosses to feel better about themselves as they try to feed the family with sloppy seconds." Really? REALLY? That's horribly dismissive to anyone who has to work in an existing code base. Its shamefully dismissive.
> The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted.
Said poster did not make the claim solely on the lack of mod-ability, but also on things like poor use of OpenGL APIs and extreme duplication of code. Some point between version 0.1 and release, one should take a step back, refactor, and clean up with an eye for maintainability.
Also, the fact that something is version 0.1 is not really an excuse for things like writing code that duplicates functionality. Its entirely possible to write an initial version that has passable code quality -- I've done it many times (and had coworkers comment on how easy it was to maintain). You just have to keep in mind that if you're writing throwaway code, it must be thrown away, and if that's not acceptable that you need to spend a little extra time on a maintaining a minimum level of quality.
> And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.
Said programmers are often interested in improving the quality of the code-base. Your disparagement is misplaced. They are the people that take an unmaintainable mess and mold it into a reliable system. But of course, since the work" is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident" that's work that anybody can do. And that statement is not horribly dismissing and insulting at all. Right.
I've had more sleepless nights due to "special snowflake" developers than the maintenance programmers you disparage.
>Notch is a very bad programmer
If his goal is to create code that other programs will love to read, then maybe he is terrible.
If his goal is to create software that millions of people will enjoy, then he is amazing.
My guess is that he would describe his goal as the latter. Maybe his goal is different from yours.
If his goal is to create code that other programs will love to read, then maybe he is terrible.
If his goal is to create software that millions of people will enjoy, then he is amazing.
My guess is that he would describe his goal as the latter. Maybe his goal is different from yours.
Note that the bad programmer bit was a quote of the post I replied to, which I then thoroughly disagreed with. It was not a statement of fact on my part.
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.
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.
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.
Agreed, I don't have much to add, I've been on both sides of the fence. Your comments hit it exactly, conjuring something from nothing takes amazing talent. Taking that and making it better is arduous but there is a path there, it's not easy I know, but the path is there.
[deleted]
Business people would think Notch is a good programmer, but what do they know. I'm commenting because I want a link back to this discussion. I wish HN made it easier to find old good stories that I didn't comment on, but I'm not bent out of shape about it. Anyway, programming is strange because you've got the output and the instructions for producing it, and sometimes one can be good while the other is not as good. Anyway blah blah mod me down. I find it unlikely that Notch is purely a bad programmer.
He probably uses multiple monitors and only streams one (at least he did when I watched). So he might be looking up documentation on another screen.
I don't want to criticise the blub essay too much because there were some valid points in there. But in fairness as soon as I read it I thought of John Carmack. He uses C++. Given that the perspective of the essay is Lisp then if C++ isn't a blub I don't know what is.
But John Carmack is really productive.
Also he doesn't use vi or emacs. He uses an IDE! He used it even before it had any bells or whistles at all. (He also uses Windows!)
So is it because he's a genius and he does it in spite of using blub? Or is it because:
"Peter Norvig here. [....] In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice."
As for Notch. He uses Java and wait for it..
Eclipse!
But John Carmack is really productive.
Also he doesn't use vi or emacs. He uses an IDE! He used it even before it had any bells or whistles at all. (He also uses Windows!)
So is it because he's a genius and he does it in spite of using blub? Or is it because:
"Peter Norvig here. [....] In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice."
As for Notch. He uses Java and wait for it..
Eclipse!
For the confused, blub is the hypothetical language from pg's essay Beating the Averages:
http://www.paulgraham.com/avg.html
http://www.paulgraham.com/avg.html
Well, it's just an essay. Not something even remotely proven.
A computer SCIENTIST should scorn the use of the "blub" notion as something that holds a priori.
A computer SCIENTIST should scorn the use of the "blub" notion as something that holds a priori.
Not to mention that it's a very opinionated, elitist, offensive essay. How calling people "Blub developers" can be taken serious and not as elitist posturing is beyond me.
Well, yes, I used an IDE in the Turbo Pascal/Turbo C++ era from which John Carmack comes
DJGPP and RHIDE as well.
It was not common to use a separate editor apart from the "programming environment"
DJGPP and RHIDE as well.
It was not common to use a separate editor apart from the "programming environment"
So, why do you think he went with Dart? You're kind of telling us that what he chose didn't matter, but he must have had his reasons for jumping into a new technology.
We probably can't infer much from Notch's use of Dart beyond the fact that the technology is baked enough for real world use. I guess someone could always ask Notch for his opinion on Dart, after he's used it for a few more weeks.
We probably can't infer much from Notch's use of Dart beyond the fact that the technology is baked enough for real world use. I guess someone could always ask Notch for his opinion on Dart, after he's used it for a few more weeks.
The primary reason no doubt is because it enables him to deliver over the web. There are other languages for this but I have no doubt that in Notch's case I have no doubt its because he feels he can be productive in it and that is because it is similar to what he knows. He was asked on reddit why he chose java and he had a really simple answer:
"Because I know it"
Given the massive language debates that are out there I thought this was pretty refreshing and indicative of a successful person whose focus is elsewhere.
Myself I think Dart is a massive improvement over java and I could probably debate it all day. But then again I'm not as successful as Notch, maybe I should ease up on the debating.
"Because I know it"
Given the massive language debates that are out there I thought this was pretty refreshing and indicative of a successful person whose focus is elsewhere.
Myself I think Dart is a massive improvement over java and I could probably debate it all day. But then again I'm not as successful as Notch, maybe I should ease up on the debating.
> why do you think he went with Dart?
I'd guess because it offers more structure than JavaScript. You have classes, packages, and you can just `import` things. You also get proper tooling. You can also overload operators, which is kinda nice for games (vector math).
He wrote a lot of Java and AS3. Dart is very similar. Just a bit terser and a bit "scriptier".
I'd guess because it offers more structure than JavaScript. You have classes, packages, and you can just `import` things. You also get proper tooling. You can also overload operators, which is kinda nice for games (vector math).
He wrote a lot of Java and AS3. Dart is very similar. Just a bit terser and a bit "scriptier".
Dart is very close to Java but with a number of language features altered to be closer to matching web APIs and for easier trans-compilation to Javascript. So Notch using Dart isn't very unlikely if he already liked Java.
Maybe he just did it in Dart for fun.
So you claim he learnt a language and a new technology quickly, solely because he uses an IDE? I doubt so...
The Norvig quote sounds more reasonable.
The Norvig quote sounds more reasonable.
Not at all. What I am saying is that it clearly doesn't matter. Some people are productive in vim. Some people are productive in eclipse and java (even though they are incredibly un-hip and won't score you any points at conferences (with your dell laptop running windows!). But like the article says really productive people tend to be focused on the product.
For John Carmack's take on the matter, see:
John Carmack: "Thoughts on Haskell" https://news.ycombinator.com/item?id=6278047
John Carmack: "Thoughts on Haskell" https://news.ycombinator.com/item?id=6278047
I know he tried Haskell. I agree with him on a lot of points he made there. But:
1. He investigated it long after he had already been successful using something more mainstream. If you are starting something up then I think it would be good advice to use what you know and get on with it. If that's Haskell then good for you. If its not then don't waste your time. Get on with the product.
2. Even then he didn't finish rebuilding his game because he was drawn back to his day to day work. The guy is just product focused.
1. He investigated it long after he had already been successful using something more mainstream. If you are starting something up then I think it would be good advice to use what you know and get on with it. If that's Haskell then good for you. If its not then don't waste your time. Get on with the product.
2. Even then he didn't finish rebuilding his game because he was drawn back to his day to day work. The guy is just product focused.
I really, really want to see Carmack's Haskell. That would be a super fun read.
This is less a matter of only writing what's needed, than having written the same thing in lots of different variations, until you know the essence of the problem, and which are the most elegant paths to take.
A beginner in any discipline can't accomplish so much with so little effort. And it's wrong for a beginner to start out trying to do so, IMO; it's too easy to get discouraged if you think from the start that you should be able to do it with so little effort.
Writing your first game loop is a bit clunky, trying to fit it in with whatever framework / language / API is hosting you, and the sequencing / setup of everything. The tenth time, you know exactly what you want from an API, and have a good idea of what bits you need to build to get the effect you need. The hundredth time, you can look at a new API / framework and see the what it enables you to build most efficiently, and you can let that inform the design of what you create. Then, very little effort is needed. But that's only because you've already done the "really complicated system for loading meshes and shaders" or some equivalent in the past.
It's hard to get really efficient without having done things the inefficient way to begin with, if not earlier in the current project, then in previous projects.
A beginner in any discipline can't accomplish so much with so little effort. And it's wrong for a beginner to start out trying to do so, IMO; it's too easy to get discouraged if you think from the start that you should be able to do it with so little effort.
Writing your first game loop is a bit clunky, trying to fit it in with whatever framework / language / API is hosting you, and the sequencing / setup of everything. The tenth time, you know exactly what you want from an API, and have a good idea of what bits you need to build to get the effect you need. The hundredth time, you can look at a new API / framework and see the what it enables you to build most efficiently, and you can let that inform the design of what you create. Then, very little effort is needed. But that's only because you've already done the "really complicated system for loading meshes and shaders" or some equivalent in the past.
It's hard to get really efficient without having done things the inefficient way to begin with, if not earlier in the current project, then in previous projects.
I don't know why the blog poster is impressed. This is Notch's domain, writing code of this ilk. He's probably got over a decade or more dealing with games and graphics, the hard part is dealing with a API that's unfamiliar.
(I have ported familiar code from a Python script to a C# desktop application in similar time, the hard part was dealing with various .NET quirks.)
(I have ported familiar code from a Python script to a C# desktop application in similar time, the hard part was dealing with various .NET quirks.)
"Just saw a nerd flamewar debating if I'm a bad programmer. I'm self-taught, prefer working along, and program for fun. Don't learn from me."
https://twitter.com/notch/status/408011329237049344
Gotta feel sorry for him, he didnt ask to be or not to be an idol, must be disconcerting to have a bunch of random strangers talking about how good you are.
https://twitter.com/notch/status/408011329237049344
Gotta feel sorry for him, he didnt ask to be or not to be an idol, must be disconcerting to have a bunch of random strangers talking about how good you are.
I agree with his main point, but to be honest, on most of the games I've worked on I've had something playable very fast (1 or 2 weeks)... Its all the details beyond basic gameplay that take all the time and really make delivering a game hard.
Agree completely. Basic little 3D engine is easy to do because it's been done so many times before. Any of the complexities are well known and it's not like Notch hasn't made a similar block based 3d engine before. The author talks about not making an engine and just making a game.. but there's no game here yet?
The hard part is always the details and the new stuff.
The hard part is always the details and the new stuff.
Now I feel bad for slowing up my current pet project by getting bogged down writing polygon collision detection when axis aligned bounding boxes would have done for prototyping. (I'm not as quick as Notch!)
To be fair, Notch did just spend a few years of his life thinking entirely in terms of axis-aligned boxes. ;-)
>> (I'm not as quick as Notch!)
You probably haven't been writing games as long, or written as many, or entered as many game contests/competitions as he has.
It'd probably take him a while to write a database or word processor since he likely doesn't have the domain knowledge and experience.
You probably haven't been writing games as long, or written as many, or entered as many game contests/competitions as he has.
It'd probably take him a while to write a database or word processor since he likely doesn't have the domain knowledge and experience.
My understanding is that usually you want both because AABB is good for broad-phase because it's so quick then true polygon collision can be done in a narrow phase.
Absolutely.
Interesting. I've recently set aside a ThreeJS project. I'm not a math wiz but even with Three, you still need some idea about matricies, vectors and even quaternions. The way you're "supposed" to do collision detection with Three is with raycasting, so more fun with vectors and matricies. I thought I had scaled down enough other things for prototyping but perhaps there was more room than what I thought.
You might want to take a look at our product, PlayCanvas. We've tried to do all the maths for you, so you don't have to. :-)
Well, this can actually have a pretty significant effect on the feel of the game so depending on what kind of game you were prototyping, it might be worth it (though, your better off hardcoding a few cases of SAT than trying to get it working completely generally in a prototype).
How would one hard code SAT cases? Just curious I've got the general code working now.
Dart syntax is very similar to Java in many respects, but simpler, so is it really any surprise that Notch would try out Dart, given his history with Java?
People like what's familiar. One of the reasons Java took off is because of it's similarity to other ALGOL type languages. C/C++ programmers could learn Java quickly for example.
People like what's familiar. One of the reasons Java took off is because of it's similarity to other ALGOL type languages. C/C++ programmers could learn Java quickly for example.
You know, I read Hacker News less and less precisely because the posts are so damn negative. For those debating whether Notch is good or bad, I suggest reading every article from programming in the 21st century.[1]
[1] http://prog21.dadgum.com/archives.html
[1] http://prog21.dadgum.com/archives.html
>Don't build an engine that you will someday build a game on top of, because you will never get past step one.
I have several still-unfinished Game Maker apps which more or less died because I got so bogged down on the "engine". So yeah.
I have several still-unfinished Game Maker apps which more or less died because I got so bogged down on the "engine". So yeah.
I've thought about that a lot as I also have the same tendency. What I've concluded (for me at least) is that it's just EASIER to get started writing an engine than to write a good game, so you end up working on the engine out of intellectual curiosity and because it's the path of least resistance.
(I've never really gotten far writing a 'from-scratch' engine here but I'm also thinking of things like integrating a scripting system into an existing engine, which is something I've done before).
With an engine, you don't start with such a nebulous spec. You know, for example, the various pieces that your engine will need and it's easy to get started. You can say "well I need an asset importer", "I need to integrate a scripting system for gameplay", "I need some kind of rendering pipeline", etc. These are generally well-defined things.
With a game, well, what is there? You start off with the question "what is a fun game idea?" but in comparison it's so free-range. The ideas of where to head next just don't come as easily. Not to mention a lot of the non-programmer things that need doing - drawing the graphics, writing the music, writing the dialog if appropriate, etc. These can be intimidating things to attempt to do.
(I've never really gotten far writing a 'from-scratch' engine here but I'm also thinking of things like integrating a scripting system into an existing engine, which is something I've done before).
With an engine, you don't start with such a nebulous spec. You know, for example, the various pieces that your engine will need and it's easy to get started. You can say "well I need an asset importer", "I need to integrate a scripting system for gameplay", "I need some kind of rendering pipeline", etc. These are generally well-defined things.
With a game, well, what is there? You start off with the question "what is a fun game idea?" but in comparison it's so free-range. The ideas of where to head next just don't come as easily. Not to mention a lot of the non-programmer things that need doing - drawing the graphics, writing the music, writing the dialog if appropriate, etc. These can be intimidating things to attempt to do.
In this case, I see an analogy with the whole "Do it manually with a few customers" advice for startups that pops up from time-to-time. You write the damn code from scratch and see what gameplay is interesting, then you can write tools within that domain.
Now that html5 is a thing that would definitely be doable.
Ultima Underworld continues to blow my mind. Happy 22nd birthday.
ahha, thanks for this! I'm really pleased to see Notch doing what I always thought he did best - messing around with wee projects and coming out with joyous little playthings.
Minecraft just got a little bigger than I imagine he was interested in playing with.
Minecraft just got a little bigger than I imagine he was interested in playing with.
Where would a noob to this kind of stuff start? I'd like to draw a rectangle to the screen. :)
I found NeHe's tutorials to be easy to follow especially since code that's ready to compile is provided at the end of each lesson:
http://nehe.gamedev.net/
Most of them focus on OpenGL for windows.
I just searched and found this WebGL tutorial which says it's based on NeHe's so it's hopefully good: http://learningwebgl.com/blog/?p=28
Disclaimer: I'm not a game developer and I barely dabble in the 3D world, so take my links with a huge grain of salt :)
Most of them focus on OpenGL for windows.
I just searched and found this WebGL tutorial which says it's based on NeHe's so it's hopefully good: http://learningwebgl.com/blog/?p=28
Disclaimer: I'm not a game developer and I barely dabble in the 3D world, so take my links with a huge grain of salt :)
Stay away from NeHe tutorials, they are badly written and really old. Pretty much everything they cover is deprecated and done in otherwise old fashioned ways.
This is a big problem with OpenGL tutorials in general, a lot of them cover old stuff that shouldn't be used any more.
The entire OpenGL fixed function pipeline is deprecated, replaced by programmable shader pipeline. It's a lot more work to get simple stuff done with shaders but it pays off in the end.
If you're looking to write a game (and not an engine) it may be a good idea to get an engine and not write "raw" OpenGL at all.
This is a big problem with OpenGL tutorials in general, a lot of them cover old stuff that shouldn't be used any more.
The entire OpenGL fixed function pipeline is deprecated, replaced by programmable shader pipeline. It's a lot more work to get simple stuff done with shaders but it pays off in the end.
If you're looking to write a game (and not an engine) it may be a good idea to get an engine and not write "raw" OpenGL at all.
If all you're looking to do is simple stuff (like get a rectangle on the screen), shaders are not required, correct?
You do need shaders for pretty much everything.
But if you only want to draw a rectangle with a solid color, you can do that using the scissor test and clearing "the screen". But that's about all you can do without shaders.
But if you only want to draw a rectangle with a solid color, you can do that using the scissor test and clearing "the screen". But that's about all you can do without shaders.
They are, unless you use old deprecated versions of OpenGL.
So the simplest program using the simplest shader would use a pass-through shader that doesn't modify the inputs?
My understanding is that the NeHe tutorials are archaic and do not properly reflect modern OpenGL usage. Iirc the legacy constructs used in NeHe have been dropped in mobile implementations of OGL.
http://www.arcsynthesis.org/gltut/
That's an excellent resource for modern OpenGL, I have links for a few others at home that I can't recall off the top of my head.
http://open.gl teaches the basics of using OpenGL to develop modern graphics applications.
Here:
OpenGL is a standard for hardware accelerated 3D graphics and it is inherently complex because of that. If you just want to do 2D do not bother with it.
[1] http://love2d.org/wiki/love.graphics.rectangle
Rectangle(100, 100, 400, 400)
OpenGL is a standard for hardware accelerated 3D graphics and it is inherently complex because of that. If you just want to do 2D do not bother with it.
[1] http://love2d.org/wiki/love.graphics.rectangle
If you're not feeling ready for 3D graphics, Khan Academy has a neat set of interactive lessons where you learn to draw and animate basic shapes using the HTML5 Canvas API (Javascript):
https://www.khanacademy.org/cs/programming
https://www.khanacademy.org/cs/programming
http://pragprog.com/book/csjava/3d-game-programming-for-kids
(It's not literally just for kids.)
(It's not literally just for kids.)
Udacity has a nice looking WebGL intro course:
https://www.udacity.com/course/cs291
https://www.udacity.com/course/cs291
[deleted]
All that stuff sounds so cool, but I have no idea of how I would implement it in code. One of these days I'll learn 3D graphics programming.
I recommend http://www.amazon.com/Math-Primer-Graphics-Development-Editi... when you're ready
This last point is rather unlikely I think. I spent more than one or two weeks worth of time watching the various screencasts you can find on twitch.tv of Notch coding (I find it highly relaxing).
He usually writes everything from scratch. He doesn't copy & paste from other projects because he's experienced enough to pretty much to just write down the code he wants. He also hardly ever looks up documentation (besides using autocomplete for library methods). Also, he practically doesn't write any code comments in these toy projects.
He's extremely productive in my opinion, and can easily spend hours at a time coding. He does a lot of play testing and small gameplay fixes, even at early stages.
I've learned a whole lot just watching these videos. For instance that we don't have the same taste in music :-) But thank god for twitch.tv.