http://ask.slashdot.org/article.pl?sid=06/06/12/2044245

The End of Native Code?
Posted by Cliff on Monday June 12, @08:15PM
from the maybe-not-JITs-yet dept.
Programming

psycln asks: "An average PC nowadays holds enough power to run complex
software programmed in an interpreted language which is handled by
runtime virtual machines, or just-in-time compiled. Particular to Windows
programmers, the announcement of MS-Windows Vista's system requirements
means that future Windows boxes will laugh at the memory/processor
requirements of current interpreted/JIT compiled languages (e.g. .NET,
Java , Python, and others). Regardless of the negligible performance
hit compared to native code, major software houses, as well as a lot
of open-source developers, prefer native code for major projects even
though interpreted languages are easier to port cross-platform, often
have a shorter development time, and are just as powerful as languages
that generate native code. What does the Slashdot community think of the
current state of interpreted/JIT compiled languages? Is it time to jump
in the boat of interpreted/JIT compiled languages? Do programmers feel
that they are losing - an arguably needed low-level - control when they
do interpreted languages? What would we be losing besides more gray hair?"


e:What else
(Score:5, Interesting)
by julesh (229690) on Tuesday June 13, @07:14AM (#15522841)


recommend getting that looked at.

The question you have to ask, of course, is where is the bottleneck. And
the answer is fairly obvious if you analyse the performance of modern
applications on a variety of different hardware: IO is the bottleneck in
almost every case. There's no other explanation for why my 400MHz desktop
(with a nice, fast hard disk) performs as well as or better than my 1.7GHz
laptop (with a slow, energy saving hard disk but otherwise similar specs)
for many applications (including Firefox, OpenOffice, etc... the kind
of things that the average user runs daily) while the laptop wipes the
floor with it for others (media players, SketchUp).

The point is, if you're going to be waiting 50ms for disk access, why
bother shaving 2ms of processing time by running in a native compiled
language? Nobody will ever notice. And you may find the more modern
and high-level design of the interpreted language's library allows
you to write faster performing IO code more easily than the simple &
low level libraries that are supplied with most compiled languages, at
which point you may get better results for the same programming effort
for using that language.

In the end, fast programs are about good design, not language
choice. Higher level languages often allow you to spend more time
on design and less on implementation. All real-world projects have a
limited time scale; ISVs just try to do the best they can with the time
they have available, which isn't usually producing something miraculous.



you'll learn
(Score:4, Insightful)
by m874t232 (973431) on Tuesday June 13, @09:03AM (#15523284)
If your native code is running as slow as interpreted, I would really recommend getting that looked at. It would seem that people are losing the ability to write clean code since the crutch of interpreted languages is hiding so much of the finer grains of computer science.

First of all, when experienced programmers write big systems in interpreted languages, you can rest assured that they know what they are doing and are doing the benchmarks to make sure they aren't losing performance where they need it. If they need special, high-performance algorithms or libraries, they will figure out the minimal set of C/C++ primitives they need and make them a native code library inside the scripting language.

And whether code is "clean" really has nothing to do with the language. People can write clean Perl code and unclean C code.

Finally, "the finer grains of computer science" are absolutely and positively not concerned with the kind of low-level mess that C exposes.

I'm currently working on learning SDL in C/C++ for exactly that reason.

Good, so you are in a very early stage of your development as a programmer. As you mature, you'll figure out how to get the job done without wasting all your time on C/C++ programming.

In general, when experienced programmers use languages like Python or Ruby with native code plug-ins, or when they use languages like Java or C#, they produce code with better performance and fewer bugs than straight C/C++, simply because they end up having more time implementing good data structures and focussing their efforts where it counts.