• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

C/C++ vs. Java vs. C#

Thanks all for the replies about threading, I'm trying to digest all that information.

It looks like native language threading (which is what I meant with native anyway) or thread-safe libraries is no holy grail, mainly because of bad performance. So it's at this point definitely not a decisive reason to choose for Java.

You can indeed hide locking nicely in C++ classes, but it get's bad for performance if you have to scale over more than a few threads in my experience. That's probably why in our software here at work concurrency is done in a number of different ways. Functionality is split over a number threaded processes that use message passing and load-balancing. I guess it will stay like that for the near future, the solution probably won't come from the programming language then.
 
dahduh said:
This is something I was never able to figure out. A supercoder can be easily 20x more productive than an average programmer and churn out much cleaner code. So what's the secret, and how do you find them? I eventually gave up entirely on interviews, qualifications and experience, and just said "show me your code". The great coders whip out 100,000 lines they wrote at home and the not so great mumble something about 'proprietary'. Unfortunately when you impose this filter employment agencies stop sending you people.
There is certainly a lot of truth in this. However, I have had the displeasure of attempting to maintain code written by fabled superprogrammers and it was a nightmare. Sometimes the 100,000 lines of code is written quickly, but at the expense of the poor schmuck to follow.

A lot of it has to do with style. We had a thread awhile ago about commenting style, for example, and there was much disagreement about the best way to comment code.

Another problem I've seen has to do with how people view the structure of code. I wrote a lot of code in Bliss, which is an expression language (like Lisp). That means that everything is an expression; there are no statements that cannot be used as expressions. So what do you think of this:
Code:
  x := f(y, (for i := 1; i <= n; ++i do
              exit i if a[i] = 0));
Is that good code? A couple of people reamed me for coding like that. "Oh," I said, "we're not really supposed to follow the philosophy of the language, I guess."

~~ Paul
 
This is something I was never able to figure out. A supercoder can be easily 20x more productive than an average programmer and churn out much cleaner code. So what's the secret, and how do you find them? I eventually gave up entirely on interviews, qualifications and experience, and just said "show me your code". The great coders whip out 100,000 lines they wrote at home and the not so great mumble something about 'proprietary'. Unfortunately when you impose this filter employment agencies stop sending you people.

My experience is limited (fortunately!) - but I have a thought on the matter: An average programmer will come up with a way to make his code work. A great programmer will come up with many ways to make his code not fail.

For example, if you ask a programmer to come up with a simple routine - say, a ToUpper(char c). An average programmer will whip up a few lines - convert the char to a byte and add 32 (or subtract? whatever), for example. If you point out that this won't give the right result for numbers or letters that are already uppercase, he'll get sullen and say "well, you didn't tell me it had to handle those."

A really good programmer will say "okay, you add 32, or just binary-OR 20h, or use a lookup table, or build a little logic structure with a few 'if' statements, but - are we space limited, or speed critical, or what? And will it only be passed lower-case letters, or does it have to handle uppercase letters? And what if the calling routine sends it something that's not a letter, or isn't a printable character? Should it throw an error, or return a #32, or what?"

That's the one who's thinking through all the ways that his code might mess up the app before he/she starts typing. That's the one you want.
 
There is certainly a lot of truth in this. However, I have had the displeasure of attempting to maintain code written by fabled superprogrammers and it was a nightmare. Sometimes the 100,000 lines of code is written quickly, but at the expense of the poor schmuck to follow.
The problem there is fabled.
 
There is certainly a lot of truth in this. However, I have had the displeasure of attempting to maintain code written by fabled superprogrammers and it was a nightmare. Sometimes the 100,000 lines of code is written quickly, but at the expense of the poor schmuck to follow.

Manager: "We need it by next week."

Engineer: "I can do that, but it will be hard to maintain and modify, and in the long run it will cost you more than if I do it right. That will take about a month."

Manager: "Can you finish by Thursday?"
 
Manager: "Can you finish by Thursday?"

Engineer: "All righty then. I'll start coding now while you go off and write the spec."

[with apologies to Dilbert]

~~ Paul
 

Back
Top Bottom