Notch, WebGL, Dart, and ramping up quickly
blog.tojicode.com
blog.tojicode.com
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.
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
I don't think just saying that makes it true
The kind of argument you're making is a very big fallacy.
Do you think Minecraft requires a complete rewrite to be maintainable?
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.
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.
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.
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)
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.
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.
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.
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.
Probably not much now, but Will Wright did code his early games (eg. Raid on Bungeling Bay , SimCity, etc).
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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)?
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.
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".
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."
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.
-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.
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.
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.
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.
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.)
Fuck, most of those I know couldn't get a basic CRUD app up and running in a week...
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!"
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!
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.
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...
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 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?
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:
You could also look at livecoding - they treat coding as a performance art. For example:
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.
By the way, why wouldn't you mention Bertrand Meyer or Niklaus Wirth?
"For every complex problem there's an answer that's clear, simple, and wrong."
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.
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.
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.
Mike Krieger got a degree in Symbolic Systems, which requires quite a few CS courses.
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.
Notch writes terrible code.
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.
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.
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...
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.
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.
Its a single-app code-base. Its not an API anyone consumes. Using get/set boilerplate really is just getting in 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?
Yes, but then you are also dead wrong.
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...
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.
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... ).
Replace majority with slice/share/percentage what have you.
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?
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Oh come on.
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.
> "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.
"Minecraft is not officially affiliated with Craft.Net."
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...).
what you would consider 'good code' wasn't Notch's goal, doesn't mean he isn't capable of it
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.
If modding was high on their list of priorities, I'm pretty sure they would get it right.
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.
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!
A computer SCIENTIST should scorn the use of the "blub" notion as something that holds a priori.
The Norvig quote sounds more reasonable.
John Carmack: "Thoughts on Haskell" https://news.ycombinator.com/item?id=6278047
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.
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.
"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.
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".
DJGPP and RHIDE as well.
It was not common to use a separate editor apart from the "programming environment"
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 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.)
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.
The hard part is always the details and the new stuff.
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.
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.
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 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.
Minecraft just got a little bigger than I imagine he was interested in playing with.
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 :)
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.
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.
(It's not literally just for kids.)
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.