What the iPhone OS disallows is running third-party apps *in the background*. Built-in functions, like iPod music playing, Mail checking, SMS and call receiving, etc., all run in the background just fine.
Right, so as long as you don't want to listen to Pandora or make a Skype call in the background, everything works fine. Well, you also can't watch Hulu in a window. Or watch Hulu at all. Or keep an SSH session open while you browse websites. Or download files using an SFTP client while you read your email.
I don't care if you have an existing codebase in C#. You are going to have to expose your code as generic webservices anyway since Mono for the iPhone does not support.NET remoting anyway.
Right, because the only type of applications is a thin client that connects to web services.
Maybe you have an existing codebase that you want to run on the iPhone.
Trying to use Mono Touch as a crutch smacks of laziness and fear of learning.
No, it smacks of wanting to re-use code to deliver a solution at lower cost in less time and with fewer bugs compared with trying to rewrite things from scratch.
There are many, many "Windows PCs" that support 5GHz, including pretty much every PC with an Intel 5100 or 5300 wireless chipset.
Even many cheap PCs like the Acer 1410 come with Intel 5100; the T400 that I currently use had it as an option for $9 more (the integrated graphics version has it standard).
since the voice and data decks are separate; the voice isn't *going* over the data connection, so a roam there shouldn't affect a voice call.
That's true for CDMA2000 EV-DO (used by Verizon and Sprint) but not for UMTS/HSDPA (used by T-Mobile and AT&T).
There are two completely independent connectivity stacks in a dual-mode UMTS/GSM device: the UMTS (UMTS/HSDPA) stack and the GSM (GSM/GPRS/EDGE) stack. Both are capable of handling either voice or packet data.
UMTS to GSM handoffs are complex. While GSM and UMTS share a lot of features at the network level, they are completely different from an RF standpoint.
I regularly see UMTS to GSM handoffs on my T-Mobile G1; I'm on the fringe of UMTS coverage at my apartment (but I have great GSM coverage) and so I will almost always see a UMTS to GSM handoff just by moving around the apartment.
Usually these handoffs are not noticeable, but I would say that about 1 in 20 results in a dropped call.
Unfortunately both AT&T and T-Mobile have been rather conservative in their UMTS deployments thus far. T-Mobile was held up until around 2007-2008 due to a lack of spectrum and delays in vacating the AWS spectrum that they purchased in late 2006. AT&T doesn't really have an excuse. The stupid thing is that T-Mobile's UMTS coverage is rapidly catching up to AT&T's UMTS coverage, despite the fact that AT&T has three times more subscribers and was able to start years earlier.
The problem is that Google rewrites the URL by changing the href attribute of the when you click. This makes it so that the status bar shows the regular URL, yet you get sent to the redirected URL because it gets switched out when you click the link.
There is no "sniffing" in Firefox. What does happen is that the "Copy Link Location" menu item in Firefox copies the *current* href, not the href before you clicked. This could be because the menu is opened on mouse up (the link is swapped on mouse down).
...Of course, since the biggest bottlenecks in code usually occur in essentially serial sections of code, you can't just reorder them and hope for the best.
Well, that's highly dependent on your code. If you're writing something like matrix manipulation or most image processing routines, none of your code is particularly serial. You can even get away with things like WAW hazards because of register renaming.
If you've already done all of the high-level optimization that you can, maybe it's time to start looking at a VTune or CodeAnalyst and figuring out where your branches are being mispredicted and where you're seeing stalls. But the reality is, those optimizations get you the last 20%, which doesn't mean shit if your algorithm is inefficient or accesses memory inefficiently.
TFA using examples such as shift-vs-multiply sound like your grandfather complaining that you don't double-clutch on downshifting into first gear. "True" in the sense that yes, it once had meaning and no longer does - But totally wrong in the sense that people who think about their code at that level have moved beyond such trivialities and onto actual modern ones such as how to feed N pipelines so as to minimize stalls, or what degenerate conditions flog the latest branch prediction techniques (or more usefully, as a classic example, how to write your code so as to minimize branching)
I also hate the 'instruction weenie' optimizations. It doesn't matter (for example) if an integer multiply instruction has two-cycle latency and a shift instruction has one-cycle latency. Something like 1 in 5 instructions is a memory access, and another 1 in 5 is a branch. Both of those are potentially far more problematic than an extra cycle that's probably going to be scheduled around anyway.
Mostly this article sounds like exactly the reasons I don't like Java for every task, and why the vast majority of Java apps feel like molasses in January despite every benchmark telling you that in theory they run just as fast as unmanaged code - Because although you can do the above, you have to work against the language rather than with it.
Pretty much no benchmark shows Java (or.NET) running as fast as unmanaged code with a decent compiler; even the best JIT runtimes usually come out in the 50-70% range.
Also, Java doesn't feel slow because of execution performance. It feels slow because it has crappy UI libraries that are slow. There are many, many GTK+/Python apps that are perfectly fine despite the fact that Python is abysmally slow compared to even Java.
When merely assigning a value to a basic machine-supported data type (32 bit integer, as the simple example) involves an implicit function call (and the whole stack-frame preservation that entails)
I'm not sure where you're getting this, but assigning to an int (not an Integer) in Java does not involve a function call in any mainstream JRE I'm familiar with; indeed, it performs very similarly to assignment in C.
The big fault of Java (and also.NET) is that the JIT doesn't have very much time to optimize. Compared with unoptimized C/C++ compilers, Java is considerably faster. It's only once you add the substantial benefits of optimization (loop unrolling, constant propagation, function inlining, instruction scheduling, and a whole host of other optimizations) that the JIT starts to look pretty crappy.
Simple cases, like assignment to an int, are well-optimized by the JIT.
Features like out of order execution, caches, and branch prediction/speculation are commonplace on many architectures, including the next generation ARM Cortex A9 and many POWER, SPARC, and other RISC architectures. Even in-order designs like Atom, Coretex A8, or POWER6 have branch prediction and multi-level caches.
The most important thing for performance is to understand the memory hierarchy. Out-of-order execution lets you get away with a lot of stupid things, since many of the pipeline stalls you would otherwise create can be re-ordered around. In contrast, the memory subsystem can do relatively little for you if your working set is too large and you don't access memory in an efficient pattern.
It also depends on the compiler. GCC, for example, sucks at auto-vectorization, so it's easy to get 30% or more on loopy scientific code just by using SSE instructions properly.
In contrast, PGI or ICC is much harder to beat using assembly.
When we say that the speed of light is "about" 3 x 10^8 m/s, everybody but the most retarded physics students know that it's not exactly that, but that that number is close enough that it's usable. Same as saying pi = 3.141 and g = 9.81 ms^-2 at sea level on Earth.
The speed of light is EXACTLY 299,792,458 m/s because the speed of light is a definition, not a measurement. Since 1983, the meter has been defined in terms of the speed of light, so refinements in the measurement of the speed of light cause the meter to change in length rather than the value of c in m/s to change.
Zed is full of crap. At least in my CS undergraduate program, we were required to take a "performance analysis" class that answered basically all of Zed's questions, plus a whole lot more. Effectively, it covered basic statistics as applied to performance analysis, simulations, measurement techniques, and some basic queuing theory.
There are published CS papers that lack statistical validity - that's inexcusable. Anyone publishing a paper that deals with performance should either know enough statistics to publish a valid paper or have their paper reviewed by someone that does.
Expecting all programmers to understand statistics well is not reasonable. "Programmer" can include everything from someone who hacks PHP pages together for a living to someone who does research into new ML techniques or designs complex software systems. For the person hacking PHP pages together, statistical validity isn't a huge issue since the primary goals are getting a system that works and doing so quickly and with minimal cost.
Philadelphia has this exact system. It's kind of bizarre; you walk through a door, then there's a middle gate (similar to a subway barrier but higher) that opens; you go through that, it closes, the outer door opens, then you go through that. Presumably if you attempt to back up and break/bypass the middle gate, the first set of steel doors closes.
Inlining is a trade-off, as it increases the size of the object code in return for removing the cost of a function call.
The big thing that inlining does, like many compiler optimizations (including things like loop unrolling) is to expose opportunities for additional optimization.
And, FYI good compilers do support multiple architecture versions, and some (ICC) will even generate multiple code paths and code to select the right one at runtime.
This doesn't excuse you from understanding the architecture (particularly the memory hierarchy). Your compiler generally can't make your random memory accesses sequential (unless you get really lucky with optimizations), nor can it turn bubble sort into something efficient.
But you can get within 10% of hand-optimized assembly code in most cases, with a good compiler. And you can do it with vastly lower developer cost.
Ubuntu doesn't distribute ffmpeg either in the default install. It doesn't have to do with being in bed with Microsoft, it has to do with being afraid of software patents.
I believe that Fedora, Debian, and all other prominent Linux distros are the same way. ffmpeg, if it's packaged at all, is in a 'restricted' repository.
The iPhone costs around $200-$300 to manufacture. Look at the iPod touch - it's largely the same hardware, minus the GSM/UMTS chipset (around $10), camera (another $10) and GPS (another $10). Yet the 32GB iPod Touch costs $300, with a healthy bit of profit for Apple.
So why the hell does the 32GB iPhone run $600 unlocked?
£220 ($357) for a laptop battery is insane. Even my high-priced 7-cell (60 Wh) ThinkPad T61 battery was $130, or about £1.30/Wh at today's exchange rates - right in line with his lawnmower battery figures.
I'm not saying that laptop batteries aren't ridiculously expensive - they are. But they aren't as bad as the story makes them out to be, at least not in the US.
The problem is, a many-core non cache-coherent x86-like system isn't particularly interesting. The big advantage of Larrabee was that you could treat it like a normal SMP system, including (presumably) running standard multithreaded C code on it. Once you have to deal with memory synchronization explicitly, Larrabee starts to look a lot more (from a programming standpoint) like Fermi, Cypress or whatever other Nvidia/ATI GPUs are out at the time.
There's nothing magic about x86/AMD64 in the HPC world. It's attractive because it is cheap and has good performance. Clusters can, have been, and still are built using POWER and other architectures.
With only 60% of the US having access to broadband I'm thinking opposition is going to come from everywhere.
Wrong. 60% of the US *has* broadband (actually, somewhere between 50% and 70%, depending on what statistics you look at). Actual broadband *coverage* in the US is at least 78% (OCED 2005 DSL coverage in the US), if not considerably higher.
FYI, Qwest (one of the Bells) does allow naked DSL; I'm using it right now. It's $5/mo or so more than DSL with a phone line, which means that you save $10/mo or so (plus the various phone line taxes that don't apply to DSL) compared with basic local service.
. The "Guide" doesn't support over-air TV sub-channels (i.e. 2.2) so getting TV listing for the subchannels requires looking at zap2it or the newspaper (not a big deal for us).
Windows 7 media center does, and it works great. You can even remap channels if the guide data is wrong, which is wonderful for picking up clear QAM channels from the cable company (for example, if you have the $10-$15/mo "basic" cable, you can get local and possibly a few cable channels this way).
Right, I personally despise the term "RISC" because it conflates a number of architecture aspects.
Does RISC mean few instructions? If so, how do you explain modern PowerPC CPUs, which have a full set of vector, floating-point, and other instructions?
Does RISC mean load-store (most instructions only support register direct and immediate addressing)?
Does RISC mean pipelined?
There are pipelined CISC CPUs, there are CISC CPUs with fewer instructions than RISC CPUs, and there are "RISC" CPUs that aren't load-store.
Intel's 34nm SSD products were the same way, as are most NVIDIA cards at launch, as was the Wii.
Production doesn't always meet demand. The wheels fell off at TSMC. You can wait a couple of weeks for your 5850, or HardOCP has a deal on them for $300.
Go seems to suffer from the problem of not being done. Case in point: exceptions.
Google's C++ style guide forbids exceptions. This is because of historical reasons - Google's codebase is not exception-tolerant.
Because Go doesn't have exceptions, programmers won't write exception-safe code. Since Go is garbage-collected, this is less of an issue compared with C++, but there are still cases where things like file handles or external resources need to be cleaned up.
Two, three, or four years down the road, it's going to be hard to use exceptions in Go, because the existing code that's out there won't inter-operate properly with code that throws exceptions.
In my opinion, exceptions are absolutely, positively critical in a modern imparative programming language. Exceptional conditions happen. Parsers get data in the wrong format. Network requests time out. Hardware fails.
There are some exceptional conditions that should never happen, and if they do they should kill the system and print something that lets you track down the problem. Exceptions provide this behavior for free; simply don't catch them and you get at least a stack trace when they occur.
The alternative is to write a bunch of error handling code to print out debugging information and exit. Then you call it from everywhere that one of these critical errors occurs.
Except, what if you want to handle one of these critical errors? What if you're calling code that exits if it fails, but you want to report errors in a different way? What if the exceptional case is supposed to happen, like if you're writing unit tests?
The other type of error isn't critical. Maybe it's a network timeout or a parsing error, neither of which should probably crash the system (in most cases). Here, you want to handle the error and take some action, like re-sending the data or asking for input from the user again.
Error codes work here, except that they're cumbersome. Want to include information on exactly what kind of a parser error occurred? Now you're going to have to return both an error code and an error string. Maybe you'll even return an error object.
What if the error occurs in a private method (lowercase first letter in Go) that's called by the public method (uppercase first letter in Go)? With exceptions, you just throw in the private method. With error codes, you need to check for an error code in the public method when you call the private method, then pass the error along.
The one consistent thing about 'audiophiles' is that they insist that they can hear the difference. Not that the difference can be measured (which, of course, it can be - no one disputes that), but that they can reliably tell the difference between two reproductions.
That's not to say that MP3 is transparent with all input sounds, or that it suddenly becomes lossless at a certain bitrate. It obviously doesn't. There are real differences, at any bitrate, between a decoded MP3 and the original data.
But, I'm betting that you can't tell the difference between lossless and high-bitrate MP3, at least not reliably. That's what the statistics say. Your argument is basically, "well, I'm not average". That's certainly possible. But I think that it's more likely that the perceived differences you hear aren't reproducible under blind conditions.
One one hand, we could get more scientific value out of launching 5 or 6 Mars Science Laboratory type projects (or 12+ MER-type projects) per year than a few Shuttle or Ares missions. The human spaceflight program does produce useful science, but it's very, very expensive compared to unmanned missions.
Note that I said science, not engineering. The human spaceflight program does far more for developing our ability to build and survive in space than an unmanned program could. But we need to evaluate just how important that ability is.
On the other hand, NASA's budget is tiny compared to the DOD or many, many other programs. Compare, for example, the cost of the F-22 program, which is equal to about 6 years of Space Shuttle missions.
Slashdot Mirror
Right, so as long as you don't want to listen to Pandora or make a Skype call in the background, everything works fine. Well, you also can't watch Hulu in a window. Or watch Hulu at all. Or keep an SSH session open while you browse websites. Or download files using an SFTP client while you read your email.
Right, because the only type of applications is a thin client that connects to web services.
Maybe you have an existing codebase that you want to run on the iPhone.
No, it smacks of wanting to re-use code to deliver a solution at lower cost in less time and with fewer bugs compared with trying to rewrite things from scratch.
There are many, many "Windows PCs" that support 5GHz, including pretty much every PC with an Intel 5100 or 5300 wireless chipset.
Even many cheap PCs like the Acer 1410 come with Intel 5100; the T400 that I currently use had it as an option for $9 more (the integrated graphics version has it standard).
That's true for CDMA2000 EV-DO (used by Verizon and Sprint) but not for UMTS/HSDPA (used by T-Mobile and AT&T).
There are two completely independent connectivity stacks in a dual-mode UMTS/GSM device: the UMTS (UMTS/HSDPA) stack and the GSM (GSM/GPRS/EDGE) stack. Both are capable of handling either voice or packet data.
UMTS to GSM handoffs are complex. While GSM and UMTS share a lot of features at the network level, they are completely different from an RF standpoint.
I regularly see UMTS to GSM handoffs on my T-Mobile G1; I'm on the fringe of UMTS coverage at my apartment (but I have great GSM coverage) and so I will almost always see a UMTS to GSM handoff just by moving around the apartment.
Usually these handoffs are not noticeable, but I would say that about 1 in 20 results in a dropped call.
Unfortunately both AT&T and T-Mobile have been rather conservative in their UMTS deployments thus far. T-Mobile was held up until around 2007-2008 due to a lack of spectrum and delays in vacating the AWS spectrum that they purchased in late 2006. AT&T doesn't really have an excuse. The stupid thing is that T-Mobile's UMTS coverage is rapidly catching up to AT&T's UMTS coverage, despite the fact that AT&T has three times more subscribers and was able to start years earlier.
No, that's not correct. Check with Firebug.
The problem is that Google rewrites the URL by changing the href attribute of the when you click. This makes it so that the status bar shows the regular URL, yet you get sent to the redirected URL because it gets switched out when you click the link.
There is no "sniffing" in Firefox. What does happen is that the "Copy Link Location" menu item in Firefox copies the *current* href, not the href before you clicked. This could be because the menu is opened on mouse up (the link is swapped on mouse down).
...Of course, since the biggest bottlenecks in code usually occur in essentially serial sections of code, you can't just reorder them and hope for the best.
Well, that's highly dependent on your code. If you're writing something like matrix manipulation or most image processing routines, none of your code is particularly serial. You can even get away with things like WAW hazards because of register renaming.
If you've already done all of the high-level optimization that you can, maybe it's time to start looking at a VTune or CodeAnalyst and figuring out where your branches are being mispredicted and where you're seeing stalls. But the reality is, those optimizations get you the last 20%, which doesn't mean shit if your algorithm is inefficient or accesses memory inefficiently.
I also hate the 'instruction weenie' optimizations. It doesn't matter (for example) if an integer multiply instruction has two-cycle latency and a shift instruction has one-cycle latency. Something like 1 in 5 instructions is a memory access, and another 1 in 5 is a branch. Both of those are potentially far more problematic than an extra cycle that's probably going to be scheduled around anyway.
Pretty much no benchmark shows Java (or .NET) running as fast as unmanaged code with a decent compiler; even the best JIT runtimes usually come out in the 50-70% range.
Also, Java doesn't feel slow because of execution performance. It feels slow because it has crappy UI libraries that are slow. There are many, many GTK+/Python apps that are perfectly fine despite the fact that Python is abysmally slow compared to even Java.
I'm not sure where you're getting this, but assigning to an int (not an Integer) in Java does not involve a function call in any mainstream JRE I'm familiar with; indeed, it performs very similarly to assignment in C.
The big fault of Java (and also .NET) is that the JIT doesn't have very much time to optimize. Compared with unoptimized C/C++ compilers, Java is considerably faster. It's only once you add the substantial benefits of optimization (loop unrolling, constant propagation, function inlining, instruction scheduling, and a whole host of other optimizations) that the JIT starts to look pretty crappy.
Simple cases, like assignment to an int, are well-optimized by the JIT.
Features like out of order execution, caches, and branch prediction/speculation are commonplace on many architectures, including the next generation ARM Cortex A9 and many POWER, SPARC, and other RISC architectures. Even in-order designs like Atom, Coretex A8, or POWER6 have branch prediction and multi-level caches.
The most important thing for performance is to understand the memory hierarchy. Out-of-order execution lets you get away with a lot of stupid things, since many of the pipeline stalls you would otherwise create can be re-ordered around. In contrast, the memory subsystem can do relatively little for you if your working set is too large and you don't access memory in an efficient pattern.
It also depends on the compiler. GCC, for example, sucks at auto-vectorization, so it's easy to get 30% or more on loopy scientific code just by using SSE instructions properly.
In contrast, PGI or ICC is much harder to beat using assembly.
The speed of light is EXACTLY 299,792,458 m/s because the speed of light is a definition, not a measurement. Since 1983, the meter has been defined in terms of the speed of light, so refinements in the measurement of the speed of light cause the meter to change in length rather than the value of c in m/s to change.
Zed is full of crap. At least in my CS undergraduate program, we were required to take a "performance analysis" class that answered basically all of Zed's questions, plus a whole lot more. Effectively, it covered basic statistics as applied to performance analysis, simulations, measurement techniques, and some basic queuing theory.
There are published CS papers that lack statistical validity - that's inexcusable. Anyone publishing a paper that deals with performance should either know enough statistics to publish a valid paper or have their paper reviewed by someone that does.
Expecting all programmers to understand statistics well is not reasonable. "Programmer" can include everything from someone who hacks PHP pages together for a living to someone who does research into new ML techniques or designs complex software systems. For the person hacking PHP pages together, statistical validity isn't a huge issue since the primary goals are getting a system that works and doing so quickly and with minimal cost.
Philadelphia has this exact system. It's kind of bizarre; you walk through a door, then there's a middle gate (similar to a subway barrier but higher) that opens; you go through that, it closes, the outer door opens, then you go through that. Presumably if you attempt to back up and break/bypass the middle gate, the first set of steel doors closes.
Sorry, but that's a bunch of BS.
EVDO Rev A does 500-800kbps in practice, in real world tests, on Verizon or Sprint.
I have never, ever seen EDGE crack 200kbps on either AT&T or T-Mobile.
AT&T's HSDPA hits 1.5Mbps at times, but usually it hovers around 1Mbps.
The big thing that inlining does, like many compiler optimizations (including things like loop unrolling) is to expose opportunities for additional optimization.
And, FYI good compilers do support multiple architecture versions, and some (ICC) will even generate multiple code paths and code to select the right one at runtime.
This doesn't excuse you from understanding the architecture (particularly the memory hierarchy). Your compiler generally can't make your random memory accesses sequential (unless you get really lucky with optimizations), nor can it turn bubble sort into something efficient.
But you can get within 10% of hand-optimized assembly code in most cases, with a good compiler. And you can do it with vastly lower developer cost.
Ubuntu doesn't distribute ffmpeg either in the default install. It doesn't have to do with being in bed with Microsoft, it has to do with being afraid of software patents.
I believe that Fedora, Debian, and all other prominent Linux distros are the same way. ffmpeg, if it's packaged at all, is in a 'restricted' repository.
The iPhone costs around $200-$300 to manufacture. Look at the iPod touch - it's largely the same hardware, minus the GSM/UMTS chipset (around $10), camera (another $10) and GPS (another $10). Yet the 32GB iPod Touch costs $300, with a healthy bit of profit for Apple.
So why the hell does the 32GB iPhone run $600 unlocked?
£220 ($357) for a laptop battery is insane. Even my high-priced 7-cell (60 Wh) ThinkPad T61 battery was $130, or about £1.30/Wh at today's exchange rates - right in line with his lawnmower battery figures.
I'm not saying that laptop batteries aren't ridiculously expensive - they are. But they aren't as bad as the story makes them out to be, at least not in the US.
The problem is, a many-core non cache-coherent x86-like system isn't particularly interesting. The big advantage of Larrabee was that you could treat it like a normal SMP system, including (presumably) running standard multithreaded C code on it. Once you have to deal with memory synchronization explicitly, Larrabee starts to look a lot more (from a programming standpoint) like Fermi, Cypress or whatever other Nvidia/ATI GPUs are out at the time.
There's nothing magic about x86/AMD64 in the HPC world. It's attractive because it is cheap and has good performance. Clusters can, have been, and still are built using POWER and other architectures.
Wrong. 60% of the US *has* broadband (actually, somewhere between 50% and 70%, depending on what statistics you look at). Actual broadband *coverage* in the US is at least 78% (OCED 2005 DSL coverage in the US), if not considerably higher.
FYI, Qwest (one of the Bells) does allow naked DSL; I'm using it right now. It's $5/mo or so more than DSL with a phone line, which means that you save $10/mo or so (plus the various phone line taxes that don't apply to DSL) compared with basic local service.
Windows 7 media center does, and it works great. You can even remap channels if the guide data is wrong, which is wonderful for picking up clear QAM channels from the cable company (for example, if you have the $10-$15/mo "basic" cable, you can get local and possibly a few cable channels this way).
Right, I personally despise the term "RISC" because it conflates a number of architecture aspects.
Does RISC mean few instructions? If so, how do you explain modern PowerPC CPUs, which have a full set of vector, floating-point, and other instructions?
Does RISC mean load-store (most instructions only support register direct and immediate addressing)?
Does RISC mean pipelined?
There are pipelined CISC CPUs, there are CISC CPUs with fewer instructions than RISC CPUs, and there are "RISC" CPUs that aren't load-store.
Intel's 34nm SSD products were the same way, as are most NVIDIA cards at launch, as was the Wii.
Production doesn't always meet demand. The wheels fell off at TSMC. You can wait a couple of weeks for your 5850, or HardOCP has a deal on them for $300.
Go seems to suffer from the problem of not being done. Case in point: exceptions.
Google's C++ style guide forbids exceptions. This is because of historical reasons - Google's codebase is not exception-tolerant.
Because Go doesn't have exceptions, programmers won't write exception-safe code. Since Go is garbage-collected, this is less of an issue compared with C++, but there are still cases where things like file handles or external resources need to be cleaned up.
Two, three, or four years down the road, it's going to be hard to use exceptions in Go, because the existing code that's out there won't inter-operate properly with code that throws exceptions.
In my opinion, exceptions are absolutely, positively critical in a modern imparative programming language. Exceptional conditions happen. Parsers get data in the wrong format. Network requests time out. Hardware fails.
There are some exceptional conditions that should never happen, and if they do they should kill the system and print something that lets you track down the problem. Exceptions provide this behavior for free; simply don't catch them and you get at least a stack trace when they occur.
The alternative is to write a bunch of error handling code to print out debugging information and exit. Then you call it from everywhere that one of these critical errors occurs.
Except, what if you want to handle one of these critical errors? What if you're calling code that exits if it fails, but you want to report errors in a different way? What if the exceptional case is supposed to happen, like if you're writing unit tests?
The other type of error isn't critical. Maybe it's a network timeout or a parsing error, neither of which should probably crash the system (in most cases). Here, you want to handle the error and take some action, like re-sending the data or asking for input from the user again.
Error codes work here, except that they're cumbersome. Want to include information on exactly what kind of a parser error occurred? Now you're going to have to return both an error code and an error string. Maybe you'll even return an error object.
What if the error occurs in a private method (lowercase first letter in Go) that's called by the public method (uppercase first letter in Go)? With exceptions, you just throw in the private method. With error codes, you need to check for an error code in the public method when you call the private method, then pass the error along.
OK, then let's do a blinded A/B/X comparison.
The one consistent thing about 'audiophiles' is that they insist that they can hear the difference. Not that the difference can be measured (which, of course, it can be - no one disputes that), but that they can reliably tell the difference between two reproductions.
That's not to say that MP3 is transparent with all input sounds, or that it suddenly becomes lossless at a certain bitrate. It obviously doesn't. There are real differences, at any bitrate, between a decoded MP3 and the original data.
But, I'm betting that you can't tell the difference between lossless and high-bitrate MP3, at least not reliably. That's what the statistics say. Your argument is basically, "well, I'm not average". That's certainly possible. But I think that it's more likely that the perceived differences you hear aren't reproducible under blind conditions.
I partially agree with what you're saying.
One one hand, we could get more scientific value out of launching 5 or 6 Mars Science Laboratory type projects (or 12+ MER-type projects) per year than a few Shuttle or Ares missions. The human spaceflight program does produce useful science, but it's very, very expensive compared to unmanned missions.
Note that I said science, not engineering. The human spaceflight program does far more for developing our ability to build and survive in space than an unmanned program could. But we need to evaluate just how important that ability is.
On the other hand, NASA's budget is tiny compared to the DOD or many, many other programs. Compare, for example, the cost of the F-22 program, which is equal to about 6 years of Space Shuttle missions.