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. 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.
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.
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.
> 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.
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.
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.
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.
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?
There seems to be some really personal stuff in there. Isn't this a huge violation of privacy or am I missing something? Any difference between wikileaks making something like this public and the British tabloids hacking peoples phones?
I find news about Nokia interesting, so thank you for posting this, but what is up with the tone of the article? It feels more like a youtube-comment than news.
When I was using the free version a while back you could mute and then hit play again if you didn't want to listen to the ads. Don't know if that still works.
I never liked app engine. To me it seemed like you have to lock yourself into google as a vendor because your application has to be designed for app engine.
Relying on a service hosted by a third party is fundamentally different. Nobody, not even Torvalds or van Rossum, could throw a switch and shut down your Linux boxes or your Python interpreter, so any needed migration to an incompatible system can happen at your convenience.
This argument come up often, but makes no sense as it ignores the fact that software rots. I cannot keep running Python 2.x indefinitely without maintenance because knowledge of its flaws will slowly escalate until it is a security risk to keep operating it. If this doesn't happen to the tool itself, then it will happen to one of its critical dependencies, like an old version of SQLite it requires, or the previous generation of OpenSSL.
Projects like Python, that simply don't care about maintenance costs of things that rely on it are simply being naive: they are pretty much saying "yes, you invested a ton of time into building code for Python 2; but those days are over: we, at some random shifting date in the future, are going to drop support for this, so if you want to get security updates to it, or hell: even upgrade to a newer version of Ubuntu with minimal pain, you now need to drop everything you are doing and reread all of that code to update it for our seemingly arbitrary changes, retesting the whole thing in the hope of finding any regressions you introduce; that, or go off-grid, maintaining this code and related infrastructure yourself". Seriously?
Imagine if Linux 2.6.100 decided to drop support for socket(), because it is (truly) a painful API to support multiple transport layers with; /even if/ they said "dude, you can still just type socket_old, and we have a crazy preprocessor that hopefuly, if your code is obvious enough, does this search and replace for you", would you still be able to take their dedication to being a platform seriously?
There's a big difference between flicking a switch to turn off python 2, and slowly deprecating it over a period of years to a new (better) system with well doucmented differences and a clear migration path.
Python 3 started in 2006 (http://www.python.org/dev/peps/pep-3000/), if you've managed to stave off software rot for the last 5 years, I'm sure you can take the extra step to support python 3.
Upgrading to Python 3 is simply not an option for me at this time as I am depending on libraries that still require me to be using Python 2: Python 2->3 is an "all or nothing" endeavor due to the horrendously incompatible way they have handled this transition. I mean: the fact that five years /have/ passed and Python 3 is still a silly pipe dream for almost all users of Python should tell you something about how poorly this was done.
Now, of course, to the extent to which I can, I've used Python 2.7's "from __future__ import" mechanism to pull as many features as I can from Python 3 to help transition, but even that has been stupidly painful: importing Python 3's gratuitously different division operator (which you can't automatically process and convert as you need to know whether the denominator is a float or an integer) was very very VERY painful on all of my careful image processing code (suddenly getting, or not getting, half pixel offsets and widths in various places).
Meanwhile, I don't see any benefit at all to me making these changes... requiring "as" instead of a comma for exceptions?... /removing/ the 2.7 ability to mark a string constant with a b-prefix, forcing an ambiguity between 2.6 str and 3.0 bytes? Are you seriously telling me that these were so important as to cause there to be a five year rift in the language community?
In all seriousness, a better usage of my time (rather than messing around porting my 2.x code to 3.x code) would have been to make a patch to Python 3.x to let you "from __future__ import hindsight" to let you use Python 2.x syntax with the Python 3.x interpreter, at which point 99% of these incompatibilities would be irrelevant. Of course, hindsight /is/ 20/20: I can't go back in time and reinvest that time better; but, I certainly have learned my lesson about using Python.
> the fact that five years /have/ passed and Python 3 is still a silly pipe dream for almost all users of Python should tell you something about how poorly this was done.
So far, it has been just how it was meant to be. It was never the goal for Python 3 to be the default Python version by year 2011.
I work with Python 2.x on a regular basis. I have no cause to recommend Python 3.x at this point in the game. Depending on Ubuntu 12/13's choices , I may push my team towards moving away from Python altogether.
I don't see that the Python team really made the right choice here. I have no good transition path from 2 to 3 besides an intensive rewrite.
What matters is whether or not the new version is a realistic option for new projects. It is not. That can't be the goal and if it is, the goal is crap.
If you feel your company has the resources to take over maintenance of something like this, with the understanding that you will no longer be benefiting from the open source contributions from the community (as Python 3's VM has diverged quite rapidly, destroying a ton of projects like mod_python and Unladen Swallow), all I can say is: more power to you. However, continuing to build your empire on land we now all know to be quicksand, just so one day you have the fun job of maintaining the water table to keep your expensive buildings from sinking, seems like poor judgement.
In this case, you're not the only one building an empire on the quicksand (which by the way, was freely provided by voulenteers, which only make changes to the quicksand in an effort to _improve_ it).
The effort to keep the platform working to support your old castle will usually be shared with others, just like with the Debian project which keeps old software versions updated with backported security fixes for many, many years just so that you can sleep well each night.
This argument also never makes sense to me: I have never demanded that the Python developers change this mentality, I do not complain on their mailing lists, nor do I storm into their IRC servers demanding that they change either. And I certainly don't send them text messages at all times of the day, like thr users of my app do to me ;P.)
Instead, when there are discussions on business-oriented sites like Hacker News about what investing in technologies (like Google APIs, in this case), I make certain that people don't make flawed arguments about the cost tradeoffs involved in maintaining your own dependency chain, and it turns out that Python 2/3 is a great example of this (and one I didn't even bring up).
Unfortunately, bringing up personal stories of this tradeoff is going to come off as "whining", as you call it, to some people, but frankly that just comes off, to mr, as name calling. I think the Python 2/3 split is a great example of a particular area of quicksand that a smart businessman (which I apparently wasn't, I will add) will avoid, and I think that is an interesting idea to keep in mind ("what is the percentage chance that I will have to maintain this thing that is not my core business myself after a few years") whenever adopting a technology, new or old.
I understand that you don't mean to complain to open source projects, and that's good :)
It feels like whining to me mostly because these stories are often brought up, but rarely without any mention of the alternative: Without the wealth of open source software to build upon, we startups would either have to license the software/service or make it ourselves at great expense.
By saying that the "pro open source" argument makes no sense, you're implying that the risk exposure is more or less equivalent whether you depend on an open source stack or a proprietary web service. And to me, that's clearly wrong. There's a world of difference between someone killing your product at the flick of a switch and some piece of software becoming unmaintained a few years down the line.
Would you be a smarter businessman if you had chosen to build your software on a proprietary, well maintained programming language which would only run on Google App Engine or an Amazon web service? I certainly wouldn't think so. Still, a lot of people do something very similar, and they become surprised when they discover that the big companies don't run charities.
I'm guessing Digium would have liked it if the Skype protocol was open, _even_ if it was changing every 6 months), but it's not. Now they have to discontinue their Skype for Asterisk product because Skype changed their mind.
(To respond to your first comment for a second: I run open source projects that have tens of millions of users, so I know quite a bit about the feeling on the other side of that specific issue: those text messages I mentioned I get all the time are about bugs in something I distribute for free under the BSD license.)
You are now conflating "prorietary" with "charity", which is ironic at best, and seem to be disagreeing with my arhument not because you disagree with it's logic, but because you dislike some indirect ramification to a cause you believe in, which is sad. :(
Open Source is not some magic bullet that makes something fundamentally maintainable: it simply affects the cost of one option, which is accepting the lock in and operating the project yourself. 99% of the time it will be cheaper to take another alternative, like "migrate to another solution", which is certainly something you can do with a proprietary solution.
So no: I disagree with you; if you are choosing an open source project just because it is open source, you are a bad businessman. Example: if you chose mod_python for your web architecture today--a discontued (with prejudice: the sole remaining official maintainer hated it) project that I seem to be the only remaining user of and which (honestly, despite what I tell people) wasn't very good in the first place--over a proprietary alternative that actually had a working business model, like ASP.NET, solely because you could maintain the former yourself, that would /clearly/ be a very poor and highly costly decision for your company, and would easily allow a competitor to run circles around you on cost of development and maintenance. There may even be reasons why mod_python would be chosen over ASP.NET (such as a plausible, if painful, migration path to mod_wsgi combined with the now know to be incorrect preference of coding in Python ;P), but this one in specific is simply irrational.
As for Digium: an ecosystem (like Skype) is fundamentally different than a hosted API, and I'm confused as to why you feel it appropriate to compare them... I can replace Google Translate (an API I rely on and do not regret choosing), but I cannot replace Skype, even if the entire client were open source.
I think you should reread my post regarding "charities". I said that it's easy for people to mistake Google and other companies for charities because they provide so many free to use services.
I never said open source is a magic bullet for anything. My original point was simply that you cannot equate relying on a third-party API to relying on an open source project. There's a risk to both, but they're very different risks.
Even perpetually licensed proprietary software that you download and run yourself has the advantage that you yourself decide when you want to stop using it.
For instance, even if ASP.NET might be discontinued at some point as was VB6, nobody from Microsoft is going to come knocking on your door telling you that you need to shut down your webserver.
However, if you built your platform around Azure and used tons of services and libraries only available there, you'd have a huge problem the day the Microsoft decided to discontinue Azure or quadrupled the price.
Some APIs are easy to replace, and some are not. I brought up the Skype API because it's one that is not easy to replace. I agree that ecosystems are different, so maybe that was a bad comparison. A better example is relying on Google App Engine or Amazon EC2/EBS, or some other API that has no viable alternatives. More complex and differentiated APIs have higher value, but also higher risk since you can't move away from them as easily.
None of those are examples of vendor lock-in. Linux, sql, and python all come from many different vendors. If you were using, say, Debian, SQLite, and IronPython, and they all exploded, you could switch to alternatives pretty easily, I think.
Yes! What about spotify? Uploading your own music? Only playing songs that you already own? Bah! Spotify came before google, amazon and apple with what seems to be a better service..
