By: Anonymous (no.delete@this.spam.com), March 3, 2008 2:11 am
Room: Moderated Discussions
JasonB (no@spam.com) on 3/2/08 wrote:
---------------------------
>nordsieck (lesprit.d@gmail.com) on 3/2/08 wrote:
>---------------------------
>>Precisely, but that is the whole point, isn't it?
>
>No, it's not -- otherwise you can say "Java is incredibly efficient" because it
>supports native methods, and you can prove it by writing your entire program in
>C and then having a Java main() method that just calls the C program.
Strawman, no one is trying to say such a thing, they are saying that the HLLs do not have an efficiency problem as soon as you accept that performance critical sections belong in another language.
>The fact that a language allows you to avoid using it for the entire program doesn't
>mean you can apply the attributes of those parts to the language itself. Most
>languages allow you to execute code written in another languages. What is important
>is how well the parts actually written in that language perform.
And?
>
>>There is no payoff to have performance
>>that isn't in the critical path.
>
>Well, in itself it certainly doesn't hurt, but it's also besides the point.
Not if that 'wasted' performance comes at other costs..
>My objection was that you were claiming Python and Ruby are reasonably efficient
>not because they are, but simply because they allows you to write parts in
>another language that is efficient.
No, that is not the claim, the claim is that they are efficient enough for the 90% non performance critical code, and that that code comes at a reduced 'cost' in a number of measurable ways.
>>There is a definite benefit to using high level
>>languages as a default in terms of increased flexibility to iterate, as well as
>>decreased line count (and hence decreased maintenance cost).
>
>I actually think those are overstated.
So what? I manage a rather large software project, multi-year, 90% in python, I actually think you have never tried.
>Iteration times: a simple change of code and a recompile of our software to reflect
>that change takes about 10 seconds, because only the affected unit needs to be recompiled
>and the program isn't very large to relink -- yet this program is still much
>bigger than anything I would contemplate in a scripting language. With Edit and
That would be because you dont have a clue - because you have not tried. I assume you think Chinese is not a good spoken language, because you do not use it also?
>Continue it is even possible to change the source code while debugging and continue
>on, although I normally don't use that -- once you've realised what the problem
>is there is often little point in continuing rather than starting again.
>
>Line count: I just don't see it. Python and C++ have very similar line counts,
Wrong, we find the ratio to be about 1:3, and we use very good C++ programmers. making C++ do its 'nice' stuff is wordy, templates are complex - shall I bring up the joys of debugging them or the joys of their compiler errors?
>with differences being caused by things as trivial as }'s on empty lines. Each language
>has a few standard features that the other lacks that can swing an individual program
>one way or the other, but we're not talking about a huge difference here, and most
We are, but I can see that you have not tried - perhaps you should, or perhaps not, depends on your applications I guess.
>of the work in writing software is not in the physical typing in of the code.
Not, its in the mental tracking of the operation, HLLs enhance that, sometimes significantly.
>Furthermore, static typing does allow a whole class of bugs to be caught
>at compile time that wouldn't be visible unless you happened to trigger them at runtime otherwise.
True, it also comes at a high complexity and implementation cost for many applications - a tradeoff, like many others.
>C++ does have greater scope for writing lousy programs, of course. I prefer not to use this ability. :-)
ah, I see, you easily write perfect code, good for you, many dont.
>>To restate, machine efficiency is only valuable in certain cases. Developer efficiency is valuable in all cases.
>
>To restate: attributes can only be given to a language when they are a property
>of that language, not when they are "inherited" by the language's ability
>to combine programs with code written in another language. Pretty much all
>languages allow that, rendering comparisons meaningless.
Lucky that is not the point here, but you hug your strawman nice and tight, hopefully it will keep you warm and safe.
C++ is good for some applications, python is good for some applications. In my experience the total mass of the second far exceeds that of the first, however neither language is in any way 'better' than the other.
---------------------------
>nordsieck (lesprit.d@gmail.com) on 3/2/08 wrote:
>---------------------------
>>Precisely, but that is the whole point, isn't it?
>
>No, it's not -- otherwise you can say "Java is incredibly efficient" because it
>supports native methods, and you can prove it by writing your entire program in
>C and then having a Java main() method that just calls the C program.
Strawman, no one is trying to say such a thing, they are saying that the HLLs do not have an efficiency problem as soon as you accept that performance critical sections belong in another language.
>The fact that a language allows you to avoid using it for the entire program doesn't
>mean you can apply the attributes of those parts to the language itself. Most
>languages allow you to execute code written in another languages. What is important
>is how well the parts actually written in that language perform.
And?
>
>>There is no payoff to have performance
>>that isn't in the critical path.
>
>Well, in itself it certainly doesn't hurt, but it's also besides the point.
Not if that 'wasted' performance comes at other costs..
>My objection was that you were claiming Python and Ruby are reasonably efficient
>not because they are, but simply because they allows you to write parts in
>another language that is efficient.
No, that is not the claim, the claim is that they are efficient enough for the 90% non performance critical code, and that that code comes at a reduced 'cost' in a number of measurable ways.
>>There is a definite benefit to using high level
>>languages as a default in terms of increased flexibility to iterate, as well as
>>decreased line count (and hence decreased maintenance cost).
>
>I actually think those are overstated.
So what? I manage a rather large software project, multi-year, 90% in python, I actually think you have never tried.
>Iteration times: a simple change of code and a recompile of our software to reflect
>that change takes about 10 seconds, because only the affected unit needs to be recompiled
>and the program isn't very large to relink -- yet this program is still much
>bigger than anything I would contemplate in a scripting language. With Edit and
That would be because you dont have a clue - because you have not tried. I assume you think Chinese is not a good spoken language, because you do not use it also?
>Continue it is even possible to change the source code while debugging and continue
>on, although I normally don't use that -- once you've realised what the problem
>is there is often little point in continuing rather than starting again.
>
>Line count: I just don't see it. Python and C++ have very similar line counts,
Wrong, we find the ratio to be about 1:3, and we use very good C++ programmers. making C++ do its 'nice' stuff is wordy, templates are complex - shall I bring up the joys of debugging them or the joys of their compiler errors?
>with differences being caused by things as trivial as }'s on empty lines. Each language
>has a few standard features that the other lacks that can swing an individual program
>one way or the other, but we're not talking about a huge difference here, and most
We are, but I can see that you have not tried - perhaps you should, or perhaps not, depends on your applications I guess.
>of the work in writing software is not in the physical typing in of the code.
Not, its in the mental tracking of the operation, HLLs enhance that, sometimes significantly.
>Furthermore, static typing does allow a whole class of bugs to be caught
>at compile time that wouldn't be visible unless you happened to trigger them at runtime otherwise.
True, it also comes at a high complexity and implementation cost for many applications - a tradeoff, like many others.
>C++ does have greater scope for writing lousy programs, of course. I prefer not to use this ability. :-)
ah, I see, you easily write perfect code, good for you, many dont.
>>To restate, machine efficiency is only valuable in certain cases. Developer efficiency is valuable in all cases.
>
>To restate: attributes can only be given to a language when they are a property
>of that language, not when they are "inherited" by the language's ability
>to combine programs with code written in another language. Pretty much all
>languages allow that, rendering comparisons meaningless.
Lucky that is not the point here, but you hug your strawman nice and tight, hopefully it will keep you warm and safe.
C++ is good for some applications, python is good for some applications. In my experience the total mass of the second far exceeds that of the first, however neither language is in any way 'better' than the other.
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 04:24 AM |
And the links.. | Anders Jensen | 2008/02/14 04:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 10:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 11:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 05:43 PM |
Disappointing.. | David Patterson | 2008/02/15 11:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 05:01 PM |
Disappointing.. | anon | 2008/02/15 08:54 PM |
Disappointing.. | JasonB | 2008/02/19 07:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 06:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 11:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 06:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 11:41 AM |
Disappointing.. | Zan | 2008/02/25 10:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 09:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 06:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 01:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 10:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 01:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 08:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 01:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 10:04 AM |
And the links.. | Howard Chu | 2008/02/14 12:58 PM |
I take some of that back | Howard Chu | 2008/02/14 01:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 02:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 02:24 PM |
And the links.. | iz | 2008/02/17 10:55 AM |
And the links.. | JasonB | 2008/02/17 07:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:54 PM |
And the links.. | JasonB | 2008/02/18 10:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 07:01 PM |
And the links.. | iz | 2008/02/20 10:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:37 PM |
And the links.. | JasonB | 2008/02/20 06:28 PM |
And the links.. | JasonB | 2008/02/17 06:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 02:27 PM |
And the links.. | JasonB | 2008/02/18 10:00 PM |
And the links.. | JasonB | 2008/02/19 03:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 04:29 PM |
And the links.. | JasonB | 2008/02/20 06:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 11:07 AM |
And the links.. | Howard Chu | 2008/02/14 01:16 PM |
And the links.. | Jukka Larja | 2008/02/15 03:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 11:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 12:49 PM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 03:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 05:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 09:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 04:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 10:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 01:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 12:44 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 03:25 PM |
Average programmers | anon | 2008/02/18 12:40 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 08:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 03:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 06:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 03:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 03:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 05:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 01:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 02:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 08:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 08:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 05:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 06:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 02:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 09:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 09:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 01:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 02:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 04:35 AM |
C++ for beginners | Michael S | 2008/03/10 05:16 AM |
C++ for beginners | JasonB | 2008/03/10 06:35 AM |
C++ | Michael S | 2008/03/10 04:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 11:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 02:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 03:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 08:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 01:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 08:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 08:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 11:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 02:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 04:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 03:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 09:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 01:23 AM |
efficient HLL's | Michael S | 2008/03/05 02:45 AM |
efficient HLL's | Wilco | 2008/03/05 05:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 07:11 PM |
efficient HLL's | Wilco | 2008/03/06 02:27 PM |
efficient HLL's | anon | 2008/03/05 08:20 AM |
And the links.. | Groo | 2008/02/17 04:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 02:33 AM |