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.