By: JasonB (no.delete@this.spam.com), March 2, 2008 4:26 pm
Room: Moderated Discussions
Dean Kent (dkent@realworldtech.com) on 3/2/08 wrote:
---------------------------
>Because of the expertise in the shop with assembler, C actually was less efficient
>in terms of developer time.
That is unsurprising and I think will always be the case, regardless of what two technologies you are comparing. There are no silver bullets in software development, and I doubt there will ever be a new tool that is so much of a step-change that new users will be immediately more productive than experienced users of the older technology.
You need to put a bit of effort in to determine whether you will actually be more productive in the long run, how much more productive you will be, how long it will take to get there, and finally, whether it is worth it.
>With extensive use of macros (IBM's macro facility
>is quite advanced and flexible) and reusable modules, there was no advantage to using C for us.
Actually, from what I've seen you post of IBM's macro facility in the past it's dangerously close to C already, so the only real difference is portability. To have a real shot at improving developer time you need a much bigger change than that, although how long it takes to get productive with the new tool may not be worth the effort, and some developers may not even be able to make the transition.
>So - the bottom line is, for a C expert all other languages have limitations.
>The same is true for an assembler expert.
C and assembler also have limitations in that respect; it is not as if going down the language hierarchy you progressively remove limitations, you just have different ones.
>Yet, other languages continue to be developed
>and be popular. Eventually, C will be relegated to the same kind of niche as other
>once popular languages have been, I predict.
For most of us C is already the assembler language of the modern world, and has been for a couple of decades. The big advantage it has over other assembler languages is that it is portable. If you want to write a compiler for a new language, you could do worse than emitting C code. (C++ started that way, and a whole bunch of tools like flex and bison do exactly that.)
All of these languages are Turing-complete, so you can express any program in any of them. It's just a question of how efficiently you can do so. Since C (and, obviously, assembler) allow you to get close to the metal, you can get a very efficient representation for the particular hardware the program is going to run on.
I would hope that language development continues and older languages fall by the wayside, but I don't expect major changes any time soon.
BTW, one interesting observation that my former professor made to me the other day was that it has been a long time since a successful new language came from academia rather than the corporate sector. I also note that the differences between languages has been minor for quite a long time now -- it's like the programming language "Cambrian explosion" ended a few decades ago and all the programming language "body plans" were established during that time, and we've since settled down into a steady evolution of languages that are gradual refinements of those that already exist. (By that I don't mean that the differences between Lisp and C++ are minor, but rather that all the new languages aren't very different from some existing language. There are obviously very good reasons for this, but the downside is that it's even less likely that things will improve radically soon.)
---------------------------
>Because of the expertise in the shop with assembler, C actually was less efficient
>in terms of developer time.
That is unsurprising and I think will always be the case, regardless of what two technologies you are comparing. There are no silver bullets in software development, and I doubt there will ever be a new tool that is so much of a step-change that new users will be immediately more productive than experienced users of the older technology.
You need to put a bit of effort in to determine whether you will actually be more productive in the long run, how much more productive you will be, how long it will take to get there, and finally, whether it is worth it.
>With extensive use of macros (IBM's macro facility
>is quite advanced and flexible) and reusable modules, there was no advantage to using C for us.
Actually, from what I've seen you post of IBM's macro facility in the past it's dangerously close to C already, so the only real difference is portability. To have a real shot at improving developer time you need a much bigger change than that, although how long it takes to get productive with the new tool may not be worth the effort, and some developers may not even be able to make the transition.
>So - the bottom line is, for a C expert all other languages have limitations.
>The same is true for an assembler expert.
C and assembler also have limitations in that respect; it is not as if going down the language hierarchy you progressively remove limitations, you just have different ones.
>Yet, other languages continue to be developed
>and be popular. Eventually, C will be relegated to the same kind of niche as other
>once popular languages have been, I predict.
For most of us C is already the assembler language of the modern world, and has been for a couple of decades. The big advantage it has over other assembler languages is that it is portable. If you want to write a compiler for a new language, you could do worse than emitting C code. (C++ started that way, and a whole bunch of tools like flex and bison do exactly that.)
All of these languages are Turing-complete, so you can express any program in any of them. It's just a question of how efficiently you can do so. Since C (and, obviously, assembler) allow you to get close to the metal, you can get a very efficient representation for the particular hardware the program is going to run on.
I would hope that language development continues and older languages fall by the wayside, but I don't expect major changes any time soon.
BTW, one interesting observation that my former professor made to me the other day was that it has been a long time since a successful new language came from academia rather than the corporate sector. I also note that the differences between languages has been minor for quite a long time now -- it's like the programming language "Cambrian explosion" ended a few decades ago and all the programming language "body plans" were established during that time, and we've since settled down into a steady evolution of languages that are gradual refinements of those that already exist. (By that I don't mean that the differences between Lisp and C++ are minor, but rather that all the new languages aren't very different from some existing language. There are obviously very good reasons for this, but the downside is that it's even less likely that things will improve radically soon.)
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 03:24 AM |
And the links.. | Anders Jensen | 2008/02/14 03:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 09:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 10:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 04:43 PM |
Disappointing.. | David Patterson | 2008/02/15 10:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 04:01 PM |
Disappointing.. | anon | 2008/02/15 07:54 PM |
Disappointing.. | JasonB | 2008/02/19 06:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 05:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 10:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 05:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 10:41 AM |
Disappointing.. | Zan | 2008/02/25 09:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 08:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 05:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 12:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 09:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 12:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 07:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 12:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 09:04 AM |
And the links.. | Howard Chu | 2008/02/14 11:58 AM |
I take some of that back | Howard Chu | 2008/02/14 12:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 01:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 01:24 PM |
And the links.. | iz | 2008/02/17 09:55 AM |
And the links.. | JasonB | 2008/02/17 06:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 12:54 PM |
And the links.. | JasonB | 2008/02/18 09:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 06:01 PM |
And the links.. | iz | 2008/02/20 09:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 02:37 PM |
And the links.. | JasonB | 2008/02/20 05:28 PM |
And the links.. | JasonB | 2008/02/17 05:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:27 PM |
And the links.. | JasonB | 2008/02/18 09:00 PM |
And the links.. | JasonB | 2008/02/19 02:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:29 PM |
And the links.. | JasonB | 2008/02/20 05:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 10:07 AM |
And the links.. | Howard Chu | 2008/02/14 12:16 PM |
And the links.. | Jukka Larja | 2008/02/15 02:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 10:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 11:49 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 02:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 04:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 08:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 03:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 09:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 12:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 11:44 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 02:25 PM |
Average programmers | anon | 2008/02/18 11:40 AM |
Berkeley View on Parallelism | JasonB | 2008/02/15 07:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 07:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 07:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 02:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 05:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 02:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 02:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 04:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 12:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 01:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 06:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 07:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 04:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 05:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 01:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 08:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 08:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 12:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 01:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 03:35 AM |
C++ for beginners | Michael S | 2008/03/10 04:16 AM |
C++ for beginners | JasonB | 2008/03/10 05:35 AM |
C++ | Michael S | 2008/03/10 03:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 10:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 01:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 02:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 07:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 12:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 06:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 07:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 10:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 01:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 03:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 02:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 08:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 12:23 AM |
efficient HLL's | Michael S | 2008/03/05 01:45 AM |
efficient HLL's | Wilco | 2008/03/05 04:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 06:11 PM |
efficient HLL's | Wilco | 2008/03/06 01:27 PM |
efficient HLL's | anon | 2008/03/05 07:20 AM |
And the links.. | Groo | 2008/02/17 03:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 01:33 AM |