 Joel on Programming Languages
started 5/6/2002; 2:23:37 AM - last post 6/2/2002; 11:27:57 PM
|
|
Dan Shappir - Joel on Programming Languages 
5/6/2002; 2:23:37 AM (reads: 2458, responses: 10)
|
|
| Joel on Programming Languages |
|
Why do developers choose one programming language over another for a given task?
Nothing very deep or new in this post, but it does demonstrate how one particular developer selects a programming language for a specific task (and he will probably get flamed for his choices.) Also brings up this issue of whether .NET languages just differ on syntax and what added benefits they provide. Both of these points have been previously debated here.
And for an initial critique:
Sometimes I choose raw C when I need blazing speed.
See language myth number 9.
Posted to critiques by Dan Shappir on 5/6/02; 2:24:31 AM
|
|
|
|
Ehud Lamm - Re: Joel on Programming Languages
5/6/2002; 6:07:41 AM (reads: 1888, responses: 0)
|
|
|
I wonder what the .Net guy are going say about this.
|
|
Chris Rathman - Re: Joel on Programming Languages
5/6/2002; 6:35:29 AM (reads: 1878, responses: 1)
|
|
|
Personally, I think the reason you choose C has more to do with how close you must operate to the hardware, rather than being a function of speed.
I also think that multi-language support is as much a marketing gimic as it is a technical achievement. Similar to C's closeness to the hardware, if you really need to get the maximum utility out of .Net, then you're probably best off using C# - since it is the closest in terms of the machine architecture.
|
|
Ehud Lamm - Re: Joel on Programming Languages
5/6/2002; 7:39:12 AM (reads: 1969, responses: 0)
|
|
|
Often (but not always, of course) being close to the hardware buys you some speed advantage.
Alas when the hardware becomes complicated (think caching, register windows etc.) the compiler usually understands the hardware better than you do...
|
|
Adam Vandenberg - Re: Joel on Programming Languages
5/6/2002; 10:50:31 AM (reads: 1866, responses: 0)
|
|
|
The only thing I've chosen C for recently is for some hobby Game Boy Advance programming. The only other reasonable choice I had found was C++, and there is always the (unreasonable, at least for me) choice of doing Arm/Thumb assembly.
I wouldn't mind using C++, but I don't yet understand how C++'s runtime works on GBA hardware. Specifically, how do I set the location and size of the heap, and how do I monitor heap usage at runtime (given that the GBA has two fixed-sized smallish chunks of RAM, you need to be very aware of how much memory your level is going to take at it's "most busy" point.)
|
|
Ehud Lamm - Re: Joel on Programming Languages
5/7/2002; 12:42:16 AM (reads: 1803, responses: 0)
|
|
|
|
Wilhelm Fitzpatrick - Re: Joel on Programming Languages
5/7/2002; 4:44:08 PM (reads: 1739, responses: 0)
|
|
|
Okay, the response was claiming 4-6x greater velocity for the .NET team for the Java and C++ teams. Now I recall reading lots similar claims in the early days of Java where Java teams were blowing the doors off stodgy C++ teams to the same degree. So it leads me to wonder, is it just that the .NET team is excited because they have new toys to play with so they are working faster, and in a few months they will get bored and slow down? Is language productivity effect just a special case of the "new management" productivity effect?
In which case we should switch to a new language and platform for every project in order to keep the level of novelty high!
|
|
scruzia - Re: Joel on Programming Languages
5/7/2002; 7:19:42 PM (reads: 1731, responses: 0)
|
|
|
It ain't the tools: the results of one study (I vaguely recall) showed that programming teams got higher productivity if they knew they were being measured.
|
|
Isaac Gouy - Re: Joel on Programming Languages
6/2/2002; 10:21:31 AM (reads: 1553, responses: 0)
|
|
|
Joel states which programming languages he selects for a specific task, and adds a little ad hoc justification. He doesn't say which other programming languages he might have used for a particular task.
"I choose raw C when I need blazing speed"
Do C optimizing compilers produce the fastest executables compared to other high-level languages?
It used to be true that Modula-2 compilers were able to produce faster executables - the Modula-2 compiler could do more optimization because the language specification is more precise.
Do we lose any insights from Joel's posting if we say this instead - I choose a language with a fantastic optimizing compiler when I need blazing speed.
"For a command-line tool that must run on any UNIX machine and doesn't need to be fast, perl is a good choice"
Do we lose any insights from Joel's posting if we say this instead -
For a command-line tool that must run on any UNIX machine and doesn't need to be fast, a unix scripting language is a good choice.
Paul Graham seems to deliver more insight into why one programming language is more powerful than another http://www.paulgraham.com/icad.html
|
|
Isaac Gouy - Re: Joel on Programming Languages
6/2/2002; 12:54:51 PM (reads: 1560, responses: 1)
|
|
|
"Sometimes I choose raw C when I need blazing speed"
It seems that if you are an "average programmer" you are more likely to get speed from using Lisp!
"although execution times of the
fastest C and C++ programs were faster than
the fastest Lisp programs, the runtime performance
of the Lisp programs in the aggregate
was substantially better than C and C++ (and
vastly better than Java). The median runtime
for Lisp was 30 seconds versus 54 for C and
C++. The mean runtime was 41 seconds versus
165 for C and C++. Even more striking is
the low variability in the results. The standard
deviation of the Lisp runtimes was 11 seconds
versus 77 for C and C++."
http://www.flownet.com/gat/papers/lisp-java.pdf
|
|
Ehud Lamm - Re: Joel on Programming Languages
6/2/2002; 11:27:57 PM (reads: 1600, responses: 0)
|
|
|
Notice that there are methodological objections to this study (a search should give you plenty of valid objections). This says nothing about truth of the conclusions, of course.
Studies of this kind are very suspect. I think this is one reason why PL researchers prefer to study pure theory...
|
|
|
|