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?
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 g
"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.
"Agreed. Obviously before humanity, all climate drivers were non-anthropogenic. The addition of humanity obviously does not make those drivers disappear, so the null hypothesis is that modern climate variation is driven by the same non-anthropogenic drivers as previously caused climate variation."
This is a straw man argument. It's not simply a case of climate changing that is the problem being studied, it's the rate of change that is of concern to cause study. Yes the climate has always changed, no we don't have any record of it changing as fast as it is without there being some clear and apparent factor (such as a massive volcanic eruption).
You really shouldn't be wasting people's time by discussing this topic with them when you don't even understand what the basic underlying phenomenon being studied is.
"If anyone is telling you they fully understand all the natural factors of climate variation and how they interact, they're lying to you."
Yet that's exactly what you've done. By claiming that human caused CO2 emissions are most definitely not the overriding factor in causing climate change you must be definition know what it is, because if you don't, then you cannot possibly rule out human made CO2 emissions. You've done exactly that though, so please, the world awaits, tell us what the overriding cause of climate change is and provide us all your evidence, it's the only possible conclusion one can reach based on what you've said.
Unless of course, you're lying to us and should never have made such a silly claim as you did that humans as a factor in climate change via CO2 is a false hypothesis.
I think I know which one I'll place my bet on - that you're the very type of liar that you're trying to deflect others away as passing off your personal opinion as scientific fact when it's anything but.
To be fair, if you're not American, the attack on Pearl Harbour is quite the irrelevance in the grand scheme of things such that no, it probably isn't in most kids history lessons, there's just too much other far more important stuff from other nations histories than that part of American history. If they go near American history at all it tends to focus on the war of independence, the war of 1812 or the American civil war.
Certainly here in the UK Pearl Harbour was never on the agenda, we got taught about the American war of independence and the American civil war but that's it. In terms of World War teaching it was focussed either on World War I, or the European and African fronts. We didn't even really get taught much about the war in Asia and places like Australia, despite these being far more relevant to our commonwealth history than Pearl Harbour either. There's just too much other stuff to fit in to make room for even the majority of British history, let alone much overseas history on top - especially events that are again in the grand scheme of things pretty irrelevant to the global perspective compared to many other much larger events in history.
"Does the idea of no God or afterlife bring you joy or any feelings (besides smugness?)"
Yes, because it means we're part of a natural system so incredibly vast and complex that I find it to be a far more fascinating proposition than "the magic man in the sky did it" and there's more scientific evidence for it too which is equally fascinating to read about, certainly more so than old fairy tales that got taken too seriously. The bible gives me joy in the way Lord of the Rings give me joy, interesting entertainment, but I wouldn't want to waste more of my life on it than necessary by dedicating my life to fruitlessly searching for Gandelf, Frodo, and the shire.
"I've had both a wife and son die. It really brings me sadness and feels me with emptiness to think that there is no after."
Absence of belief in god doesn't mean there is no after, it just means there's no anthropomorphisation of after. There's every possibility that when you pass, you will be buried, or your ashes dispersed where you wife and son were only to decay with parts of you becoming nutrients that comprise part of a tree together. In hundreds of years that tree may die, and what was once part of you maybe your wife and son too will become parts of many other plants or animals, in millions of years you may become part of a fossil together, in billions of years you may come together as part of a new planet or a star.
You don't need god to realise that the universe is a beautiful thing that you and your deceased wife and son will always be part of in one way or another.
I'm not exactly sure what the point of your link is? A bitch fight between a bunch of bloggers that seems to have no relevance to silicon valley in general? One or two people with an axe to grind don't exactly act as proof of a problem. with the companies themselves.
"I don't think an incredibly skewed ethnic or gender makeup is concrete evidence of discrimination, but it's definitely an indicator that something is wrong."
Yes it is, and that was the point the person you originally responded to was making, that something is wrong, but not necessarily with the companies themselves, or even silicon valley. That it could be a fundamental issue with say, the education system for example which they have no real control over fixing.
At the point they forget that that also means they can't sell ads in Europe without having a European operation such that they're shutting themselves out of the world's largest economy (the European Union) I would imagine.
So sure they could do that, but they'd rapidly lose the race to global competitors who are willing to simply play ball with privacy and data protection law in Europe and it would be goodbye silicon valley, enjoy your trip into irrelevance.
I'm not sure anyone in silicon valley actually wants that. There's far more profit in behaving themselves and playing global than being isolationist dicks.
Plus it seems pretty clear that GCHQ is in breach of the Data Protection Act in the UK, which makes allowance for law enforcement, but obviously by harvesting all data GCHQ goes beyond that. The specific exemptions in law are:
- the prevention or detection of crime; - the capture or prosecution of offenders; and
Obviously harvesting data of innocent non-crime committing people achieves neither of these things. Which is why I suspect GCHQ's acts wont survive subsequent court challenges anyway - even if they succeed in national courts, they'll get slapped down at European level as whilst the creation of the UK's supreme court has created a puppet for parliament in the judiciary they still have no way of manipulating the European Court of Justice.
So it's a multi-pronged approach. Saying "Well there's no point fixing this, because that is broken" is stupid when "that" is also being targeted for fixing also. As you imply, just because there's more than one issue doesn't mean we should deal with none of them, it just means they have to be dealt with as separate cases.
From what I've seen they seem to be some of the few companies willing to actively campaign for gay rights equality and so forth for example and they don't seem to have any qualms hiring people from different ethnicities overseas, and in fact have been campaigning for more.
Is your suggestion that because the numbers aren't 50/50 that they're obviously discriminatory or something?
I think that's the problem, I think this law was enacted in an era where off-shore communications were rare, such that any mail sent to somewhere like Russia during the cold war might be a bit suspicious. Although not everyone, not by a longshot, the ratio of legitimate overseas communications to subversive ones would have been much lower when this law was written. There was also no trivial way to blanket intercept all postal mail, open it, and record it automatically without greater risk of the recipient and sender being aware either.
The problem is now it's being applied when everyone and anyone now communicates overseas on a daily basis. There is a far greater ratio of innocents to threats, and collection is arbitrary of everyone. That means the law is being used well beyond it's originally intended purposes which were actually more likely the two examples you cite.
Wow, I always thought Forbes was a fairly professional business oriented publication like The Financial Times, but if their writers can't even grasp the difference between revenue and profit and show absolutely no understanding of the fact that taxes are paid before profit what hope is there?
I guess I'll avoid Forbes in future, I didn't realise it was quite such an amateur and clueless operation.
As for your point, well 1000101, it's really quite simple. An overseas company is defined as one that doesn't have it's headquarters in the UK. Doing business in a country does not make a company resident in that country, even though it makes it liable for tax in that country on revenue earned in that country post other deductions on revenue.
But most importantly in this case it's primarily the routing of communications that matters in GCHQ's argument, and if the data is crossing out of the UK then of course it's overseas data.
Which isn't to defend the practice, it's disgusting and unacceptable, but if we're going to argue against it we need to stick to arguments that actually make sense and that hold up in the face of counter arguments.
You haven't demonstrated why I'm wrong because you can't demonstrate why I'm wrong because you can't dispute the law as it's written is not written as it's written as that creates a paradox, hence, you are still wrong. Get over it.
Slashdot Mirror
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 g
"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.
"Agreed. Obviously before humanity, all climate drivers were non-anthropogenic. The addition of humanity obviously does not make those drivers disappear, so the null hypothesis is that modern climate variation is driven by the same non-anthropogenic drivers as previously caused climate variation."
This is a straw man argument. It's not simply a case of climate changing that is the problem being studied, it's the rate of change that is of concern to cause study. Yes the climate has always changed, no we don't have any record of it changing as fast as it is without there being some clear and apparent factor (such as a massive volcanic eruption).
You really shouldn't be wasting people's time by discussing this topic with them when you don't even understand what the basic underlying phenomenon being studied is.
"If anyone is telling you they fully understand all the natural factors of climate variation and how they interact, they're lying to you."
Yet that's exactly what you've done. By claiming that human caused CO2 emissions are most definitely not the overriding factor in causing climate change you must be definition know what it is, because if you don't, then you cannot possibly rule out human made CO2 emissions. You've done exactly that though, so please, the world awaits, tell us what the overriding cause of climate change is and provide us all your evidence, it's the only possible conclusion one can reach based on what you've said.
Unless of course, you're lying to us and should never have made such a silly claim as you did that humans as a factor in climate change via CO2 is a false hypothesis.
I think I know which one I'll place my bet on - that you're the very type of liar that you're trying to deflect others away as passing off your personal opinion as scientific fact when it's anything but.
To be fair, if you're not American, the attack on Pearl Harbour is quite the irrelevance in the grand scheme of things such that no, it probably isn't in most kids history lessons, there's just too much other far more important stuff from other nations histories than that part of American history. If they go near American history at all it tends to focus on the war of independence, the war of 1812 or the American civil war.
Certainly here in the UK Pearl Harbour was never on the agenda, we got taught about the American war of independence and the American civil war but that's it. In terms of World War teaching it was focussed either on World War I, or the European and African fronts. We didn't even really get taught much about the war in Asia and places like Australia, despite these being far more relevant to our commonwealth history than Pearl Harbour either. There's just too much other stuff to fit in to make room for even the majority of British history, let alone much overseas history on top - especially events that are again in the grand scheme of things pretty irrelevant to the global perspective compared to many other much larger events in history.
"Does the idea of no God or afterlife bring you joy or any feelings (besides smugness?)"
Yes, because it means we're part of a natural system so incredibly vast and complex that I find it to be a far more fascinating proposition than "the magic man in the sky did it" and there's more scientific evidence for it too which is equally fascinating to read about, certainly more so than old fairy tales that got taken too seriously. The bible gives me joy in the way Lord of the Rings give me joy, interesting entertainment, but I wouldn't want to waste more of my life on it than necessary by dedicating my life to fruitlessly searching for Gandelf, Frodo, and the shire.
"I've had both a wife and son die. It really brings me sadness and feels me with emptiness to think that there is no after."
Absence of belief in god doesn't mean there is no after, it just means there's no anthropomorphisation of after. There's every possibility that when you pass, you will be buried, or your ashes dispersed where you wife and son were only to decay with parts of you becoming nutrients that comprise part of a tree together. In hundreds of years that tree may die, and what was once part of you maybe your wife and son too will become parts of many other plants or animals, in millions of years you may become part of a fossil together, in billions of years you may come together as part of a new planet or a star.
You don't need god to realise that the universe is a beautiful thing that you and your deceased wife and son will always be part of in one way or another.
"Of course they have no problem hiring brown foreigners for dirt-cheap labor,"
But they're not hiring dirt-cheap labour, in fact, they're paying well above the average. So that comment is obviously false, for example, Google:
http://www.immihelp.com/h1b-sp...
I'm not exactly sure what the point of your link is? A bitch fight between a bunch of bloggers that seems to have no relevance to silicon valley in general? One or two people with an axe to grind don't exactly act as proof of a problem. with the companies themselves.
"I don't think an incredibly skewed ethnic or gender makeup is concrete evidence of discrimination, but it's definitely an indicator that something is wrong."
Yes it is, and that was the point the person you originally responded to was making, that something is wrong, but not necessarily with the companies themselves, or even silicon valley. That it could be a fundamental issue with say, the education system for example which they have no real control over fixing.
At the point they forget that that also means they can't sell ads in Europe without having a European operation such that they're shutting themselves out of the world's largest economy (the European Union) I would imagine.
So sure they could do that, but they'd rapidly lose the race to global competitors who are willing to simply play ball with privacy and data protection law in Europe and it would be goodbye silicon valley, enjoy your trip into irrelevance.
I'm not sure anyone in silicon valley actually wants that. There's far more profit in behaving themselves and playing global than being isolationist dicks.
Plus it seems pretty clear that GCHQ is in breach of the Data Protection Act in the UK, which makes allowance for law enforcement, but obviously by harvesting all data GCHQ goes beyond that. The specific exemptions in law are:
- the prevention or detection of crime;
- the capture or prosecution of offenders; and
Obviously harvesting data of innocent non-crime committing people achieves neither of these things. Which is why I suspect GCHQ's acts wont survive subsequent court challenges anyway - even if they succeed in national courts, they'll get slapped down at European level as whilst the creation of the UK's supreme court has created a puppet for parliament in the judiciary they still have no way of manipulating the European Court of Justice.
So it's a multi-pronged approach. Saying "Well there's no point fixing this, because that is broken" is stupid when "that" is also being targeted for fixing also. As you imply, just because there's more than one issue doesn't mean we should deal with none of them, it just means they have to be dealt with as separate cases.
I'm intrigued, care to elaborate?
From what I've seen they seem to be some of the few companies willing to actively campaign for gay rights equality and so forth for example and they don't seem to have any qualms hiring people from different ethnicities overseas, and in fact have been campaigning for more.
Is your suggestion that because the numbers aren't 50/50 that they're obviously discriminatory or something?
I think that's the problem, I think this law was enacted in an era where off-shore communications were rare, such that any mail sent to somewhere like Russia during the cold war might be a bit suspicious. Although not everyone, not by a longshot, the ratio of legitimate overseas communications to subversive ones would have been much lower when this law was written. There was also no trivial way to blanket intercept all postal mail, open it, and record it automatically without greater risk of the recipient and sender being aware either.
The problem is now it's being applied when everyone and anyone now communicates overseas on a daily basis. There is a far greater ratio of innocents to threats, and collection is arbitrary of everyone. That means the law is being used well beyond it's originally intended purposes which were actually more likely the two examples you cite.
Wow, I always thought Forbes was a fairly professional business oriented publication like The Financial Times, but if their writers can't even grasp the difference between revenue and profit and show absolutely no understanding of the fact that taxes are paid before profit what hope is there?
I guess I'll avoid Forbes in future, I didn't realise it was quite such an amateur and clueless operation.
As for your point, well 1000101, it's really quite simple. An overseas company is defined as one that doesn't have it's headquarters in the UK. Doing business in a country does not make a company resident in that country, even though it makes it liable for tax in that country on revenue earned in that country post other deductions on revenue.
But most importantly in this case it's primarily the routing of communications that matters in GCHQ's argument, and if the data is crossing out of the UK then of course it's overseas data.
Which isn't to defend the practice, it's disgusting and unacceptable, but if we're going to argue against it we need to stick to arguments that actually make sense and that hold up in the face of counter arguments.
You haven't demonstrated why I'm wrong because you can't demonstrate why I'm wrong because you can't dispute the law as it's written is not written as it's written as that creates a paradox, hence, you are still wrong. Get over it.