Well you sure have a point there! In fact I don't even know why this upsets me since I'm not even a client/user in that market!:) Maybe because I have the feeling that the free software I'm using can actually have more quality.. IMHO
Sorry, I think I came off a little hostile.
I do agree that there is some really high quality free software / open source software. I think that happens sometimes because much of that kind of software is a labor of love, instead of just profit. I know that I work really hard to polish my personal software projects because they are like my children.
Then again, I think some commercial software is higher quality than free software / open source software, too. My guess is it depends on how sexy the application is.
Sexy applications -- the ones that are fun to write -- tend to have high quality free software / open source software implementations.
It is the applications that aren't sexy that often see better commercial implementations, because not enough developers are interested in spending their free time to write free software / open source software that is not interesting to them.
Of course there are exceptions to those general observations as well.
But I do worry a bit when people think all software should be held to the same standard as, say, bridges or medical devices. Unless the software is critical (such as running a medical device, or handling security for a bank, or an OS kernel, etc.), then there is insufficient incentive to make it super reliable and robust. The market would punish you terribly for having less features and more cost.
There are limits to that, of course. If your application is a buggy mess, they'll reject it. It has to be "good enough", but often, "good enough" is still pretty buggy.
here is this car for you to buy, with 5 seats...but you can only use two of the seats because the engine takes the other three...
It is amazing what software companies can escape with, things that in other engineering fields would totally blast them companies with lawsuits.
Can you imagine a civil engineer gradually patching structural inconsistencies in a bridge as they show up? Yikes!
Software can, in fact, be made as reliable as bridges. But you better be prepared to pay a lot more for your software...
The fact is, the market prefers cheap and buggy over expensive and reliable. If that upsets you, preach your message to the users, not the developers. The developers are only giving users what they want.
I work in a mixed environment, Windows 7/OSX and Linux. I've never heard an OSX user claim Windows 7 is better.
I run both Windows 7 and OS X, and find that both have pros and cons, with no clear winner. That being said, I'd like to enumerate a few places where I think Windows 7 is better than OS X:
Remote Desktop. Windows 7 is insanely better for remote access to the desktop.
Window handling. Windows 7 reliably maximizes windows. (No, OS X's zoom button is not the same.) Win+Left and Win+Right for quickly putting windows side-by-side. Win+Up and Win+Down for things like maximize and restore/minimize.
Windows task bar vs. OS X dock. This comes down to personal preference, but I strongly prefer the Windows task bar.
More window handling. I find it unwieldy to use Cmd+Tab to choose the app, then Cmd+` to choose the window within the app. I much prefer the simplicity of Alt+Tab to get all the way where I want to go. Also, I prefer how Windows first offers to switch to the most recently used windows, whereas Cmd+` cycles through windows in order without regard to last used, making it hard to quickly switch back and forth between windows if there are more than 2 in the same app.
Window menus vs. desktop menu. I much prefer menus be attached to windows. I cannot count the number of times I've seen people tripped up because what appears to be the active OS X window is not, so the menu from a different app is being displayed. Sometimes, that different app does not even have any windows open anymore.
Now before you accuse me of being an "M$ shill" or something, I could just as easily come up with a list of things I like about OS X better than Windows. I'm not picking a favorite horse, just pointing out there are, in fact, reasons someone might really prefer Windows to OS X. I still consider them about even, each having pros and cons, and again, with no clear winner.
And if they knew about it for that long then they should be able to be sued for negligence.
Perhaps when the software industry has to accept the same liability and culpability as anyone else they will take their job seriously.
Aircraft are extremely complex and they cant use that as a get out of jail free card, software should not be able to either. If they want protection and patents then they can accept the down side, liability.
And who is going to pay for this software that is 1000x more expensive?
It's under preferences, universal access, keyboard shortcuts. Assign the keystroke of your choice. Enjoy.
Unless it changed in Lion or Mountain Lion, OS X does not have maximize. It has zoom. And zoom is not maximize, though it might behave that way in some applications, sometimes.
A link/name for the idiom I can pass to our Java people?
I think I would just point them to the Java API documentation and point out these constructors for java.lang.Exception:
Exception(String message, Throwable cause)
Constructs a new exception with the specified detail message and cause.
Exception(Throwable cause)
Constructs a new exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).
These two additional constructors were added to Java 1.4 (so, a good long time ago) precisely because of the issue of catching and re-throwing exceptions and losing the underlying stack trace. These constructors solve that issue. (It does, however, make the stack trace that much longer, so it's pretty noisy!)
All that being said, I'm not really a fan of exceptions. I like old fashioned return codes myself.
But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
Easier/safer languages are a double edged sword. In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?". But, at the same time, it makes programming more accessible to people who really shouldn't be doing software development.
I like to think I'm a good software developer and that using Java makes me more productive, but I readily admit that your average C developer is probably more talented than your average Java developer, possibly by a wide margin.
Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
I believe it. I wonder if it's because all the less talented programmers have moved onto easier/safer languages, as I suggested above. In fact, that's one of my pet theories why your average iOS application is better than your average Android application. It takes a certain determination and skill to master Objective-C, while Java is a lot more "accessible" to less talented developers.
In many ways, I very much miss doing regular C development, though I do wish they would have added a few language features that I consider "must have" for modern development these days, such as "real strings" -- but that opens a whole other can of worms.:-)
Did you not read the entire sentence? I clearly stated that we need a safety net for those unable to work until the raised retirement age. I live in the rust belt, so I have plenty of friends that work in factories and on farms that are unlikely to be able to work to 67.
Are you proposing different retirement ages for different careers, and/or allowing people to retire early based on doctor's recommendations, or what exactly?
I think retiring at 69 with full benefits (what many in congress propose) is going too far, even for white collar workers. What we have currently (retire at 67 with full benefits -- at least for my generation) is already pushing the boundaries, in my opinion.
Sorry, I just have to disagree with your proposal to on average delay retirement, even if we have a safety net for those unable to continue working. Who decides who is and isn't able to continue working?
Smells too subjective and lottery-like. What if you get the bureaucrat or doctor that's ornery and not willing to let people retire early? Or if some people get the bureaucrat or doctor that's allowing healthy people to retire early? That approach seems too ripe for abuse.
Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
That's interesting. My experience has actually been the opposite. I spent a few decades programming in C, and about a decade ago switched to Java.
In my experience -- which is, of course, just anecdotal -- C presented more difficulties. Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened. In addition, it should just kill the one thread. Though typically, we'd wrap threads with catch-all-log-all-and-restart-thread logic, which is just a few lines of code.
However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
Finally we as a society need to realize that as we increase our average lifespan we need to on average delay retirement while still allowing a safetynet for those unable to continue working.
I agree with most of what you're saying, but I get the impression you don't have any "blue collar friends". I do, and ideas like raising the retirement age to 69 is obnoxious and laughable. Some of my "blue collar friends" will be lucky to make it to 65 before their bodies completely give out. My retirement age is 67, and as a "white collar guy", that already scares me enough, especially with the rampant ageism in software development. If the answer to our economic challenges is to place most of the burden on the ailing backs of the elderly, perhaps we should just consider mandatory euthanasia at 65 years old. It would probably be less cruel.
Now answer me the unexplainable riddle of why you didn't immediately install Linux on it?
It's not like you could play 3D games or use things like Maya/Photoshop/Cubase on it anyway.
Various Linux distros did, of course, find their way onto my netbook (thanks UNetbootin!), but I wasn't impressed with the performance of the leading "turn key" distros such as Ubuntu.
I suppose if I wanted to, I could throw Ubuntu or Debian on it, and probably get even a few additional horsepower, but I do have a need to run MS-Office, and it's a member of my AD network, so it's just easier to go XP.
Skip Ubuntu.
It was my distro of choice for extending the life of hardware, but it doesn't seem to offer any performance advantages over Windows 7 or 8 these days.
Debian with a lighter weight DE would work, I'm sure.
I did run Linux on it for a while, and was disappointed with the performance of Unity, KDE, and GNOME 3. In many cases, they seemed slower than Windows 7.
Using a lighter weight DE was an option, of course, but I got tired of dinking around with it. I have a family and a mortgage and a full time job and just wanted something turn key. That was the iPad.
An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.
The JVM would continue running as long as there are running non-daemon threads. Whether or not it is the main thread is irrelevant.
You are correct, however, that calling.length() on an object of type String that is null will throw a NullPointerException; however, it may or may not kill the current thread. It depends on whether or not the exception is caught, which is often the case, especially in servers where robustness is important.
I bought a netbook because I figured it could do everything a tablet could do, and more.
It turned out to be frustratingly slow, largely due to Windows 7 needing too many resources, Microsoft putting ridiculous limitations on what kind of specs a netbook could have while still qualifying for Windows Starter 7, and the agonizingly slow hard drive (which was accessed far too often due to Windows 7 needing lots of RAM -- while at the same time, Microsoft demanding it not be allowed to have much RAM).
Later, I bought an iPad, with a slower CPU and less RAM... and I love it. Even though it's just a lowly iPad 2, the user experience is wonderful. I can't help but think Microsoft is partially responsible for making the iPad a success, because Microsoft were the ones responsible for ensuring a poor netbook experience. If my netbook experience hadn't sucked, I'd never have purchased an iPad.
Unless google recognizes that their content is going across ATT in that area and starts delaying the release of those packets.
That would mean that Google Search would be fast for their own network...but slower (in that area) for ATT.
Don't you love NetNeutrality?
It seems very unlikely Google would intentionally make their main product perform poorly on purpose, as it would just encourage people to use competitor's products instead (e.g., Bing).
My issue with iTunes was never the interface. It was usually pretty intuitive.
I wish it was intuitive to me.:-( I purchase, download, and install an app from the app store to my iPad, then start iTunes to sync the iPad, and before I get a chance to start the sync, iTunes downloads the app again, but this time, just to the Mac. Err, or something like that. Why? Why does it do that?!
Or, I delete a program from my iPad, go into iTunes sometime later to sync, and even then, it downloads the app that I just deleted and never, ever want to see again. I hated that app and deleted it for a reason! Why are you downloading it, iTunes?!
Ugh, as always happens I poorly phrase the first sentence of my post and everyone jumps on it. I wasn't saying debuggers are bad, or at least wasn't trying to - just that in Java, the standard library has a tendency to return null when something goes wrong rather than throw an exception, which means you don't get told about the cause of the issue, just when it shows up later as a null pointer exception. This can lead to using the debugger a lot or looking through the code to track it down. I hope that clarifies my point.
I agree that APIs should avoid returning null wherever it is reasonable to do so, and that the standard Java library is not perfect. However, I am darn glad the standard Java library is as comprehensive as it is. It saves me a lot of time having to hunt down third party libraries that may or may not be affordable, or may or may not have licensing terms that I can accept.
I think Python is much worse in its "anything can throw an exception at any time" design, and I am glad I don't have to use it very much anymore.
That really isn't true. Typing bugs show up with even the most trivial testing. I have written nontrivial stuff with Python, and it works fine as long as you have sane design.
Unit tests rarely, if ever, have 100% coverage.
It is the lazy programmer that uses dynamic typing so he can write less source code. Do the right thing by your users: write the extra (statically typed) code so your programs are more robust.
Plus, as I mentioned, it then allows for easy refactoring, to help keep your code base sane even after it has grown large and you realize some of your design decisions were wrong. And that happens in every nontrivial project, unless you are claiming you have some kind of super human design and coding ability.
Slashdot Mirror
Well you sure have a point there! In fact I don't even know why this upsets me since I'm not even a client/user in that market! :) Maybe because I have the feeling that the free software I'm using can actually have more quality.. IMHO
Sorry, I think I came off a little hostile.
I do agree that there is some really high quality free software / open source software. I think that happens sometimes because much of that kind of software is a labor of love, instead of just profit. I know that I work really hard to polish my personal software projects because they are like my children.
Then again, I think some commercial software is higher quality than free software / open source software, too. My guess is it depends on how sexy the application is.
Sexy applications -- the ones that are fun to write -- tend to have high quality free software / open source software implementations.
It is the applications that aren't sexy that often see better commercial implementations, because not enough developers are interested in spending their free time to write free software / open source software that is not interesting to them.
Of course there are exceptions to those general observations as well.
But I do worry a bit when people think all software should be held to the same standard as, say, bridges or medical devices. Unless the software is critical (such as running a medical device, or handling security for a bank, or an OS kernel, etc.), then there is insufficient incentive to make it super reliable and robust. The market would punish you terribly for having less features and more cost.
There are limits to that, of course. If your application is a buggy mess, they'll reject it. It has to be "good enough", but often, "good enough" is still pretty buggy.
it is more like:
here is this car for you to buy, with 5 seats...but you can only use two of the seats because the engine takes the other three...
It is amazing what software companies can escape with, things that in other engineering fields would totally blast them companies with lawsuits. Can you imagine a civil engineer gradually patching structural inconsistencies in a bridge as they show up? Yikes!
Software can, in fact, be made as reliable as bridges. But you better be prepared to pay a lot more for your software...
The fact is, the market prefers cheap and buggy over expensive and reliable. If that upsets you, preach your message to the users, not the developers. The developers are only giving users what they want.
I work in a mixed environment, Windows 7/OSX and Linux. I've never heard an OSX user claim Windows 7 is better.
I run both Windows 7 and OS X, and find that both have pros and cons, with no clear winner. That being said, I'd like to enumerate a few places where I think Windows 7 is better than OS X:
Now before you accuse me of being an "M$ shill" or something, I could just as easily come up with a list of things I like about OS X better than Windows. I'm not picking a favorite horse, just pointing out there are, in fact, reasons someone might really prefer Windows to OS X. I still consider them about even, each having pros and cons, and again, with no clear winner.
I've been told that the power required to make enough aluminium for a windmill exceeds what that windmill can generate in its service life.
Windmills are, and have been for quite a while, profitable over their lifetime, even if you discount any subsidies.
Since the energy cost of all the materials in a windmill are built into the overall cost of a windmill, it becomes obvious you've been misinformed.
Also, the meme that windmills kill wildlife is just hype. You've been misinformed there, too.
It sounds to me like you need to listen to more reputable sources. Yours are misleading you, or just plain lying to you, for whatever reason.
And if they knew about it for that long then they should be able to be sued for negligence.
Perhaps when the software industry has to accept the same liability and culpability as anyone else they will take their job seriously.
Aircraft are extremely complex and they cant use that as a get out of jail free card, software should not be able to either. If they want protection and patents then they can accept the down side, liability.
And who is going to pay for this software that is 1000x more expensive?
It's under preferences, universal access, keyboard shortcuts. Assign the keystroke of your choice. Enjoy.
Unless it changed in Lion or Mountain Lion, OS X does not have maximize. It has zoom. And zoom is not maximize, though it might behave that way in some applications, sometimes.
A link/name for the idiom I can pass to our Java people?
I think I would just point them to the Java API documentation and point out these constructors for java.lang.Exception:
Exception(String message, Throwable cause)
Constructs a new exception with the specified detail message and cause.
Exception(Throwable cause)
Constructs a new exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).
These two additional constructors were added to Java 1.4 (so, a good long time ago) precisely because of the issue of catching and re-throwing exceptions and losing the underlying stack trace. These constructors solve that issue. (It does, however, make the stack trace that much longer, so it's pretty noisy!)
All that being said, I'm not really a fan of exceptions. I like old fashioned return codes myself.
But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
Easier/safer languages are a double edged sword. In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?". But, at the same time, it makes programming more accessible to people who really shouldn't be doing software development.
I like to think I'm a good software developer and that using Java makes me more productive, but I readily admit that your average C developer is probably more talented than your average Java developer, possibly by a wide margin.
Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
I believe it. I wonder if it's because all the less talented programmers have moved onto easier/safer languages, as I suggested above. In fact, that's one of my pet theories why your average iOS application is better than your average Android application. It takes a certain determination and skill to master Objective-C, while Java is a lot more "accessible" to less talented developers.
In many ways, I very much miss doing regular C development, though I do wish they would have added a few language features that I consider "must have" for modern development these days, such as "real strings" -- but that opens a whole other can of worms. :-)
Did you not read the entire sentence? I clearly stated that we need a safety net for those unable to work until the raised retirement age. I live in the rust belt, so I have plenty of friends that work in factories and on farms that are unlikely to be able to work to 67.
Are you proposing different retirement ages for different careers, and/or allowing people to retire early based on doctor's recommendations, or what exactly?
I think retiring at 69 with full benefits (what many in congress propose) is going too far, even for white collar workers. What we have currently (retire at 67 with full benefits -- at least for my generation) is already pushing the boundaries, in my opinion.
Sorry, I just have to disagree with your proposal to on average delay retirement, even if we have a safety net for those unable to continue working. Who decides who is and isn't able to continue working?
Smells too subjective and lottery-like. What if you get the bureaucrat or doctor that's ornery and not willing to let people retire early? Or if some people get the bureaucrat or doctor that's allowing healthy people to retire early? That approach seems too ripe for abuse.
Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
That's interesting. My experience has actually been the opposite. I spent a few decades programming in C, and about a decade ago switched to Java.
In my experience -- which is, of course, just anecdotal -- C presented more difficulties. Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened. In addition, it should just kill the one thread. Though typically, we'd wrap threads with catch-all-log-all-and-restart-thread logic, which is just a few lines of code.
However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
Finally we as a society need to realize that as we increase our average lifespan we need to on average delay retirement while still allowing a safetynet for those unable to continue working.
I agree with most of what you're saying, but I get the impression you don't have any "blue collar friends". I do, and ideas like raising the retirement age to 69 is obnoxious and laughable. Some of my "blue collar friends" will be lucky to make it to 65 before their bodies completely give out. My retirement age is 67, and as a "white collar guy", that already scares me enough, especially with the rampant ageism in software development. If the answer to our economic challenges is to place most of the burden on the ailing backs of the elderly, perhaps we should just consider mandatory euthanasia at 65 years old. It would probably be less cruel.
Now answer me the unexplainable riddle of why you didn't immediately install Linux on it?
It's not like you could play 3D games or use things like Maya/Photoshop/Cubase on it anyway.
Various Linux distros did, of course, find their way onto my netbook (thanks UNetbootin!), but I wasn't impressed with the performance of the leading "turn key" distros such as Ubuntu.
There were also various driver related issues...
So, you're comparing a $200 netbook with a $500+ tablet?
Well, a $300 netbook, but point taken.
I did learn an important lesson, that lesson being that it is often better to spend more for a far superior experience.
I suppose if I wanted to, I could throw Ubuntu or Debian on it, and probably get even a few additional horsepower, but I do have a need to run MS-Office, and it's a member of my AD network, so it's just easier to go XP.
Skip Ubuntu.
It was my distro of choice for extending the life of hardware, but it doesn't seem to offer any performance advantages over Windows 7 or 8 these days.
Debian with a lighter weight DE would work, I'm sure.
Well, um, can't you change the OS on the netbook?
I did run Linux on it for a while, and was disappointed with the performance of Unity, KDE, and GNOME 3. In many cases, they seemed slower than Windows 7.
Using a lighter weight DE was an option, of course, but I got tired of dinking around with it. I have a family and a mortgage and a full time job and just wanted something turn key. That was the iPad.
An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.
The JVM would continue running as long as there are running non-daemon threads. Whether or not it is the main thread is irrelevant.
You are correct, however, that calling .length() on an object of type String that is null will throw a NullPointerException; however, it may or may not kill the current thread. It depends on whether or not the exception is caught, which is often the case, especially in servers where robustness is important.
I bought a netbook because I figured it could do everything a tablet could do, and more.
It turned out to be frustratingly slow, largely due to Windows 7 needing too many resources, Microsoft putting ridiculous limitations on what kind of specs a netbook could have while still qualifying for Windows Starter 7, and the agonizingly slow hard drive (which was accessed far too often due to Windows 7 needing lots of RAM -- while at the same time, Microsoft demanding it not be allowed to have much RAM).
Later, I bought an iPad, with a slower CPU and less RAM ... and I love it. Even though it's just a lowly iPad 2, the user experience is wonderful. I can't help but think Microsoft is partially responsible for making the iPad a success, because Microsoft were the ones responsible for ensuring a poor netbook experience. If my netbook experience hadn't sucked, I'd never have purchased an iPad.
Wish I hadn't wasted my money on a POS netbook.
Would I have to pay Microsoft $5 per month just to watch Netflix, like I have to with the Xbox 360?
Nickel and diming bastards...
Unless google recognizes that their content is going across ATT in that area and starts delaying the release of those packets.
That would mean that Google Search would be fast for their own network...but slower (in that area) for ATT.
Don't you love NetNeutrality?
It seems very unlikely Google would intentionally make their main product perform poorly on purpose, as it would just encourage people to use competitor's products instead (e.g., Bing).
Similar numbers apply to agriculture (fertilizers, pesticides), open air power lines, automobiles, and - of course - domestic and feral cats.
How much do cats actually kill?
My issue with iTunes was never the interface. It was usually pretty intuitive.
I wish it was intuitive to me. :-( I purchase, download, and install an app from the app store to my iPad, then start iTunes to sync the iPad, and before I get a chance to start the sync, iTunes downloads the app again, but this time, just to the Mac. Err, or something like that. Why? Why does it do that?!
Or, I delete a program from my iPad, go into iTunes sometime later to sync, and even then, it downloads the app that I just deleted and never, ever want to see again. I hated that app and deleted it for a reason! Why are you downloading it, iTunes?!
I find the whole thing !@#$ing confusing.
...says the Java programmer...
Haters gonna hate.
Eclipse is better if you're a pro, too. It makes navigating around large code bases very easy.
Ignore all the morons who think we should all still be digging holes with spoons instead of power equipment.
Ugh, as always happens I poorly phrase the first sentence of my post and everyone jumps on it. I wasn't saying debuggers are bad, or at least wasn't trying to - just that in Java, the standard library has a tendency to return null when something goes wrong rather than throw an exception, which means you don't get told about the cause of the issue, just when it shows up later as a null pointer exception. This can lead to using the debugger a lot or looking through the code to track it down. I hope that clarifies my point.
I agree that APIs should avoid returning null wherever it is reasonable to do so, and that the standard Java library is not perfect. However, I am darn glad the standard Java library is as comprehensive as it is. It saves me a lot of time having to hunt down third party libraries that may or may not be affordable, or may or may not have licensing terms that I can accept.
I think Python is much worse in its "anything can throw an exception at any time" design, and I am glad I don't have to use it very much anymore.
That really isn't true. Typing bugs show up with even the most trivial testing. I have written nontrivial stuff with Python, and it works fine as long as you have sane design.
Unit tests rarely, if ever, have 100% coverage.
It is the lazy programmer that uses dynamic typing so he can write less source code. Do the right thing by your users: write the extra (statically typed) code so your programs are more robust.
Plus, as I mentioned, it then allows for easy refactoring, to help keep your code base sane even after it has grown large and you realize some of your design decisions were wrong. And that happens in every nontrivial project, unless you are claiming you have some kind of super human design and coding ability.