I don't think a clean, elegant design was ever the goal. It was built as a practical set of design compromises to fill the needs of the industry at the time.

I think it is worth pointing out that there are plenty of languages that took the non-compromising approach and have fallen into obscurity while C++ took off. In the end it was the compromises of C++ that the software industry as a whole actually wanted. C++ for a long time has provided tools such as std::string and std::vector, to mitigate/eliminate the risk of buffer overflow vulnerabilities. The C string functions are terribly designed, but programmers wanted to and chose to continue to use them, that's not the fault of C++.

Personally I'll take the productivity and maintainability of Java/C# over C++ if I can. When I can't though, C++ isn't a bad option. It certainly has its pitfalls/complexity. Some were bad design choices (e.g. exceptions can throw any type). Some were unavoidable (e.g. the interplay of virtual functions/inheritance with in place allocation). Some are technical debt.

No they didn't: http://doc.rust-lang.org/compl...

Presumably the women he raped, who then bore sons for him didn't take on his last name. (That is if he had a last name)

I fitted a simple exponential curve. Assuming 800 years have passed, and one new generation is formed every 20 years we get the range t : [0,40]. Assuming for f(t): f(0) = 1 and f(40) = 17.5m, I get f(t) = e^(0.181076t). This means the ratio of f(t+1):f(t) is ~1.5, so each generation would have to leave about 1.5 male descendants.

I'm confused to what you mean by .Net not having more popularity in other countries. Do you mean, you expect that it would enjoy (even) greater popularity levels than it does in English speaking countries?

The simple answer to that is there are more important factors (fitness for task at hand .etc.) in influencing language choice. Where I am (Japan) .Net and Java have plenty of popularity, although nobody writes identifier names in non-ASCII characters. Conversly, desktop Linux which has rather poor Japanese support (Buggy, sub-standard input methods, poor translations, and painful font support) seems (I have no statistics) to have less popularity.

Learning a language is a multi-year undertaking full stop (unless you already speak a closely related language) and novels are generally the most difficult reading materials. Even learning German or French, I expect it would take several years of study to reach the point where I could read a novel.

I imagine the Chinese and Koreans do that as well. The characters used to write names are part of people's identity and generally carefully selected by parents. There can be literally hundreds of different ways to write the same name in Japanese. 'Kazuo' is a good example. The name itself simply means first born (son) but there are many different choices of characters to represent it, with the characters for either 'one' or 'harmony' (wa) being common choices to write 'kazu'

I couldn't agree more. Language and orthography are fascinating topics, intrinsically linked with culture.

Yeah sure, it's not an iron rule. I could name plenty of exceptions as well, but its pretty damn consistent. Most of the exceptions are words formed by combining Japanese words, or using kanji for their phonetic value (e.g. country names) rather than words formed from Chinese character roots.

Chinese characters aren't that hard to learn. I learnt them (a subset anyway) while learning Japanese. It took about 3 years of reasonably intense study to be able to pick up and read a novel without too much difficulty. After 2 years I could generally approach newspaper articles. Newspapers are generally one of the easiest written mediums to approach. While there are several thousand characters in use, there is a relatively small subset of frequently used characters. Additional most characters are formed in a regular fashion from simpler characters. Probably the most common form being one phonetic part to indicate the reading and one semantic part to indicate the meaning.

Chinese (apparently) has more characters in common use than Japanese but the difficulty does not scale linearly with the number of characters and Japanese adds the significant complication of having phonetic (Chinese derived) readings and often multiple, irregular native Japanese readings per character, and huge numbers of irregular readings for combinations of characters.

One interesting side affect of characters having semantic meaning is that it often makes the meaning of words even new to the reader, immediately obvious. Especially for science and technology related vocabulary the meanings of words rendered in Chinese characters is often much clearer and more immediately obvious than that of English words derived from Latin/Greek. As an extreme example I can often comprehend Chinese (esp. when written in traditional characters) even though I do not speak Chinese

The equator runs through Indonesia. Most poor countries (and most countries full stop) are north of the equator.

Maybe I'm missing the joke but how did Newton do that in the 17th century?

One interesting piece of history about this project is that they switched from using C/GTK to using C++/QT recently and apparently with very good results. Especially interesting given the way Linus' past comments on C++ have been so widely replayed.

here's a link to the talk: https://m.youtube.com/watch?v=...

If it is a real trend and a real statistic then please link to some reference for this. I'm interested to see. Maybe I'm not very good at Google searches but I cannot find any reliable statistics to support this.

I code mostly in C++ and C# and have no trouble at all with C#. It's one of my favourite languages. My post however was not about myself, I was paraphrasing the original question, as perhaps I've missed something but the statement "why you are asking for citation when the whole discussion is sort of based on this issue" is completely at odds with how I read the original question - i.e. (very much paraphrasing here) 'Should I learn C# it seems to be the way forward'

Though even if your interpretation of the original question is correct, it would still not seem unreasonable to ask for a reference to support the statement that .NET is losing popularity. The only evidence of this "fact" I can see on this thread is mis-matched anecdotes, hence my reply to your post.

Replying to myself but I also think ref/out parameters are worth mention :)

I'm not the OP but while Java is not a bad programming language at all, in my opinion C# is much nicer. It is pretty much Java but with more features and candy. Java has finally caught up with a few of the big ones - e.g. lambdas, try-resource to match C#'s using blocks, the streaming API to kind of capture part of LINQ's functionality and default methods to kind of match extension methods as a way to do mixins.

It's still lacks a lot of features though - e.g. generics with support for unboxed types and runtime type checking, unsigned types, stack allocated arrays/structs, support for unsafe code and pointers, coroutines, type inference on variable declerations, properties and property initializer syntax, operator overloading, language level support for async programming constructs, nullable types and the '??' operator, dynamic types, .etc. C# 6 will also be adding the '.?' to allow propagation of null through chained methods

In addition to this I feel like the core .NET libraries have generally benefited from the hindsite of seeing where Java went wrong / could be improved on.

Agreed about the docs. MSDN documentation in general is horrendous. It lacks critical information and is generally written in a completly impenetrable way. They also rely on crappy machine translation for non-English languages, ugh.

There is one good reason for avoiding checked exceptions though. Interfaces. In Java it is required that either 1. all exceptions that might ever be thrown by implementations of an interface be declared at the interface decleration or 2. all exceptions be bundled in RuntimeExceptions to short circuit the checked exception mechanism anyway (with the potential side effect of ruining stack traces).

As far as catching exceptions go, imo unless you are going to do something specific to deal with an exception, then catching it is bad coding practice. E.g. Catching a SocketException to implement retry logic - sure go for it. Catching an exception to log it and rethrow (or worse throw your own custom exception and ruin the stack trace) - do this as high up the call stack as possible.