Because nothing says less crashes like creating something completely new and untested than something that has crashed in the past but had the causes for the crash ironed out?

Aircraft crash anyway, there was a US harrier crash a month or two back and that aircraft was fighting in the Falklands in 82. If a platform that mature still has the odd issue then what makes you think a brand new untested platform is magically not going to crash?

Isn't the proof in the pudding? Given that gameplay sunk after Carmack became id's only remaining big name developer I'd say that's evidence enough.

"I said data. An anecdote is not data."

Yes it is, but that's besides the point, because don't worry, I know what you meant, you meant that an anecdote isn't as important a piece of data in your view, as TIOBE.

But here's the problem, TIOBE's methodology is so less than useless that I'm not sure it is better than an anecdote. Go read how they figure out their rankings - they take results from pages where content is mostly user generated and weight the result based on the amount of traffic that site gets. This means that user generated content sites like Wikipedia, and Blogger are being used to determine language popularity such that you can massively boost the ranking of a low down language by spuriously creating blogs and Wikipedia entries so forth including mention of it. There are many problems with this alone including the fact that they're reliant on the quality of the search functionality of the site in question to help with the weightings and we all know how pointless even Google's search results rapidly decline to after only a couple of pages.

It then gets worse. They apply arbitrary exemptions, they for example preclude Objective-C from searches on C to ensure it doesn't pollute the results but they don't filter out things like C sharp, meaning there are many thousands, possibly millions of results about C# polluting the rankings for C. They try and also give arbitrary confidence ratings, but the methodology for determining these seems to be completely made up and unpublished.

"There's well over a million apps on the iOS app store. The overwhelming proportion of which use Obj-C."

Most apps seem to get written using things like C# (i.e. in Unity, or MonoGame) or Javascript and HTML5 in tools like PhoneGap. The amount of native development on both iOS and Android is an absolute minority of all development.

When someone points to TIOBE to try and back up a claim you might as well replace "TIOBE" with "The Daily Mail" or "Fox News" or "The Register" because they're all equally full of shit.

This index actually looks pretty decent and quite realistic. It's based on stats that, unlike TIOBE, don't lie (at least not quite so much) like job listings - i.e. what companies are actually hiring for, in other words, what business is really actually using, an actually useful metric because most people looking at such rankings want to know popularity for the purpose of employment. I wont say it mirrors exactly my experience and view of the job market, but also I recognise that my experience is always going to be much more localised than a global study. I know Python is popular but I find it odd to see it above C#, however I guess there's every possibility it's used more prominently in other countries and cities so I don't think the ranking's results are far outside the realm of possibility.

It's certainly a much more realistic index than TIOBE, there's absolutely no doubt about that whatsoever - it far better mirrors reality for those of us working in the field. TIOBE isn't really much better than just outright making it up.

Don't tell someone you've proved conclusively they don't know what they're talking about when you clearly have not the slightest idea as to what tools and technologies are used for the bulk of mobile development. Even with the popularity of iOS and the vast number of apps it's app store has, much of it is still not written in Objective C regardless.

I'm just saying I'm not willing to debate with someone who stoops to the level of misrepresenting data. If you have to do that it's obvious you're not interested in an honest argument but are just a zealot with a one track mind who can't accept science, objectivity, and rationality. There's no logic to your arbitrary pre-1950/post-1950 divide, that's neither the start or the end of the industrial revolution, it's just an arbitrary point you've selected because you're attempting to take things out of context because that's the only way you can make the argument work in your favour. You can't argue based on the long term trends that aren't arbitrary because they do not fit your predetermined world view.

Trying to argue with a zealot like yourself who isn't interested in fact but merely their own twisted denialist fantasy is a waste of time.

I think the article misses the way modern economies work too. It doesn't matter if it's profitable, shareholders nowadays want to see increasing profits year on year.

You don't need millions of people to boycott it so that the production makes a loss, you only need thousands like yourself and I that mean it makes less money than it has in previous years.

If there's no profit growth, investors will start to notice and start asking questions and demanding a change in direction.

So yes, absolutely boycott, you can make a different, you don't need everyone to boycott, just enough to give up on it each year that it suffers declining sales.

Someone who so blatantly misunderstands data cannot in any way be called a scientist. Given that you failed in your argument right at the start I think it's at the point where it's clear you're at a dead end now.

I think the problem is that there's a thin line between where people call it a refactor and where you call it a rewrite. I don't think anyone actually does a literal complete rewrite where they replace every single line of code by manually retyping it out. If a refactor could be classed as modularising everything, and then rewriting each module, then that to me for all intents and purposes is a rewrite anyway - in that case I'd class the terms as interchangeable anyway.

I don't necessarily believe to be called a rewrite that every bit of code has to be rewritten by hand. I think it's sufficient that the vast majority of the codebase be rewritten for it to be termed a rewrite. If I ever was to call for something to be completely rewritten with nothing carried over I'd probably refer to it as a "full rewrite", "complete rewrite", or an "absolute rewrite".

I find backtracking to the beginning to sometimes be a useful tool for managing a major refactoring (what I'd call a rewrite), sometimes if it's the base of the application that's rotten - i.e. lacking an OS specific abstraction layer for something like, say, drawing such that there are OS specific hacks littered over completely unrelated things then I might just start a new project, build that abstraction layer and then bring the rest of the code over switching it to use that new abstraction layer so that drawing calls are drawing calls, not drawing calls with random OS specific instructions as a result of hacks in them. This is what I'd typically call a rewrite, even if large parts of the application are being brought across, but I suppose you might equally just call it a major refactoring operation if any existing code at all is carried across.

So I suppose it really depends on where you draw the line if anything. I guess you may be able to corner it to the point of saying whether you need a refactor or a fresh project depends on what part of the applications needs to be replaced - if it's something fundamental like the underlying calls to be switched from being OS specific into a nice OS neutral abstraction layer that has OS specific concrete implementations per OS to keep all the OS specific stuff separate then I'd argue that that's going to be too low down in the application to refactor in a reasonable manner. If however your drawing calls are just messy and the interfaces are cluttered with unnecessary parameters and make no sense then of course a refactor is sufficient. In other words, the further away you are abstracted from the low level guts of the application the easier it is to refactor, but if the guts themselves are fucked then it will often make sense to rewrite them from scratch and take the higher level stuff across. In this respect I would imagine it depends on what you're doing too - if your job is porting software to different operating systems then I'd imagine starting from a fresh base is a far more common thing than if you're just maintaining mature business systems that are never going to move from the platform they're already on for example.

The other place I've seen prominent rewrites is in web applications, I've seen any number of PHP applications that started to need things like proper threading to support better scalability and flexibility be rewritten in things like C#/ASP.NET or Java/Spring or similar. When you're changing stack like that the rewrite is the only option, and frankly switching from interpreted to compiled languages tends to result in better code quality anyway because whole classes of errors are caught and fixed at compile time that can trivially go unnoticed in interpreted languages like PHP so concerns about throwing out years of existing knowledge tend to be outweighed by the inherent better code quality and performance you get from JIT'd languages in that sort of circumstance anyway.

But I do agree, there's a time and a place. It's certainly not something that you should be doing too often.

But I don't think anyone talks about creating a description when they're referring to description vs. discovery of an algorithm. Everyone knows that language, which is ultimately what math is, is a creation of the human mind (or is it discovered inside the human mind? I'll let you figure that one out).

What you're referring to as the creation of an algorithm is simply the creation of the description of the algorithm which is a different thing to the creation/discovery of the algorithm. Fundamentally the point still stands that the person you created it, may simply have subconsciously discovered it - what they wrote down is merely the description of what they discovered.

Well not necessarily, if as the article says there's a greater abundance of food then they'll be less likely to come and hunt dangerous and relatively bony and low meat humans.

Generally they don't hunt us out of choice, but out of necessity.

It's possible that an increase in great whites will result in reduced attacks if the increase is the result of greater availability of food so now satisfy or more than satisfy the population. It'll only be an issue if there are years where their food sources suffer population declines or similar.

MonoGame is a drop in replacement for XNA and it's actively developed by people who are themselves game developers. It even has some commercial PS4 releases to it's name.

I was skeptical at first, but I've started playing with it and it's absolutely excellent. Most definitely fit for rapid high quality indie game development.

There are a number of commercial indie games on platforms ranging from Android, iOS, Windows, Mac, the PS3, the PS4, the XBox 360, the Wii, the Wii U and the XBox One written using C# executing via Unity or Mono using something like MonoGame.

C# is not too high level for game programming, it's perfectly adequate. You may start running into issues with it if you're trying to produce photorealistic next gen console graphics with it, but I assure you, if you're an indie developer, you are not doing this, because you do not have the 1000 people behind you required to produce the art assets that make that kind of engine worthwhile. Even then it wont even be C++ that'll save the day, it'll be assembly optimisations and making use of platform specific functionality (like say the ESRAM in the XBox One).

So anyone who isn't part of a professional studio most definitely should look at C# and Java for game programming, they wont hit any performance problems from the language/runtimes and they hit the ground running much faster due to the faster development times that higher level languages grant you.

Unless you already know C++ and only know C++, then there's no real benefit to using it as an indie developer. The language/language runtime is never going to be the bottleneck for the indie - the algorithms they use will be the bottleneck if anything.

As an indie you'd be a fool to use C++, especially if you're new to programming, because it means you'll probably be stuck learning and dealing with it's increased complexities rather than actually getting done what you're there to do - write games.

I learnt this the hard way, I spent 10 years on and off chasing down the perfect engine, a beautiful modular cross platform compilable C++ thing and all I ever got was this base engine each time (then new API versions would come out and I'd re-think things) and never really ever ended up getting anywhere game wise. Nowadays I'm using things like MonoGame and I'm actually doing what I wanted to do all along - write games. The only performance problems I've faced have been from using the wrong data structures and algorithms - performance is entirely in that area. Get your algorithms right and visual quality and hitting the magical 60fps is no problem at all if you do that.

The one thing any indie developer needs to understand is that it's about just doing with what you have. Don't worry about targeting every platform under the sun, just pick what you know best and run with it, and if you do finish something, if you do end up with a game by the end of it that's decent then you'll be raking in enough money to worry about creating a beautiful cross platform native compilable wonder afterwards.

I'd wager anyone who thinks "all games are written in C++", or that "C# is too high level for games development" hasn't actually done any games development and doesn't know the industry. Even some of the big boys are moving away from low level cutting edge C++ in many cases now, performance of high level JIT compiled languages has pretty much reached par with native anyway, the industry has changed, and even large studios have started taking notice.

In fact, in relation to indies, just about all succesful indies that have actually released something in recent years have used managed code, for C# there's Fez, Terraria, Super Meat Boy, Bastion, Magicka, Schizoid, Dishwasher, for Java there's the obvious - Minecraft. I think this really highlights how important managed languages actually are to indies, the speed of development they offer has in many ways been the enabler of the indie movement in the first place.

Agreed, I'd have thought if they actually wanted to stop the NSA doing this sort of thing or be more transparent about it then they'd just shut down the secret courts.

Altering a single budget seems to be a distraction at best.

I think it's still hard because you could equally have:

1) Person A who thinks up the algorithm in his head and writes it down hence creating it

2) Person B who independently spots the algorithm executing in a natural process and writes it down, hence discovering it.

An algorithm is a set of instructions, but how you come to getting into your mind and writing down those instructions results in a dividing line between whether it was created or discovered and even that's not simple when there's a debate about whether the very act of understanding itself is a process of discovery or creation.

This remains true whichever of your definitions is used.

Honestly, I think that's one of Joel's poorer articles. He writes a lot of good stuff, but he's not always right - his views on giving programmers their own office in isolation of others runs in complete contradiction to the reasons for success at many startups that have grown into the big boys like Google, and Facebook for example not to mention many such articles including the one you linked are ancient now (this one is 14 years old) and understanding of problems changes. He makes a lot of claims in this particular article without really any founding:

"It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time."

This is complete nonsense. When you've worked with a codebase for a while you begin to understand it's deficiencies, sometimes they can be resolved with a simple refactor, but other times there's a more fundamental problem with the whole underlying architecture, and at that point a rewrite is a sensible option.

"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95."

These are mostly symptoms of why the codebase should be re-written, if it's full of hacks, sorry "bug fixes" like this then it's a sign that there were design deficiencies from the outset. You shouldn't have LoadLibrary calls everywhere to fix things because you should've had a platform abstraction layer which hides all that away in one comfortable place. Worse, because the codebase is full of such hacks, the maintainability of the codebase would be atrocious. You'll be throwing away hours trying to understand the implications of changes on these hacks, and making these hacks work with changes, when a clean design learning from the issues in the original codebase would simply let you just write your changes without any worries about upsetting these hacks. He claims "Itâ(TM)s harder to read code than to write it." - that's only true if your codebase is a complete mess and needs rewriting in the first place.

Worse, because your codebase is full of hacks and unreadable code, the potential for difficult to track bugs increases drastically.

Which isn't to say I think rewrites are always a good idea, but I think his examples are poor - for every example of failed rewrites, there is at least an example of a successful rewrite. He's right that if you have a shit dev team that doesn't understand the problems the software is trying to solve well that a rewrite will likely fail also, but that's more a fundamental problem with having a shit dev team than any inherent problem with rewrites.

Most the time consumption in writing software is understanding how to solve problems, the reasons for needing a rewrite are generally architectural. It's not uncommon to be able to define a new architecture and move across knowledge of problem solving or even methods or classes to do so into a completely fresh architectural design. Unless your developers are an army of incompetent hen-pecking typists then writing code is the quick part.

So again, rewrites are not always part the solution, but if you're designing a more flexible and future proof architecture and going in with a development paradigm change, such as writing the new version in TDD, then you can most definitely end up with something that's higher quality, quicker to make changes too, and performs better resulting in a clear net gain in overall cost due to the drastic reduction in time spent bug fixing and generally maintaining it.

If a rewrite is going to take 3 months that sounds like an awful lot of time to sacrifice, but if you're halving the time it takes to do changes and you're doing a few multi-day changes a month, and are simultaneously removing a few days of time spent bug fixing per week then it's going to rapidly become worth it.

In the centre ground there's a question of when a rewrite becomes a rewrite anyway, is it a rewrite if you start a new project but copy a whole bunch of classes that were well designed over? As with pretty much everything there are made shades of grey, and I'd argue the level of rewriting that's required is proportional to the amount of time that's being lost on difficulty of maintenance. If you're losing many days per month on changes and are fixing many bugs per month because the codebase is a mess then it's time for a rewrite. If it's mostly okay but a bit crappy in places then refactor. If it's fine then most definitely don't rewrite just for the sake of it.

"Even with the inherent limitations of proxy data, we've got plenty of records of climate changing as fast as it has during the modern observational period."

No we don't, stop lying, your premise is false, you're just digging yourself a deeper hole as a denialist zealot.

"I'm more careful than that - the claim is that AGW has no necessary and sufficient falsifiable hypothesis statement, and therefore is not science. You're trying to make an argument from ignorance, insisting that AGW must be true if we don't know definitively that it's false."

No you're not, you're stating something is absolutely false, even when there's still a possibility it could be true. Science doesn't always deal in absolutes, and this has to be more the case as we deal with ever more complex systems (nature isn't simple) that's why we have confidence levels that are oft quoted.

If you restrict science to that which can only be proven with absolute certainty then we might as well drop back to the stone ages. Your argument is that unless something is 100% true, then it's false, which is a complete nonsense. You're arguing that it's rational that if something can only be shown to be likely true with 99.99%, or even 99%, or even 80% confidence, that it's better to believe it's false because it's still not 100%.

Apparently you can't see how stupid that makes you look and intend to insist on continuing to prefer the idea that it's better to place your bet on the 5% option than the 95% option. I hope you don't ever considering gambling because it'll absolutely ruin you.