Yeah the guy is a troll, look at his post history. He made a similarly stupid post last time Kinect was discussed. Criticism of Kinect is fair enough but some of the points he made don't even make sense- complaints about lighting etc. when it works using IR. Still he gets modded up because he's slagging off Microsoft and that gives your average Slashdotter a hardon no matter how factually incorrect it is.
That's not to say all his points are invalid, the distance thing is a bit of a pain certainly (although the Wii and Move struggle at very short distances too) but for the most part he's just trolling.
You seem to be making the implication that because an organisation is biased one way or another, that both organisations equally distort the truth towards their bias.
This is a false premise on which to base your argument, we know for example that organisations like Fox News, and the Daily Mail, are far more guilty of bending the truth, or sometimes outright lying to support their bias, than say the BBC or The Guardian which whilst both having a left wing bias, are for the most part, capable of sticking to the facts most of the time. This means we can have much greater confidence in what they report being factually correct.
You can of course argue that the fact we know they don't stick to the facts 100% of the time means we should check anyway, and I agree, I think that's fine, but in some stories it's pretty clear whether any bias is being applied. I think you should fact check anyway- I'd be more concerned about the organisations that don't advertise their bias or whose bias isn't well known. Certainly I wouldn't assume that because a site doesn't advertise it's bias then it must be neutral and it's facts don't need checking!
Well exactly, that's the point isn't it? It's about using the right tool for the job. If you absolutely know you'll never need to switch databases for the lifetime of the application then don't do it. If you know there's a slim chance, but you're willing to suffer the extra development time in switching by not abstracting away your database layer (or any layer for that matter- e.g. audio in a computer game) then don't bother.
As I say, it's something that may or may not happen, in some cases database abstraction is something you can just do with no extra effort anyway- in a.NET app for example, using the Db* classes and interfaces in System.Data.Common might well just be suitable for many projects such that you're abstracting away with really no more code than it takes to write some database specific code with say, the MySQL connector anyway. If performance isn't a problem, then why not go down this route and ensure abstraction for no extra cost, but with the extra peace of mind? It's just as trivial on many other platforms. Take an example though, no one knew for sure Oracle was going to take over MySQL a year or two back yet it's widely used, how many people now, knowing future development of it is far from certain, and far from guaranteed to be a worthwhile standard are glad they abstracted away their database layer, so that they can switch with no hassle at all? How many are left with the choice of risking their data on a platform that may be obsolete some time down the road and did base their code on MySQL specific libraries and SQL features and have a lot of work ahead of them to fix it? To some people peace of mind is worth it, it's one of those choices you have to make when you're planning and designing a system.
Again I totally agree with you on your core point - that it's about the best tool for the job, but as I say why single out database abstraction when there are equally many other things you can argue too and fro about the relative benefits of, but where the answer about whether to use that thing still comes back to your core point - is it relevant, is it a priority, and is it right to use it in solving the problem at hand? If it's something that offers benefit and can be implemented with no disadvantages in the context of solving the problem at hand, then surely it makes sense to just do it anyway?
I think I made it quite clear that database abstraction isn't always needed, and can in some cases even be an issue, so I'm not sure why you point out that I haven't proven it's something that must be done every time- I never intended to prove such a thing, I think it's unproveable because like you, I think it's wrong.
That makes sense really, when we had MPs (who are after all, right at the top) managing to reply to a private request from a constituent including the text of the constituents original e-mail that included their name, home address and phone number as well as their concern and somehow including every single person in their address book (thousands of public sector employees) then it doesn't breed much respect for the Disclaimer at the bottom.
At least if you don't include the disclaimer people don't associate such a fuckup with that and chuckle when they see requests to keep things secret or private whilst making snyde comments like "well if the guys at the top can't, why should we be expected to?".
"Question: When have you EVER switched database on a web application"
Earlier this year, because expenditure needed to be kept to a minimum during the recession starting in 2008 so the initial build used MySQL with the goal of moving to MS SQL Server when profit forecasts were a lot safer and more stable, which they were (and still are!) earlier this year.
"HOW easy was it?"
Effortless, precisely because I'd used database abstraction. It was done and tested in around 20 minutes thanks to the well written unit tests accompanying our abstraction layer demonstrating that the switch worked as required.
"Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same?"
Yes, I did, for this particular project, for precisely this reason.
"Then go stand in the corner, because your code lacks any optimization."
That's a rather broad statement, there's plenty of optimisation you can do even with just standard SQL, whilst you may lose some additional DBMS specific optimisation features, you may still be able to reach suitable levels of optimisation with ease-
"Real developers optimize their code for the specific environment they are using."
What was that about magic solutions? Optimisation is something you prioritise like everything else. If your application runs at no more than 10% CPU usage and the load isn't going to increase because the userbase is fairly static and this provides plenty of room for increases your application would be expected to see then it's far better to ensure your code is maintainble, than it is to sacrifice maintainability for unnecessary and time consuming optimisation and save the company money by focussing on the priority that best suits the task at hand. "Real developers" should recognise that they simply don't need to optimise at all if in the specific case they are considering it is an unnecesary task.
To use a typical Slashdot car analogy, even the car industry gets this, this is why not every car is in a fight to be the fastest in the world, car manufacturers understand that when a lot of people are limited to a set speed limit anyway, there's no point optimising the car beyond that point and ensuring other things, like having enough room for children to sit in the back, are a priority. The speed of the car just has to be good enough to fulfil the end user's needs not be able to reach speeds which the vehicle will never ever be pushed to in practice at an unnecessary and possibly unaffordable level of cost to the end user.
I actually agree with pretty much everything else you said, but your viewpoint seems a bit contradictory- on one hand you seem to be arguing the basic principle that it's all about using the right tool for the job, but on the other you then seem to be arguing against ways of doing things that are perfectly valid in some scenarios. If you hadn't taken a pop at database abstraction and insisted that all "real programmers" optimise their code then I find little fault with everything else you said. As it stands it sounds like you're saying "You should use the best tool for the job, except in a few cases where I don't like that tool". Sometimes database abstraction has value, sometimes optimisation doesn't.
I used to work in public sector and this sort of disclaimer at the bottom of e-mails was standard practice at the bottom of e-mails from all other public sector departments as well as ours. I always thought at the time it was a bit of a joke, I don't think it's enforceable I think it's designed entirely as a scare tactic in the hope people will believe it, I don't think for a second it's enforcable.
I agree Eclipse is crap but then that's due to abysmal software engineering design and practice, it's just bad software- look at the fact the plugin architecture doesn't work half the time such that if you want the IDE to cope properly with different languages and frameworks you need multiple copies of Eclipse.
I've never had any problems with NetBeans and IntelliJ though, they've always been fast and worked fine.
"I've seen microsofts sucky attempts to make a competitor."
ASP.NET, w/MVC is actually pretty good nowadays.
"Same story, different year. Programmers hate any language they don't know well. It takes a lot of time to learn a new language and many programmers don't have a lot of time. Instead of admitting they are intimidated they dis the technology."
Bad programmers perhaps. Good programmers can jump to the best tool for the job with very little effort, and no need to complain.
No in this case it's just a study that's potentially flawed.
They used automated code checking software, the problem is that this might flag some block of code as an exploit which would normally be if it weren't properly trapped. The problem with automated software like this is that it can flag things up that are correctly handled because it's smart enough to spot an exploit, but not smart enough to deal with the various different ways of handling potential exploits. It's also worth noting that classification of serious is quite arbitrary with this software, it could mean anything from "Really is serious", to "simply doesn't matter".
Until someone has been through and manually checked each one (which is something Google may have already done using similar software meaning none of these are actual workable exploits) then the number of actual serious security bugs could be zero, 10, or 100- in other words the study basically tells us nothing, it's just an attempt to sell their software which is fine for finding potential security flaws, but useful by itself as a tool to guage how many security flaws truly exist in a piece of software.
Well I think that's the biggest problem with this idea, not that it's inherently going to fail in the short term to bring in wortwhile income, but simply that decreasing your customer base in an increasingly globalised world is probably one of the most stupid things you can do in many cases, I don't believe media is different for a second. I think they'll just get drowned out in the long run by the likes of The Guardian, The Telegraph, the BBC and so forth which have much more massive online audiences now, and as time progresses, will get a greater share each of the audiences as their competitors retreat behind paywalls leaving hundreds of thousands of customers looking for their next free offering.
At best those that retreat behind paywalls will see a short term increase in revenue, in contrast, their competitors that remain free are going to be raking in ever more ad revenue and seeing their profits increase, not just in the short term, but over the long term as ever more people come online, and ever more people get abandoned by paywalls. Some sites like the BBC couldn't even go behind a paywall if they wanted because they're under royal mandate to provide free equal access to all British TV license payers (although they use ads to fund accesses from outside the UK which if you're from the US I'm sure you're aware unless you ad block them, those ads aren't there to those accessing from British IPs) so free will always be there, and free will always be increasing it's customer base.
The problem with classification is that we're basically trying to simplify a very complex system of a massive amount of variation even amongst individuals of a species into a finite set of groups. There isn't always this rather binary split between species in reality.
The problem is largely in cases like this, that species don't just diverge- through interbreeding they can converge back together again, then split, and converge and so on with varying ratios of each species involved each time which with each convergence or divergence may increase or decrease the percentage of genetic material of one or the other species.
The problem is also that historically -prior to DNA analysis - we've based our understanding on visual traits, but let me show you some pictures (in this case of cacti) to illustrate how utterly misleading this can be.
They both come from Minas Gerais in Brazil, and appear very similar, and as such it made sense to group them together in the same genus. No one could really argue with this, the logic is sound. Yet, when DNA analysis came along, it turns out the genus Cipocereus is more closely related to Cereus, than it is Pilosocereus, so the plant Cipocereus laniflorus above is more closely related to a plant like this, Cereus repandus, which has it's origins 2500 miles away in Venezuela:
Those who had classified Cipocereus laniflorus as a Pilosocereus were then wildly wrong in their classification.
The problem that faces classification based on visual traits is that of evolutionary convergence- the species that live close in Brazil, despite having a much less close genetic heritage, both had to cater to the same conditions- the same temperatures, the same threats, the same pollinators, and in this case, evolution often just repeats the same solution. If the main pollinators in the area are hummingbirds attracted by bright purple day blooming flowers, then both plants are going to evolve that trait again, even if they're genetically different.
So you can probably see why classification based on visual traits and so forth can at times be horrendously misleading, but as you'll probably realise from my earlier point about convergence and divergence through interbreeding even the DNA records can be confusing. This is why, to this day, as far as I know, the inclusion of Homo neanderthalensis as a subspecies is unresolved. The reality is we never really had these two perfectly distinct species Homo sapien, and Homo neanderthalensis, probably through pretty much their entire period of evolution there were at least periods where them and their ancestors were interbreeding. So from there you can see that the real point is that they evolved in parallel, sometimes sharing genetic material through interbreeding and the real question is, are they genetically close enough to homo sapiens to be classed as a subspecies in that they evolved in parallel with humans and then diverged, or are they genetically distinct enough to be separated from homo sapiens altogether? It might even depend on the point at which you take your sample- a DNA sample taken from a member of the species at a period of interbreeding will likely lead you to the conclusion that H. neanderthalensis probably is just a subspecies of H. sapiens, but one taken from an individual in a population that's had no contact with H. sapiens for a few thousand years or more might lead you to a different conclusion.
I firmly believe classification based on visual traits is wrong, and a bad way to do things
"The point of nuclear weapons is to deter conflicts on the scale of the world wars from ever happening again, and so far they've done that admirably."
That's an interesting conclusion, but based on what evidence? How can you be so certain that it's the nuclear weapons that have deterred such conflicts, rather than perhaps just that even the most crazy dictators around nowadays simply don't have either the will or even resources to cause another world war? Russia has no interest in it, because like Europe, it knows the cost of a world war even when conventional weapons are the limit. China has historically never been particularly interested in incursions outside it's border, largely because it has enough problems inside it's borders, and the smaller players will be obliterated with conventional weapons in no time at all.
I'm not saying you're wrong, but you seem to be asserting that your viewpoint is absolutely correct, when it's one of those things we simply can't be sure about- other posters may well be right, the world might well be just as stable even without nuclear weapons, we simply do not know, because we do not have that nuclear weapon free world to compare to.
Well I'm talking somewhat from experience, I've put many years into MMOs and it took me a while to realise there was no point me spending half the time in game that I was. I was doing so out of habit, but I simply was not enjoying it. I loved it when my friends were around, but when they weren't, I'd still login to grind, because I felt obliged to to be able to keep up with the more interesting stuff, or simply because I was too lazy to find something else to do.
My experience is that many many MMO players felt this way, I'm just glad I eventually figured out what a waste of time it was and much prefer the instant entertainment of single player games or faster paced drop-in/drop-out multiplayer games again.
The only upside of being an MMO addict is you save a fortune, £10 a month subscription and you don't go out or do anything else for entertainment!
Probably not as profitable, but profitable all the same.
It was almost 10 years ago now that Popcap figured out that casual gamers are one hell of a money spinner so it's certainly not a new realisation. Facebook just helped change the degree to which they could make money- Popcap now (or a year or two ago at Facebook's game spam peak) would also probably have achieved the level of income Zynga has.
So I think Zynga would've still been succesful without Facebook, but I agree not to the extent they have been with Facebook.
Assuming you do actually enjoy it. If MMOs are anything to go by a lot of people only enjoy it that 10% of the time it's actually fun (big raids, PVP etc.) and spend the rest of the time pissed off, fed up, and waiting for that thrill to come along next. People seem to put themeselves through these things for a variety of reasons other than enjoyment such as laziness to put in the initial effort to do something they'll enjoy more overall (i.e. go out with friends), depression and hence general lack of motivation to change things, or just outright addiction to the game even if they don't actually enjoy it. Sometimes these things are linked.
Carry on sucking Tom, don't come crying next time the redundancies come around and you can't find anyone else gullable enough to pay for your incompetence though.
Each post you make demonstrates more and more that you simply don't know what the fuck you're on about.
"Please grow up and stop being such a fanboy. The reality is that if you're using JNI, it's because Java doesn't cut it."
Or as mentioned, simply because you're interfacing with something that isn't suited to being developed in native Java, a point you're still apparently entirely unable to comprehend.
"And no, we are FAR from past the days when every clock cycle matters. As energy becomes more expensive, both for cpus and for cooling, programs that use fewer resources are not just welcome, they're needed."
Energy isn't so expensive yet that a handful of clock cycles outweighs the massive extra development cost of achieving that saving. Developer time is still by far the more costly factor.
"Or look at the mobile, embedded, and laptop spaces - oh, don't bother - Java isn't licensed to run on mobiles without paying Oracle to license JavaME - and it needs to be customized for each device (so much for write once run anywhere)."
Not really, the only thing that changes are things like the UI, core code can be reused- a concept you still apparently just do not understand.
"But that's okay, because in YOUR world, nobody buys laptops or servers... just WinBlows, where you're already so bloated that a bit more won't make a difference."
What are you on about? The server space is an area where Java has really made it's mark used by everyone from banks to Google to run their back end processes. I guess you just don't have any experience in developing backend software otherwise you'd know that.
"When I can switch from a generic framework to my custom one, and go from a few pages a second to 400 a second on the same hardware, it means something."
Yes, it probably means you don't know what the hell you're doing.
"it means that the generic code is bloated and almost useless."
Or it means you simply picked the worst framework possible, or picked a good framework and aren't smart enough to understand how to implement it properly.
"It also means that when we put it on the outside-facing server tomorrow, the client is going to be blown away by the fraction-of-a-second responsiveness. "
Which you could also achieve in a fraction of the time with a good framework, which will have been tested and optimised far beyond anything you could do in the 24hrs you've got to get it on the server tommorrow.
"The same techniques work whether I'm coding in assembler, c, c++, php, python, or any other language - well-designed, well-written code wins."
Yes, and the chances are, for most problems, that code has already been written.
"People like you will be the dinosaurs."
I'll take the chance thanks. Meanwhile you can continue to actually be a dinosaur with your 1980s write everything from scratch leading to poorly tested buggy code with a long development time ideology.
"And speaking of code re-use - that has never been the way to advance this industry."
Yes it has, because if you start from scratch every time you have no hope of ever getting round to doing anything new, and you run the risk of constantly reintroducing bugs and security flaws simply because humans aren't perfect- repeat the same thing a hundred times and they'll still do it wrong some of those times no matter how experienced.
"Blindly re-using code just allows crappy code to become firmly embedded. When I get my hands on code, *nothing* is sacrosanct. If you're not throwing out code whenever you refactor, you're not doing it right."
No one said anything about reusing crap code, just reusing good code.
"It's why programming is a form of art. It's where you get to express your creative vision in a concrete fashion."
No actually, it's an engineering discipline, that's probably why you're getting it so very wrong. People want solid, well structured applications, not arty farty bullshit.
"If you don't, or can't, write your own classes, explore new ways of doing things, etc., don't criticize others who enjoy doing so and have managed
You can't blame politicians in a proportional representation system like that. If the population continues to vote someone in who is catering to minority elected extremists then the population are explicitly granting support for that through their vote.
The system isn't the problem, the problem is the electorate that votes for both extremist parties, and parties who are willing to work with and cater to extremists.
"Your ignorance is showing. Communicating with a driver is not "system level stuff." Writing the driver is."
Exactly! This is precisely what JNI can do, yet you stated that if you use JNI for this you're not using Java which implies you're suggesting you need to write a piece of code in Java at systems level, quite clearly you don't. There's no problem with ignorance here, the only issue is you wriggling and constantly redefining the problem to suit as you realise how stupid your comments are- the fact is you're trying to troll about Java and when your arguments are demonstrably wrong, you change the problem to suit your troll. You are wrong, your example was terrible, get over it, stop trying to change the problem to suit your argument, you're now at the point where you're simply contradicting your earlier statements in doing so, this makes you appear stupid, not smart.
"And no, I don't get "thrown by object orientation" - I still write my own classes rather than use pre-made ones. Why should I use someone's generic bloatware approach when I can write one that does exactly what I want, and ONLY what I want?"
LOL, you really don't know what the fuck you're doing do you? you write everything from scratch? Not only do you struggle with object orientation, but you have absolutely no concept of code reuse? Christ I hope you're not developing professionally currently, I'd hate to think you're building any real world code right now. It sounds Tom, like you're one of those people who fits your latter description- 1 years experience 20x over, due to the very fact you're doing things in a very antiquated way, using antiquated technology for the task at hand, and doing things that whilst might have passed as acceptable some decades ago, no longer have a place in modern good practice software development. Clearly you have no understanding of the way software development has moved on in the last 15 - 20 years or so at least. Clearly you have no concept of understanding a wide variety of tools such that you can use the best tool for the job.
Still, as I'm feeling like a good samaritan, I'll try and help you and answer your question, the answer is because we're so long past the days where every clock cycle matters that spending days, possibly weeks redoing something just to save a few clock cycles, at the expense of having more poorly tested and hence less reliable and less trustworthy code, and because using common code rather than reinventing the wheel each time makes it easier for other developers with experience in using that common code to jump in and maintain your product. If you really reinvent the wheel as you say then you must be grossly incompetent, your code must be horribly unmaintainable and your productivity must be painfully low. Just because you can reinvent the wheel, doesn't mean it's a good idea, and certainly doesn't mean you should.
I never touched the first two versions, but dealt with 3, and it was fairly okay when it jumped to 5. I was developing still then though all the same, really DirectX came about to try and ween people onto Windows game development and away from DOS development as Microsoft was pretty clear in their will to eventually move away fully from the command line by this point, I don't think there was any real convincing evidence to the contrary, Carmack's early distaste of DirectX always seemed to stem from the fact it was initially rather crap (which is also why I never bothered with it at first), rather than Microsoft's motivations- they didn't completely shun DirectX, just Direct3D IIRC as I'm pretty sure Quake II's software renderer was written using DirectDraw.
I would however say XNA is more of a problem in the respect you state, because it means you not only lose the ability to simply abstract away library specific stuff, but you're dealing with a completely different platform - you're having to develop for C# and.NET (which is no bad thing in itself as I like C# and.NET) but it's a problem in that it means if you write an XNA game then you really are struggling to get it onto other platforms without a much larger rewrite than if you could just use C++ and DirectX with an abstraction layer for graphics. It's probably this you should be concerned about more than anything because by and large, most AAA developers nowadays are quite content working with both OpenGL style calls (or a close relative of) on the Playstation and Wii, and DirectX on the 360. If Microsoft decided to go fully or at least much more heavily down the managed route next console iteration then you might well find less will to port to say the Playstation than there was this time round and vice versa- that really would be a bad thing IMO.
I still disagree with you on abstraction, you seem to be talking about extremes- too much or too little, when there is simply put, just the right amount of abstraction to ensure your game isn't dependent on any particular multimedia API, and again, as demonstrated through the years with various engines that do just this, it need not cause a measurable performance hit. From Quake through to modern cross platform games like Assassins Creed 2 that push the graphics capabilities of the systems they run on there's no problem with performance doing it this way. Some engines (Source included I think?) even offer DX9 and DX10 paths which is a real demonstration of how a well architected engine really can be neutral to the rendering technology without performing poorly. You also mention the use of wrappers, and a wrapper really is just an abstraction layer albeit generally a sloppy one in that it'll tend to follow an existing specific API's naming standards rather than provide a more generic and neutral interface, but it will tend to do the trick all the same. I guess we'll just have to agree to disagree on this.
Slashdot Mirror
Yeah the guy is a troll, look at his post history. He made a similarly stupid post last time Kinect was discussed. Criticism of Kinect is fair enough but some of the points he made don't even make sense- complaints about lighting etc. when it works using IR. Still he gets modded up because he's slagging off Microsoft and that gives your average Slashdotter a hardon no matter how factually incorrect it is.
That's not to say all his points are invalid, the distance thing is a bit of a pain certainly (although the Wii and Move struggle at very short distances too) but for the most part he's just trolling.
You seem to be making the implication that because an organisation is biased one way or another, that both organisations equally distort the truth towards their bias.
This is a false premise on which to base your argument, we know for example that organisations like Fox News, and the Daily Mail, are far more guilty of bending the truth, or sometimes outright lying to support their bias, than say the BBC or The Guardian which whilst both having a left wing bias, are for the most part, capable of sticking to the facts most of the time. This means we can have much greater confidence in what they report being factually correct.
You can of course argue that the fact we know they don't stick to the facts 100% of the time means we should check anyway, and I agree, I think that's fine, but in some stories it's pretty clear whether any bias is being applied. I think you should fact check anyway- I'd be more concerned about the organisations that don't advertise their bias or whose bias isn't well known. Certainly I wouldn't assume that because a site doesn't advertise it's bias then it must be neutral and it's facts don't need checking!
Well exactly, that's the point isn't it? It's about using the right tool for the job. If you absolutely know you'll never need to switch databases for the lifetime of the application then don't do it. If you know there's a slim chance, but you're willing to suffer the extra development time in switching by not abstracting away your database layer (or any layer for that matter- e.g. audio in a computer game) then don't bother.
As I say, it's something that may or may not happen, in some cases database abstraction is something you can just do with no extra effort anyway- in a .NET app for example, using the Db* classes and interfaces in System.Data.Common might well just be suitable for many projects such that you're abstracting away with really no more code than it takes to write some database specific code with say, the MySQL connector anyway. If performance isn't a problem, then why not go down this route and ensure abstraction for no extra cost, but with the extra peace of mind? It's just as trivial on many other platforms. Take an example though, no one knew for sure Oracle was going to take over MySQL a year or two back yet it's widely used, how many people now, knowing future development of it is far from certain, and far from guaranteed to be a worthwhile standard are glad they abstracted away their database layer, so that they can switch with no hassle at all? How many are left with the choice of risking their data on a platform that may be obsolete some time down the road and did base their code on MySQL specific libraries and SQL features and have a lot of work ahead of them to fix it? To some people peace of mind is worth it, it's one of those choices you have to make when you're planning and designing a system.
Again I totally agree with you on your core point - that it's about the best tool for the job, but as I say why single out database abstraction when there are equally many other things you can argue too and fro about the relative benefits of, but where the answer about whether to use that thing still comes back to your core point - is it relevant, is it a priority, and is it right to use it in solving the problem at hand? If it's something that offers benefit and can be implemented with no disadvantages in the context of solving the problem at hand, then surely it makes sense to just do it anyway?
I think I made it quite clear that database abstraction isn't always needed, and can in some cases even be an issue, so I'm not sure why you point out that I haven't proven it's something that must be done every time- I never intended to prove such a thing, I think it's unproveable because like you, I think it's wrong.
Weren't some of the worst US laws in recent decades voted for by both sides anyway like the DMCA and various "terrorism" related measures?
That makes sense really, when we had MPs (who are after all, right at the top) managing to reply to a private request from a constituent including the text of the constituents original e-mail that included their name, home address and phone number as well as their concern and somehow including every single person in their address book (thousands of public sector employees) then it doesn't breed much respect for the Disclaimer at the bottom.
At least if you don't include the disclaimer people don't associate such a fuckup with that and chuckle when they see requests to keep things secret or private whilst making snyde comments like "well if the guys at the top can't, why should we be expected to?".
"Question: When have you EVER switched database on a web application"
Earlier this year, because expenditure needed to be kept to a minimum during the recession starting in 2008 so the initial build used MySQL with the goal of moving to MS SQL Server when profit forecasts were a lot safer and more stable, which they were (and still are!) earlier this year.
"HOW easy was it?"
Effortless, precisely because I'd used database abstraction. It was done and tested in around 20 minutes thanks to the well written unit tests accompanying our abstraction layer demonstrating that the switch worked as required.
"Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same?"
Yes, I did, for this particular project, for precisely this reason.
"Then go stand in the corner, because your code lacks any optimization."
That's a rather broad statement, there's plenty of optimisation you can do even with just standard SQL, whilst you may lose some additional DBMS specific optimisation features, you may still be able to reach suitable levels of optimisation with ease-
"Real developers optimize their code for the specific environment they are using."
What was that about magic solutions? Optimisation is something you prioritise like everything else. If your application runs at no more than 10% CPU usage and the load isn't going to increase because the userbase is fairly static and this provides plenty of room for increases your application would be expected to see then it's far better to ensure your code is maintainble, than it is to sacrifice maintainability for unnecessary and time consuming optimisation and save the company money by focussing on the priority that best suits the task at hand. "Real developers" should recognise that they simply don't need to optimise at all if in the specific case they are considering it is an unnecesary task.
To use a typical Slashdot car analogy, even the car industry gets this, this is why not every car is in a fight to be the fastest in the world, car manufacturers understand that when a lot of people are limited to a set speed limit anyway, there's no point optimising the car beyond that point and ensuring other things, like having enough room for children to sit in the back, are a priority. The speed of the car just has to be good enough to fulfil the end user's needs not be able to reach speeds which the vehicle will never ever be pushed to in practice at an unnecessary and possibly unaffordable level of cost to the end user.
I actually agree with pretty much everything else you said, but your viewpoint seems a bit contradictory- on one hand you seem to be arguing the basic principle that it's all about using the right tool for the job, but on the other you then seem to be arguing against ways of doing things that are perfectly valid in some scenarios. If you hadn't taken a pop at database abstraction and insisted that all "real programmers" optimise their code then I find little fault with everything else you said. As it stands it sounds like you're saying "You should use the best tool for the job, except in a few cases where I don't like that tool". Sometimes database abstraction has value, sometimes optimisation doesn't.
I used to work in public sector and this sort of disclaimer at the bottom of e-mails was standard practice at the bottom of e-mails from all other public sector departments as well as ours. I always thought at the time it was a bit of a joke, I don't think it's enforceable I think it's designed entirely as a scare tactic in the hope people will believe it, I don't think for a second it's enforcable.
Azureus is a Windows Java app that runs fine.
I agree Eclipse is crap but then that's due to abysmal software engineering design and practice, it's just bad software- look at the fact the plugin architecture doesn't work half the time such that if you want the IDE to cope properly with different languages and frameworks you need multiple copies of Eclipse.
I've never had any problems with NetBeans and IntelliJ though, they've always been fast and worked fine.
"I've seen microsofts sucky attempts to make a competitor."
ASP.NET, w/MVC is actually pretty good nowadays.
"Same story, different year. Programmers hate any language they don't know well. It takes a lot of time to learn a new language and many programmers don't have a lot of time. Instead of admitting they are intimidated they dis the technology."
Bad programmers perhaps. Good programmers can jump to the best tool for the job with very little effort, and no need to complain.
No in this case it's just a study that's potentially flawed.
They used automated code checking software, the problem is that this might flag some block of code as an exploit which would normally be if it weren't properly trapped. The problem with automated software like this is that it can flag things up that are correctly handled because it's smart enough to spot an exploit, but not smart enough to deal with the various different ways of handling potential exploits. It's also worth noting that classification of serious is quite arbitrary with this software, it could mean anything from "Really is serious", to "simply doesn't matter".
Until someone has been through and manually checked each one (which is something Google may have already done using similar software meaning none of these are actual workable exploits) then the number of actual serious security bugs could be zero, 10, or 100- in other words the study basically tells us nothing, it's just an attempt to sell their software which is fine for finding potential security flaws, but useful by itself as a tool to guage how many security flaws truly exist in a piece of software.
"Suddenly all those "2-factor bank SMS" things don't seem so secure anymore, do they?"
That's why some banks, i.e. Barclays in the UK, send you the digital equivalent of a one time pad.
It's a pain in the arse if you want to manage your account on holiday or whatever and forget the pad though.
Well I think that's the biggest problem with this idea, not that it's inherently going to fail in the short term to bring in wortwhile income, but simply that decreasing your customer base in an increasingly globalised world is probably one of the most stupid things you can do in many cases, I don't believe media is different for a second. I think they'll just get drowned out in the long run by the likes of The Guardian, The Telegraph, the BBC and so forth which have much more massive online audiences now, and as time progresses, will get a greater share each of the audiences as their competitors retreat behind paywalls leaving hundreds of thousands of customers looking for their next free offering.
At best those that retreat behind paywalls will see a short term increase in revenue, in contrast, their competitors that remain free are going to be raking in ever more ad revenue and seeing their profits increase, not just in the short term, but over the long term as ever more people come online, and ever more people get abandoned by paywalls. Some sites like the BBC couldn't even go behind a paywall if they wanted because they're under royal mandate to provide free equal access to all British TV license payers (although they use ads to fund accesses from outside the UK which if you're from the US I'm sure you're aware unless you ad block them, those ads aren't there to those accessing from British IPs) so free will always be there, and free will always be increasing it's customer base.
Indeed, even if it is profitable, then it's still a plus that there's 87% less people reading that crap.
"I wonder why the iPhone bug went the other way?"
Apple - Think different.
The problem with classification is that we're basically trying to simplify a very complex system of a massive amount of variation even amongst individuals of a species into a finite set of groups. There isn't always this rather binary split between species in reality.
The problem is largely in cases like this, that species don't just diverge- through interbreeding they can converge back together again, then split, and converge and so on with varying ratios of each species involved each time which with each convergence or divergence may increase or decrease the percentage of genetic material of one or the other species.
The problem is also that historically -prior to DNA analysis - we've based our understanding on visual traits, but let me show you some pictures (in this case of cacti) to illustrate how utterly misleading this can be.
Take these two plants:
Cipocereus laniflorus:
http://www.arkive.org/cactus/cipocereus-laniflorus/image-G5064.html
and Pilosocereus fulvilanatus:
http://home-and-garden.webshots.com/photo/2916062630075508785tgLHvf
They both come from Minas Gerais in Brazil, and appear very similar, and as such it made sense to group them together in the same genus. No one could really argue with this, the logic is sound. Yet, when DNA analysis came along, it turns out the genus Cipocereus is more closely related to Cereus, than it is Pilosocereus, so the plant Cipocereus laniflorus above is more closely related to a plant like this, Cereus repandus, which has it's origins 2500 miles away in Venezuela:
http://www.rarefruit.org/magicgallery05/ph05.htm
Those who had classified Cipocereus laniflorus as a Pilosocereus were then wildly wrong in their classification.
The problem that faces classification based on visual traits is that of evolutionary convergence- the species that live close in Brazil, despite having a much less close genetic heritage, both had to cater to the same conditions- the same temperatures, the same threats, the same pollinators, and in this case, evolution often just repeats the same solution. If the main pollinators in the area are hummingbirds attracted by bright purple day blooming flowers, then both plants are going to evolve that trait again, even if they're genetically different.
So you can probably see why classification based on visual traits and so forth can at times be horrendously misleading, but as you'll probably realise from my earlier point about convergence and divergence through interbreeding even the DNA records can be confusing. This is why, to this day, as far as I know, the inclusion of Homo neanderthalensis as a subspecies is unresolved. The reality is we never really had these two perfectly distinct species Homo sapien, and Homo neanderthalensis, probably through pretty much their entire period of evolution there were at least periods where them and their ancestors were interbreeding. So from there you can see that the real point is that they evolved in parallel, sometimes sharing genetic material through interbreeding and the real question is, are they genetically close enough to homo sapiens to be classed as a subspecies in that they evolved in parallel with humans and then diverged, or are they genetically distinct enough to be separated from homo sapiens altogether? It might even depend on the point at which you take your sample- a DNA sample taken from a member of the species at a period of interbreeding will likely lead you to the conclusion that H. neanderthalensis probably is just a subspecies of H. sapiens, but one taken from an individual in a population that's had no contact with H. sapiens for a few thousand years or more might lead you to a different conclusion.
I firmly believe classification based on visual traits is wrong, and a bad way to do things
For every definition of the word intelligence.
I'd imagine being stuck at gitmo for 8 years has quite a negative effect on the mind too.
"The point of nuclear weapons is to deter conflicts on the scale of the world wars from ever happening again, and so far they've done that admirably."
That's an interesting conclusion, but based on what evidence? How can you be so certain that it's the nuclear weapons that have deterred such conflicts, rather than perhaps just that even the most crazy dictators around nowadays simply don't have either the will or even resources to cause another world war? Russia has no interest in it, because like Europe, it knows the cost of a world war even when conventional weapons are the limit. China has historically never been particularly interested in incursions outside it's border, largely because it has enough problems inside it's borders, and the smaller players will be obliterated with conventional weapons in no time at all.
I'm not saying you're wrong, but you seem to be asserting that your viewpoint is absolutely correct, when it's one of those things we simply can't be sure about- other posters may well be right, the world might well be just as stable even without nuclear weapons, we simply do not know, because we do not have that nuclear weapon free world to compare to.
Well I'm talking somewhat from experience, I've put many years into MMOs and it took me a while to realise there was no point me spending half the time in game that I was. I was doing so out of habit, but I simply was not enjoying it. I loved it when my friends were around, but when they weren't, I'd still login to grind, because I felt obliged to to be able to keep up with the more interesting stuff, or simply because I was too lazy to find something else to do.
My experience is that many many MMO players felt this way, I'm just glad I eventually figured out what a waste of time it was and much prefer the instant entertainment of single player games or faster paced drop-in/drop-out multiplayer games again.
The only upside of being an MMO addict is you save a fortune, £10 a month subscription and you don't go out or do anything else for entertainment!
Probably not as profitable, but profitable all the same.
It was almost 10 years ago now that Popcap figured out that casual gamers are one hell of a money spinner so it's certainly not a new realisation. Facebook just helped change the degree to which they could make money- Popcap now (or a year or two ago at Facebook's game spam peak) would also probably have achieved the level of income Zynga has.
So I think Zynga would've still been succesful without Facebook, but I agree not to the extent they have been with Facebook.
Assuming you do actually enjoy it. If MMOs are anything to go by a lot of people only enjoy it that 10% of the time it's actually fun (big raids, PVP etc.) and spend the rest of the time pissed off, fed up, and waiting for that thrill to come along next. People seem to put themeselves through these things for a variety of reasons other than enjoyment such as laziness to put in the initial effort to do something they'll enjoy more overall (i.e. go out with friends), depression and hence general lack of motivation to change things, or just outright addiction to the game even if they don't actually enjoy it. Sometimes these things are linked.
Carry on sucking Tom, don't come crying next time the redundancies come around and you can't find anyone else gullable enough to pay for your incompetence though.
Each post you make demonstrates more and more that you simply don't know what the fuck you're on about.
This is probably the most realistic theory I've heard to date.
"Please grow up and stop being such a fanboy. The reality is that if you're using JNI, it's because Java doesn't cut it."
Or as mentioned, simply because you're interfacing with something that isn't suited to being developed in native Java, a point you're still apparently entirely unable to comprehend.
"And no, we are FAR from past the days when every clock cycle matters. As energy becomes more expensive, both for cpus and for cooling, programs that use fewer resources are not just welcome, they're needed."
Energy isn't so expensive yet that a handful of clock cycles outweighs the massive extra development cost of achieving that saving. Developer time is still by far the more costly factor.
"Or look at the mobile, embedded, and laptop spaces - oh, don't bother - Java isn't licensed to run on mobiles without paying Oracle to license JavaME - and it needs to be customized for each device (so much for write once run anywhere)."
Not really, the only thing that changes are things like the UI, core code can be reused- a concept you still apparently just do not understand.
"But that's okay, because in YOUR world, nobody buys laptops or servers ... just WinBlows, where you're already so bloated that a bit more won't make a difference."
What are you on about? The server space is an area where Java has really made it's mark used by everyone from banks to Google to run their back end processes. I guess you just don't have any experience in developing backend software otherwise you'd know that.
"When I can switch from a generic framework to my custom one, and go from a few pages a second to 400 a second on the same hardware, it means something."
Yes, it probably means you don't know what the hell you're doing.
"it means that the generic code is bloated and almost useless."
Or it means you simply picked the worst framework possible, or picked a good framework and aren't smart enough to understand how to implement it properly.
"It also means that when we put it on the outside-facing server tomorrow, the client is going to be blown away by the fraction-of-a-second responsiveness. "
Which you could also achieve in a fraction of the time with a good framework, which will have been tested and optimised far beyond anything you could do in the 24hrs you've got to get it on the server tommorrow.
"The same techniques work whether I'm coding in assembler, c, c++, php, python, or any other language - well-designed, well-written code wins."
Yes, and the chances are, for most problems, that code has already been written.
"People like you will be the dinosaurs."
I'll take the chance thanks. Meanwhile you can continue to actually be a dinosaur with your 1980s write everything from scratch leading to poorly tested buggy code with a long development time ideology.
"And speaking of code re-use - that has never been the way to advance this industry."
Yes it has, because if you start from scratch every time you have no hope of ever getting round to doing anything new, and you run the risk of constantly reintroducing bugs and security flaws simply because humans aren't perfect- repeat the same thing a hundred times and they'll still do it wrong some of those times no matter how experienced.
"Blindly re-using code just allows crappy code to become firmly embedded. When I get my hands on code, *nothing* is sacrosanct. If you're not throwing out code whenever you refactor, you're not doing it right."
No one said anything about reusing crap code, just reusing good code.
"It's why programming is a form of art. It's where you get to express your creative vision in a concrete fashion."
No actually, it's an engineering discipline, that's probably why you're getting it so very wrong. People want solid, well structured applications, not arty farty bullshit.
"If you don't, or can't, write your own classes, explore new ways of doing things, etc., don't criticize others who enjoy doing so and have managed
You can't blame politicians in a proportional representation system like that. If the population continues to vote someone in who is catering to minority elected extremists then the population are explicitly granting support for that through their vote.
The system isn't the problem, the problem is the electorate that votes for both extremist parties, and parties who are willing to work with and cater to extremists.
"Your ignorance is showing. Communicating with a driver is not "system level stuff." Writing the driver is."
Exactly! This is precisely what JNI can do, yet you stated that if you use JNI for this you're not using Java which implies you're suggesting you need to write a piece of code in Java at systems level, quite clearly you don't. There's no problem with ignorance here, the only issue is you wriggling and constantly redefining the problem to suit as you realise how stupid your comments are- the fact is you're trying to troll about Java and when your arguments are demonstrably wrong, you change the problem to suit your troll. You are wrong, your example was terrible, get over it, stop trying to change the problem to suit your argument, you're now at the point where you're simply contradicting your earlier statements in doing so, this makes you appear stupid, not smart.
"And no, I don't get "thrown by object orientation" - I still write my own classes rather than use pre-made ones. Why should I use someone's generic bloatware approach when I can write one that does exactly what I want, and ONLY what I want?"
LOL, you really don't know what the fuck you're doing do you? you write everything from scratch? Not only do you struggle with object orientation, but you have absolutely no concept of code reuse? Christ I hope you're not developing professionally currently, I'd hate to think you're building any real world code right now. It sounds Tom, like you're one of those people who fits your latter description- 1 years experience 20x over, due to the very fact you're doing things in a very antiquated way, using antiquated technology for the task at hand, and doing things that whilst might have passed as acceptable some decades ago, no longer have a place in modern good practice software development. Clearly you have no understanding of the way software development has moved on in the last 15 - 20 years or so at least. Clearly you have no concept of understanding a wide variety of tools such that you can use the best tool for the job.
Still, as I'm feeling like a good samaritan, I'll try and help you and answer your question, the answer is because we're so long past the days where every clock cycle matters that spending days, possibly weeks redoing something just to save a few clock cycles, at the expense of having more poorly tested and hence less reliable and less trustworthy code, and because using common code rather than reinventing the wheel each time makes it easier for other developers with experience in using that common code to jump in and maintain your product. If you really reinvent the wheel as you say then you must be grossly incompetent, your code must be horribly unmaintainable and your productivity must be painfully low. Just because you can reinvent the wheel, doesn't mean it's a good idea, and certainly doesn't mean you should.
I never touched the first two versions, but dealt with 3, and it was fairly okay when it jumped to 5. I was developing still then though all the same, really DirectX came about to try and ween people onto Windows game development and away from DOS development as Microsoft was pretty clear in their will to eventually move away fully from the command line by this point, I don't think there was any real convincing evidence to the contrary, Carmack's early distaste of DirectX always seemed to stem from the fact it was initially rather crap (which is also why I never bothered with it at first), rather than Microsoft's motivations- they didn't completely shun DirectX, just Direct3D IIRC as I'm pretty sure Quake II's software renderer was written using DirectDraw.
I would however say XNA is more of a problem in the respect you state, because it means you not only lose the ability to simply abstract away library specific stuff, but you're dealing with a completely different platform - you're having to develop for C# and .NET (which is no bad thing in itself as I like C# and .NET) but it's a problem in that it means if you write an XNA game then you really are struggling to get it onto other platforms without a much larger rewrite than if you could just use C++ and DirectX with an abstraction layer for graphics. It's probably this you should be concerned about more than anything because by and large, most AAA developers nowadays are quite content working with both OpenGL style calls (or a close relative of) on the Playstation and Wii, and DirectX on the 360. If Microsoft decided to go fully or at least much more heavily down the managed route next console iteration then you might well find less will to port to say the Playstation than there was this time round and vice versa- that really would be a bad thing IMO.
I still disagree with you on abstraction, you seem to be talking about extremes- too much or too little, when there is simply put, just the right amount of abstraction to ensure your game isn't dependent on any particular multimedia API, and again, as demonstrated through the years with various engines that do just this, it need not cause a measurable performance hit. From Quake through to modern cross platform games like Assassins Creed 2 that push the graphics capabilities of the systems they run on there's no problem with performance doing it this way. Some engines (Source included I think?) even offer DX9 and DX10 paths which is a real demonstration of how a well architected engine really can be neutral to the rendering technology without performing poorly. You also mention the use of wrappers, and a wrapper really is just an abstraction layer albeit generally a sloppy one in that it'll tend to follow an existing specific API's naming standards rather than provide a more generic and neutral interface, but it will tend to do the trick all the same. I guess we'll just have to agree to disagree on this.