No, I meant that the manipulation of the legislative processes of sovereign governments (as was done with ACTA, using trade treaties) is what pisses people off - not ACTA itself.
Oh, thanks for clarifying. You're completely right with regard to capture rather than kill. However, given the factors involved such as: trying to get him with no losses (bad politically - remember Mogidishu where the bodies of soldiers were dragged like meat through the streets); then there's the fact that Osama was so close to Islamabad which probably means elements of the the Pakistani ISI knew about him (ie. he was protected); resistance by the general Pakistani populace to drone strikes and cross-border raids (which would have posed problems for the friendlier elements of the Pakistani government); and once you got him out ever posturing lawyer would try and turn things around so that the victims of 9/11 did harm to Osama in some way. Things got *so* much simpler from a practical point-of-view with this particular individual dead, despite it being a fail in moral terms (which, sadly, the Western masses often conveniently ignore - preferring instead to follow whatever young master Bieber is up to rather than weigh in in the rightness of acts carried out in their name). Good riddance to that particular turkey, let's just hope it is not accepted as a precedent.
Wow. You must have missed Osamas confessions and urging other people to do the same. And the years of recorded tapes he sent. You might be clever for not thinking action movies are true, but you could have been paying attention to the news for all those years instead of watching fictional movies - then you wouldn't have made such a gaffe (as harmless as it is) on Slashdot.
Actually, the Taliban kill far more civilians than NATO. While you might not have noticed this fast the Afghans certainly have. Some of the tribes (aided by NATO) actively repel the Taliban. Doesn't make good sound bites so the Western News mostly ignores the fact that most of northern Afghanistan is actually ok (by its low standards).
The big problem is not that we won't win the "War on Terror" (and it is important for "us" in the West to win it). The big problem is that we are losing the "War on Corruption", not just petty corruption but the subtle subjugation of the legislative process. This is what is causing revolutions in the Middle East (sick of corruption) and one of the original motivators of Osama Bin Laden. Unfortunately US internal interests (multi-national corps) undermine the laws of sovereign states (eg witness ACTA and the 3-strikes laws popping up etc) is what will create a new wave of disaffected terrorists far more than the bombs. I hope that the US gets its act together with its excessively meddlesome foreign policy (some is understandable - its a linked world after all) and reigns in the corps instead of being a puppet to their tune - but I fear this hope will never come to fruition.
Actually a San Francisco company owns the water rights to a parched town in Bolivia. Including rain water collection rights. This is no joke. The people had to fight their own police force to change the situation (which they eventually did). The US does good things (the government is a very generous aid donor), but also very bad things (the corporations) overseas. It talks about "Free Trade" when it wants to, but then uses all sorts of subsidies for its own farmers. Disclaimer - I'm from New Zealand - I like the US but it is promoting a pretty borked system.
Worse still. The tapping facilities of 'lawful interception' *must* be made available to a foreign government as part of trade treaties (for 'IP protection').
In New Zealand (where I am) our government reminded all of our telcos of a law to have this lawful inception equipment installed by the end of 2010 (my understanding it was part of our international obligations, mostly at the behest of the US whose own agencies are not subject to our local [NZ] laws). Similar equipment is installed in many other countries. This allows the US to trace packets flying across the World in real time (bypassing the supposed protection of the TOR system).
It's even weirder on the Moon when you have no atmospheric attenuation to give you depth cues. True story: a couple of astronauts in a moon rover were headed for a crater and stopped since it didn't seem to be getting any closer. After consulting with Mission Control they decided to continue on for a while but again it didn't seem to be getting any closer. Eventually they decided to turn back. When they analysed this after the mission it turns out they had got very close to the crater when they turned back - but during their moonwalk they were completely unable to judge the distances by sight. Pretty fruity.
Actually you are missing the point. Microsoft dominates the desktop and will continue to do so. However, people aren't buying desktops as they used to. They use their smartphone and iPads for tasks they formerly bought desktops for. With console use on the rise as well you can expected to see the number of consumer desktops stabilize or grow very slowly (accounting for growth in use in the developing world). This is not a situation investors will want to be in. (also written from OS X; I agree with your point that the the software is ok, but the hardware integration is excellent).
Neither the Kinect nor XBox will cause investors to love Microsoft. Just as well there are still loyal fanbois who have blinkers on to what is going on outside of Redmond. The rest of us see Microsoft in a similar way to IBM; big, bloated, and not going away anytime soon, but not exciting either - it's just not in their corporate DNA to make a radical change (the 'addiction' to the Windows/Office cash-cow ensures this).
Excellent point (btw. I'm an ex-astrophysicist so know a bit about the 'astronomy' side of things, and the historical origins of star names like Algol, Aldebaran etc). Islam for a while had a Golden Age of thinking and challenging yourself (ijtihad) - leading to many advancements on the science inherited from the Byzantines (Greek-cultured 'Romans'). Unfortunately, this worried the Caliphate in Baghdad, who shut the questioning down - and lead to the unquestioning stagnation and tribalistic practices of the Arabic Islamic world (which you don't see so much in asian Islamic countries).
China had a technological lead a long time ago, in the technologies you mention. With the Age of Enlightenment (decreased religious and political control of learning and thought), the printing press, and personal freedoms the West/Russia/Middle East leapt ahead. So, while you mention black powder, (block) printing, noodles, which are all great inventions you are choosing to selectively ignore the mammoth changes the West developed since. For example: free speech, modern printing press, mass literacy, railways, steam/coal/hydro/wind/nuclear power, true understanding of electricity and electromagnetism, true understanding of chemistry, true understanding of much of physics, electromagnetic communication, flight, blah blah blah blah blah. Sure the Chinese were by no means primitive, but you are also missing the elephant in the room when you mention their historic contributions. Hopefully they'll also contribute again meaningfully in the future, instead of just copying and refining ideas as they are doing know. That said, I still personally would not like to be a Chinese citizen living in China, hopefully individuals will have more meaningful existences there too.
Writing your own classes for basic stuff is a fail in the modern marketplace. Commercial development usually cannot afford this kind of overhead (although it is perfectly fine for hobbyist and academic work with looser time constraints). In large scale commercial development (large teams of programmers) your suggestion is simply not an option. Large scale development with a large degree of multi-threaded processing and your suggestion is even more removed from reality. Sorry, rolling your own basic classes is madness in this day and age.
It's not only that. How to you handle deallocation of a multitude of heap-allocated objects that are shared amongst multiple-threads. When do you get rid of it without 'pulling the rug out from under' another thread that is using it? You end-up either not using threads (since they're relatively painful in C++) or rolling your own pseudo garbage collector - neither of these is a 'win'.
We wrestled with this design choice for years. In the end we return direct access to the array. It is very efficient (as you point out) and sometimes your client needs that access to get something done (usually some use you didn't foresee). As long as things are documented properly it is better to require that the client know what they are doing and avoid being 'straightjacketed'. If you have to tight a straightjacket (try to hard to protect them from themselves) they can't use your class and end up re-implementing your class themselves so they can have the required access. I come across classes that try to protect me from myself too much and that is a far worse problem then me modifying them incorrectly. Basically, design 'Java Beans' where you can and your classes will be easy to re-use. Document you are returning a modifiable instance and trust your client to read the javadoc (if they screw up and cant read simple docs then that isn't your fault). If the client is you alone and you are protecting yourself from your own code to this degree then I suggest you might find your time spent better by doing productive things (more features, more unit tests) than trying to make your code 'foolproof'. This is my experience (around two decades of C/C++ and Java - both writing my own libraries and using a lot of libraries written by others).
Huh? I 've done a *lot* of bit-level manipulation for devices using Java and the lack of unsigned types has been far outweighed by the benefits of using Java (develop on desktop and deploy to embedded device where 'write once, run everywhere' works far better than C++ for the same tasks). In lieu of using unsigned types you simply use an integer type one 'step' larger and go from there. Once I changed my own mindset from the way I used to do things in C++ to the way Java does things I found the change liberating and I was vastly more productive too (plus, Java's productivity tools like NetBeans and the diagnostics of JVisualVM are hard to beat).
C# may be a good language but its libraries are truly awful in the sense they're simply not available everywhere (Mono's libraries are missing major chunks of functionality compared to the Microsoft set).
Despite the supposed language shortcomings of Java (often criticised by those writing smaller programs or who don't realise that features like 'operator overloading' were deliberately omitted as practical experience showed them to be problematic) the language isn't that bad (especially if you have a large team of people with differing skill levels working on a projetc). The real clincher is that the Java libraries (including 3rd-party) and library portability make Java without peer. This is why Java is still King of the Hill in the Enterprise, and likely to stay there for the foreseable future.
Java deliberately avoided operator overloading as it caused horrific problems with C++ programs. Apart from simple cases you could never trust that someone had overloaded the operator to make it work like you thought - you had to laboriously understand each and every place where an operator was used. Operator overloading was a good idea that turned out to be terrible in practice.
You have obviously never been on a *huge* software development project. The reason you use accessors and mutators (getters & setters) is so you can change the underlying representation without breaking all the uses in you million lines of code.I've had to make changes to underlying representation without breaking th client contract (signature). This is why such practices are used (plus, these methods are auto-generated by most tools anyway).
I have used C and C++ multiple times to make JNI interfaces with a *lot* of hardware (US $30,000 scientific cameras; all sorts of electronics; closed-source native driver libraries, etc etc). These days JNA can pretty much do the integration I need - meaning, using Java means mixed languages are less necessary than they once were, and Java works just about everywhere (except when deliberately excluded, iOS).
With regard to scalability. I recently did a long contract for a global system for a very large US software company who I cannot yet name (they have hosted services as well as desktop stuff). The scale was massive (so called 'Internet scale'). Here we used Java (mostly intended for Linux given the economics of deploying on thousands of servers). The reasons we used Java were the reason I outlined in my original post: strictness of the language means a large team can work on it and comprehend it and the tools give a lot of support to find obscure bugs (at this scale a one-in-a-million threading issue will swamp tech support with hundreds of occurrences per day). Mixing languages in this environment would be a disaster as would dynamic typed languages. Hence, my comments were made because I am experienced with this stuff.
Thanks for taking the time to make your points known, listen, and discuss rationally - wish it was always like that on Slashdot:)
My point was that Python is not used to build *huge* applications, simply because it doesn't easily scale that far (humans need help to gr0k the massive). Oh, you don't need C to make Java faster, since except in a few parts of the standard libraries the JVM is generally faster than C (if you want I can give you a link to the report when INRIA, the French scientific supercomputing folks, did tests) and is approaching FORTRAN for speed. With Java you only really needed C/C++ to do JNI native library integration, but with the third-party JNA library don't even need to do that anymore.
Absolutely correct analysis correlating with my experience. It's very hard making a huge program out of C (too many low level details to keep track of, and poor support for mixing multi-threading and memory management). IMHO the 'open' languages you mention are good for small scale stuff but also hard to scale to the huge (the compiler and tools just can't help you get so many things right *before* you compile and before you run). It's unfortunate that fans of languages of Python think that because Python is quick to develop small applications in then it follows that it would be similarly quick to develop a large application in (which is false, since the debugging effort would increase dramatically). The apparent relative 'slowness' of developing in statically-typed languages like C# or Java is mostly because they are more strict, which allows the compiler and tools to help out during development (incremental compilation and error detection). After all, if your program doesn't have to work correctly every time then your development time can be zero and languages like Python or Lua are good choices:)
"Gtk# is an entirely reasonable alternative and more familiar for the non-Windows crowd at which Mono's aimed."
While I understand this position, it is mostly a 'fail' for the Windows C# crowd. Having a non-portable stack is a big issue. Non-portable (ie. non-standardized) libraries means you can't trust whether it is going to be on your *customers* chosen platform or not (and big customers get to chose the platform, not the developer). Trying to sell a Gtk# solution would work in some places, but there are plenty of customers who would reject it out of hand. This means Mono probably will get limited traction in such (enterprise) spaces, especially when Java does the same thing but far more portably (and the niceness of C# syntax is never a customer concern, and any productivity gains are marginal at best - so I doubt real customers would see many upsides to having Mono-based solutions even if developers do).
Those of us that did C and C++ for two (approaching three) decades want to go back to the bad old days of balkanized solution spaces (eg. juggle both WinForms for Windows, Gtk# for Linux, Cocoa bindings for Mac etc etc - possible to do but just a PITA). We're past the point of finding it 'fun' to re-invent solutions for every platform simply because of different/non-portable libraries, and it certainly makes no commercial sense to do this either. Hence a lot of developers have chosen tech where they don't have to do this.
If C# libraries were as portable as Java and supported by the vendor (eg. Microsoft) then C# would be a rational choice and would dominate development - C# has certainly matured and have plenty of time to achieve this. However the Tiobe Index figures show that C# adoption is not growing very rapidly (certainly not as much as its proponents would like). If C# library portability was a design goal then C# would make sense for development on phones and pads (the topic of this Slashdot article). Even Java falls short in this space (although, as Android gets more powerful I expect eventually to be able to run Java SE libraries on Android - I've deployed Java SE applications to far more constrained embedded/Single-board systems than what is available today to host Android). So, C# may be nice but it is never going to be of much interest to Android (and Big Enterprise) developers.
Huh? how do the "arguers" have anything to do with "one language" ? (aside from a commonly used argument). Having a single language that can meet your development needs is a Good Thing (tm). Remember the K.I.S.S. principle? Sounds like you are indeed a teacher of "development" but not a teacher of "design", and good design [rarely taught or learned, especially not in software] aims to simplify where possible - which means "one language" is a good design goal (and it always indicates poor design in an API if a single language cannot be used to solve most common problems).
Slashdot Mirror
No, I meant that the manipulation of the legislative processes of sovereign governments (as was done with ACTA, using trade treaties) is what pisses people off - not ACTA itself.
Oh, thanks for clarifying. You're completely right with regard to capture rather than kill. However, given the factors involved such as: trying to get him with no losses (bad politically - remember Mogidishu where the bodies of soldiers were dragged like meat through the streets); then there's the fact that Osama was so close to Islamabad which probably means elements of the the Pakistani ISI knew about him (ie. he was protected); resistance by the general Pakistani populace to drone strikes and cross-border raids (which would have posed problems for the friendlier elements of the Pakistani government); and once you got him out ever posturing lawyer would try and turn things around so that the victims of 9/11 did harm to Osama in some way. Things got *so* much simpler from a practical point-of-view with this particular individual dead, despite it being a fail in moral terms (which, sadly, the Western masses often conveniently ignore - preferring instead to follow whatever young master Bieber is up to rather than weigh in in the rightness of acts carried out in their name). Good riddance to that particular turkey, let's just hope it is not accepted as a precedent.
Wow. You must have missed Osamas confessions and urging other people to do the same. And the years of recorded tapes he sent. You might be clever for not thinking action movies are true, but you could have been paying attention to the news for all those years instead of watching fictional movies - then you wouldn't have made such a gaffe (as harmless as it is) on Slashdot.
Very nice! I wonder how many folks will get this?
Actually, the Taliban kill far more civilians than NATO. While you might not have noticed this fast the Afghans certainly have. Some of the tribes (aided by NATO) actively repel the Taliban. Doesn't make good sound bites so the Western News mostly ignores the fact that most of northern Afghanistan is actually ok (by its low standards).
The big problem is not that we won't win the "War on Terror" (and it is important for "us" in the West to win it). The big problem is that we are losing the "War on Corruption", not just petty corruption but the subtle subjugation of the legislative process. This is what is causing revolutions in the Middle East (sick of corruption) and one of the original motivators of Osama Bin Laden. Unfortunately US internal interests (multi-national corps) undermine the laws of sovereign states (eg witness ACTA and the 3-strikes laws popping up etc) is what will create a new wave of disaffected terrorists far more than the bombs. I hope that the US gets its act together with its excessively meddlesome foreign policy (some is understandable - its a linked world after all) and reigns in the corps instead of being a puppet to their tune - but I fear this hope will never come to fruition.
Actually a San Francisco company owns the water rights to a parched town in Bolivia. Including rain water collection rights. This is no joke. The people had to fight their own police force to change the situation (which they eventually did). The US does good things (the government is a very generous aid donor), but also very bad things (the corporations) overseas. It talks about "Free Trade" when it wants to, but then uses all sorts of subsidies for its own farmers. Disclaimer - I'm from New Zealand - I like the US but it is promoting a pretty borked system.
In New Zealand (where I am) our government reminded all of our telcos of a law to have this lawful inception equipment installed by the end of 2010 (my understanding it was part of our international obligations, mostly at the behest of the US whose own agencies are not subject to our local [NZ] laws). Similar equipment is installed in many other countries. This allows the US to trace packets flying across the World in real time (bypassing the supposed protection of the TOR system).
It's even weirder on the Moon when you have no atmospheric attenuation to give you depth cues. True story: a couple of astronauts in a moon rover were headed for a crater and stopped since it didn't seem to be getting any closer. After consulting with Mission Control they decided to continue on for a while but again it didn't seem to be getting any closer. Eventually they decided to turn back. When they analysed this after the mission it turns out they had got very close to the crater when they turned back - but during their moonwalk they were completely unable to judge the distances by sight. Pretty fruity.
Actually you are missing the point. Microsoft dominates the desktop and will continue to do so. However, people aren't buying desktops as they used to. They use their smartphone and iPads for tasks they formerly bought desktops for. With console use on the rise as well you can expected to see the number of consumer desktops stabilize or grow very slowly (accounting for growth in use in the developing world). This is not a situation investors will want to be in. (also written from OS X; I agree with your point that the the software is ok, but the hardware integration is excellent).
Kinect has competitors. One done with (Open Source) software and an IPhone also produces impressive results:
http://www.i-programmer.info/news/105-artificial-intelligence/2310-predator-better-than-kinect.html
Neither the Kinect nor XBox will cause investors to love Microsoft. Just as well there are still loyal fanbois who have blinkers on to what is going on outside of Redmond. The rest of us see Microsoft in a similar way to IBM; big, bloated, and not going away anytime soon, but not exciting either - it's just not in their corporate DNA to make a radical change (the 'addiction' to the Windows/Office cash-cow ensures this).
Excellent point (btw. I'm an ex-astrophysicist so know a bit about the 'astronomy' side of things, and the historical origins of star names like Algol, Aldebaran etc). Islam for a while had a Golden Age of thinking and challenging yourself (ijtihad) - leading to many advancements on the science inherited from the Byzantines (Greek-cultured 'Romans'). Unfortunately, this worried the Caliphate in Baghdad, who shut the questioning down - and lead to the unquestioning stagnation and tribalistic practices of the Arabic Islamic world (which you don't see so much in asian Islamic countries).
China had a technological lead a long time ago, in the technologies you mention. With the Age of Enlightenment (decreased religious and political control of learning and thought), the printing press, and personal freedoms the West/Russia/Middle East leapt ahead. So, while you mention black powder, (block) printing, noodles, which are all great inventions you are choosing to selectively ignore the mammoth changes the West developed since. For example: free speech, modern printing press, mass literacy, railways, steam/coal/hydro/wind/nuclear power, true understanding of electricity and electromagnetism, true understanding of chemistry, true understanding of much of physics, electromagnetic communication, flight, blah blah blah blah blah. Sure the Chinese were by no means primitive, but you are also missing the elephant in the room when you mention their historic contributions. Hopefully they'll also contribute again meaningfully in the future, instead of just copying and refining ideas as they are doing know. That said, I still personally would not like to be a Chinese citizen living in China, hopefully individuals will have more meaningful existences there too.
Writing your own classes for basic stuff is a fail in the modern marketplace. Commercial development usually cannot afford this kind of overhead (although it is perfectly fine for hobbyist and academic work with looser time constraints). In large scale commercial development (large teams of programmers) your suggestion is simply not an option. Large scale development with a large degree of multi-threaded processing and your suggestion is even more removed from reality. Sorry, rolling your own basic classes is madness in this day and age.
It's not only that. How to you handle deallocation of a multitude of heap-allocated objects that are shared amongst multiple-threads. When do you get rid of it without 'pulling the rug out from under' another thread that is using it? You end-up either not using threads (since they're relatively painful in C++) or rolling your own pseudo garbage collector - neither of these is a 'win'.
We wrestled with this design choice for years. In the end we return direct access to the array. It is very efficient (as you point out) and sometimes your client needs that access to get something done (usually some use you didn't foresee). As long as things are documented properly it is better to require that the client know what they are doing and avoid being 'straightjacketed'. If you have to tight a straightjacket (try to hard to protect them from themselves) they can't use your class and end up re-implementing your class themselves so they can have the required access. I come across classes that try to protect me from myself too much and that is a far worse problem then me modifying them incorrectly. Basically, design 'Java Beans' where you can and your classes will be easy to re-use. Document you are returning a modifiable instance and trust your client to read the javadoc (if they screw up and cant read simple docs then that isn't your fault). If the client is you alone and you are protecting yourself from your own code to this degree then I suggest you might find your time spent better by doing productive things (more features, more unit tests) than trying to make your code 'foolproof'. This is my experience (around two decades of C/C++ and Java - both writing my own libraries and using a lot of libraries written by others).
Huh? I 've done a *lot* of bit-level manipulation for devices using Java and the lack of unsigned types has been far outweighed by the benefits of using Java (develop on desktop and deploy to embedded device where 'write once, run everywhere' works far better than C++ for the same tasks). In lieu of using unsigned types you simply use an integer type one 'step' larger and go from there. Once I changed my own mindset from the way I used to do things in C++ to the way Java does things I found the change liberating and I was vastly more productive too (plus, Java's productivity tools like NetBeans and the diagnostics of JVisualVM are hard to beat).
Despite the supposed language shortcomings of Java (often criticised by those writing smaller programs or who don't realise that features like 'operator overloading' were deliberately omitted as practical experience showed them to be problematic) the language isn't that bad (especially if you have a large team of people with differing skill levels working on a projetc). The real clincher is that the Java libraries (including 3rd-party) and library portability make Java without peer. This is why Java is still King of the Hill in the Enterprise, and likely to stay there for the foreseable future.
Java deliberately avoided operator overloading as it caused horrific problems with C++ programs. Apart from simple cases you could never trust that someone had overloaded the operator to make it work like you thought - you had to laboriously understand each and every place where an operator was used. Operator overloading was a good idea that turned out to be terrible in practice.
You mean like the Java compiler (or the Eclipse or Netbeans incremental compilers)
You have obviously never been on a *huge* software development project. The reason you use accessors and mutators (getters & setters) is so you can change the underlying representation without breaking all the uses in you million lines of code.I've had to make changes to underlying representation without breaking th client contract (signature). This is why such practices are used (plus, these methods are auto-generated by most tools anyway).
I have used C and C++ multiple times to make JNI interfaces with a *lot* of hardware (US $30,000 scientific cameras; all sorts of electronics; closed-source native driver libraries, etc etc). These days JNA can pretty much do the integration I need - meaning, using Java means mixed languages are less necessary than they once were, and Java works just about everywhere (except when deliberately excluded, iOS).
:)
With regard to scalability. I recently did a long contract for a global system for a very large US software company who I cannot yet name (they have hosted services as well as desktop stuff). The scale was massive (so called 'Internet scale'). Here we used Java (mostly intended for Linux given the economics of deploying on thousands of servers). The reasons we used Java were the reason I outlined in my original post: strictness of the language means a large team can work on it and comprehend it and the tools give a lot of support to find obscure bugs (at this scale a one-in-a-million threading issue will swamp tech support with hundreds of occurrences per day). Mixing languages in this environment would be a disaster as would dynamic typed languages. Hence, my comments were made because I am experienced with this stuff.
Thanks for taking the time to make your points known, listen, and discuss rationally - wish it was always like that on Slashdot
My point was that Python is not used to build *huge* applications, simply because it doesn't easily scale that far (humans need help to gr0k the massive). Oh, you don't need C to make Java faster, since except in a few parts of the standard libraries the JVM is generally faster than C (if you want I can give you a link to the report when INRIA, the French scientific supercomputing folks, did tests) and is approaching FORTRAN for speed. With Java you only really needed C/C++ to do JNI native library integration, but with the third-party JNA library don't even need to do that anymore.
Absolutely correct analysis correlating with my experience. It's very hard making a huge program out of C (too many low level details to keep track of, and poor support for mixing multi-threading and memory management). IMHO the 'open' languages you mention are good for small scale stuff but also hard to scale to the huge (the compiler and tools just can't help you get so many things right *before* you compile and before you run). It's unfortunate that fans of languages of Python think that because Python is quick to develop small applications in then it follows that it would be similarly quick to develop a large application in (which is false, since the debugging effort would increase dramatically). The apparent relative 'slowness' of developing in statically-typed languages like C# or Java is mostly because they are more strict, which allows the compiler and tools to help out during development (incremental compilation and error detection). After all, if your program doesn't have to work correctly every time then your development time can be zero and languages like Python or Lua are good choices :)
"Gtk# is an entirely reasonable alternative and more familiar for the non-Windows crowd at which Mono's aimed."
While I understand this position, it is mostly a 'fail' for the Windows C# crowd. Having a non-portable stack is a big issue. Non-portable (ie. non-standardized) libraries means you can't trust whether it is going to be on your *customers* chosen platform or not (and big customers get to chose the platform, not the developer). Trying to sell a Gtk# solution would work in some places, but there are plenty of customers who would reject it out of hand. This means Mono probably will get limited traction in such (enterprise) spaces, especially when Java does the same thing but far more portably (and the niceness of C# syntax is never a customer concern, and any productivity gains are marginal at best - so I doubt real customers would see many upsides to having Mono-based solutions even if developers do).
Those of us that did C and C++ for two (approaching three) decades want to go back to the bad old days of balkanized solution spaces (eg. juggle both WinForms for Windows, Gtk# for Linux, Cocoa bindings for Mac etc etc - possible to do but just a PITA). We're past the point of finding it 'fun' to re-invent solutions for every platform simply because of different/non-portable libraries, and it certainly makes no commercial sense to do this either. Hence a lot of developers have chosen tech where they don't have to do this.
If C# libraries were as portable as Java and supported by the vendor (eg. Microsoft) then C# would be a rational choice and would dominate development - C# has certainly matured and have plenty of time to achieve this. However the Tiobe Index figures show that C# adoption is not growing very rapidly (certainly not as much as its proponents would like). If C# library portability was a design goal then C# would make sense for development on phones and pads (the topic of this Slashdot article). Even Java falls short in this space (although, as Android gets more powerful I expect eventually to be able to run Java SE libraries on Android - I've deployed Java SE applications to far more constrained embedded/Single-board systems than what is available today to host Android). So, C# may be nice but it is never going to be of much interest to Android (and Big Enterprise) developers.
Huh? how do the "arguers" have anything to do with "one language" ? (aside from a commonly used argument). Having a single language that can meet your development needs is a Good Thing (tm). Remember the K.I.S.S. principle? Sounds like you are indeed a teacher of "development" but not a teacher of "design", and good design [rarely taught or learned, especially not in software] aims to simplify where possible - which means "one language" is a good design goal (and it always indicates poor design in an API if a single language cannot be used to solve most common problems).