The End of Native Code?

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?"

Comments

What else

[Anonymous Coward]

We might be loosing our ability to spell the verb "lose".

No, wait, too late.

Re:What else

[eonlabs]

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. Sure, if you're writing apps that are fine slow, interpreted doesn't matter. If you're writing higher end programs like games, I would recommend cross-platform libraries in a native language. I'm currently working on learning SDL in C/C++ for exactly that reason.

Re:What else

[fyngyrz]

It's maroon if you red carefully, anyway.

Re:What else

[julesh]

If your native code is running as slow as interpreted, I would really 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.

Re:What else

[petermgreen]

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.
what they will notice is when the gc decides it needs to scan a memory area that has been swapped out crowding out any other IO on the system.

Average performance only matters for a few time consuming tasks (and they do still exist), what matters far more in end user apps is any apparent hangs, if a button takes 100ms to get a response i probablly won't notice unless i'm gaming. if a button takes 10ms 99% of the time and 1 second the rest then i damn well will notice despite the better average performance, app startup time is also a killer in terms of percived perfomance (and languages like java are terrible for this especilly the first run on boot).

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.
java.io really sucks for some types of apps as it basically forces you to have one thread per socket and the new java.nio isn't really any higher level than bsd sockets. I don't know what the situation is like over in .net land though maybe its better there.

Have you tried coding anything hard?

[Anonymous Coward]

When your web-based-datastore gets 50,000 inserts per second, hovers between 15 and 20 billion rows and endures a sustained query rate of 43,000 queries per hour, tell me which part of it you want to coded in PHP.

Re:Have you tried coding anything hard?

[Hamled]

The blinking lights, obviously!

But seriously, I like the Python model of "code the performance intensive parts in lower-level languages, code the rest in higher level languages that control it." If using an interpreted language would afford you more flexibility, more powerful language constructs, and faster development times, without much negative impact on parts of your system that are not performance-critical, it's almost a no-brainer to use them for those areas.

Re:Have you tried coding anything hard?

[kpharmer]

> When your web-based-datastore gets 50,000 inserts per second, hovers between 15 and 20 billion rows and endures a sustained query rate
> of 43,000 queries per hour, tell me which part of it you want to coded in PHP.

hmm, the warehouse I work on has multiple databases with billions of rows in them, can hit insert rates of 100,000 rows a second, can experience 60,000 queries/hour - many of which are trending data over 13 months, has hundreds of users. Many of these users are allowed to directly hit some of the databases with whatever query tool they want. Scans of a hundred million rows at a time aren't uncommon (though seldom happen more than a few dozen times a day).

This app is completely written in korn shell, python, php and sql (db2). Looks like Ruby is also coming into the picture now, will probably supplant much of the php in order to improve manageablity.

Oh yeah, and the frequency of releases is quick and it's defect rate is low. And we're planning to begin adding over 400 million events a day soon. I've done similar projects in C and java. Never anywhere near as successfully as in python and php.

We might consider rewriting a few select python classes in c. Maybe, if we port the ETL over to the Power5 architecture with psycho doesn't run. Otherwise, it's cheaper to just buy more hardware at this point - since each ETL server can handle about 3 billion rows of data/day with our python programs.

Re:Have you tried coding anything hard?

[JoshRosenbaum]

I think you guys are missing the original poster's point. I think he is using the standard "right tool for the right job" line. He is saying that the db system shouldn't be an interpreted language since performance is very important there. That is the one system you probably wouldn't want to be in PHP. (Disclaimer: I'm just clarifying what I guess to be their point.)

BTW: I use Perl with Postgres, and yes, I wouldn't want Postgres to be wrote in Perl or PHP. I do, however, love using Perl for most everything else.

Re:Have you tried coding anything hard?

[fozzy1015]

I'm still not convinced. I work for a huge telecom company(think recent merger) which builds Enterprise-level network switches. We use C and C++. We have a 800mhz Freescale PPC to work with and 256mb of 333mhz DDR memory. On our edge routers that's it. On our core switches each blade has it's own PPC processor to interact with the switching ASIC from another company.

So we have decent processing power but I can't imagine trying to do what we do in Java. We basically analyze packet headers, figure out where they're suppose to go, and then copy the packet to the right port. If there was an integeral GUI component then I could see a point in Java. Automatic garbage collection would be nice but probably not worth the speed hit. We already have code in place to help from memory leaks occuring.

There's also a team at work that's working on a network management program all in Java. One PC to control an entire network of switches and computers through SNMP. There's been issues with GUI control placement across platforms. The thing is a resource hog and it's recommended to have at least a gig of memory or more. And even though it's programmed in Java and has touted as cross platform compatible it's developed and tested in Windows and hence runs best in it. And besides, how much more cost effective can you get then a cheap PC running Windows?

I still see embedded applications being dominated by lower-level code for a while. An engineer I worked with left the company for a job working on medical devices. Development is in C++.

Re:Have you tried coding anything hard?

[Fulcrum of Evil]

the warehouse I work on has multiple databases with billions of rows in them, can hit insert rates of 100,000 rows a second, can experience 60,000 queries/hour

cans of a hundred million rows at a time aren't uncommon (though seldom happen more than a few dozen times a day).

Yes they are. Go read what you wrote.

This app is completely written in korn shell, python, php and sql (db2).

One guess where 99% of the ccycles arae in that (and 90% of the dollars).

Re:Have you tried coding anything hard?

[teknomage1]

I suspect you've missed the point. The database (db2) is doing most of the work and is indeed written in native code. The interface logic most certainly is appropriate to be highe level, but the database engine itself is probably better off as native code. Ditto for the operating system kernel.

Re:Have you tried coding anything hard?

[kpharmer]

> How much app. processing goes on in the script languages? How much hardware do you dedicate to those vs. db2?

Well, db2 is obviously managing quite a lot of it. Certainly all of the queries, but also the very fast loads. DB2 is running on four-way Power4 & Power5 hardware with 4-12 disk arrays per server with 64-bit architectur and typically 8 gbytes of memory. It's running extremely fast.

By the time the data hits PHP it is typically just small result hits - that is, a scan of a few million rows will typically generate just a hundred rows or less that will go into a chart, graph or table. The PHP component is just running on older intel four-way SMPs. For a while much of it was statically generating all possible query pages - which meant a vast amount of processing, which worked fine - while we had slower databases.

But *100%* of the data pours through python. Every single row has to be reformated, has to be validated, has to have multiple fields replaced with identifiers to other tables (which require lookups in arrays). All of this happens in python. The python processes can hit 500 million events a day comfortably on older 1.4 ghz intel four-way smps with 4 gbytes of memory and a single slow disk array. They can hit about 3 billion events a day on fast 2.8+ ghz intel four-ways with multiple disk arrays.

> Is this externally visible (like search_used_books.amazon.com...)?

Yes, but only if you're one of hundreds of our customers.

> And of course to be an argumentative /.er, "Which interpretted language is db2 written in?" :)

you've got me there - we do run several pieces of software written in native code: aix, redhat linux, apache, db2, etc. And they do quite a lot of work - I'm not taking anything from them or suggesting that they be ported to python. However, our python ETL server is still churning out a vast amount of data every hour of the day.

Re:Have you tried coding anything hard?

[Memnos]

Hmm.. as well. I worked on a team that developed a DB app that was nine PETABYTES and growing constantly. (Our little test database was 60 terabytes.) It will soon be one of the five largest databases in the world, and could extend into the exabyte range (you can guess who it's for.) We use Java and ASP.NET on the server and Java and an AJAX solution on the client. We throw shitloads of big boxes at it and we don't give a damn, because it works. Do not get me started on how analytically complex the algorthms are that use that data...

Re:Have you tried coding anything hard?

[ceeam]

To be fair it's more up to database engine - and they _do_ seriously differ in speed despite what you might think otherwise (EG, MSSQL is up to 100 times slower on lots of simple selects than MySQL or Firebird - those I have extensive experience with).

But, right, PHP is slow. That's the second reason why I wish to move my web-development to Python. Python+Psyco kick ass unbelievably (speed-wise) - add "import psyco; psyco.profile()" to the end of your site.py :)

Oh, and the first reason is that PHP gets messy past about 2000-5000 lines of code, no namespaces you know, no first-class functions, no closures of course etc... The only consolation they may have for a moment is that Ruby may be even slower.

Re:Have you tried coding anything hard?

[Anonymous Brave Guy]

The interface logic most certainly is appropriate to be highe level, but the database engine itself is probably better off as native code. Ditto for the operating system kernel.

Thank you. In that one, concise post, you have provided the only credible answer to the question in the title: no.

As always, we should use the right tool for the job. For anything where processing performance matters, native code blows away anything interpreted, and always will. I loved this little bit of rhetoric in the original post:

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.

Negligible performance hit? Don't make me laugh. I write high performance maths libraries for a living, and there's a reason almost everything in this business is still done in C, C++ or FORTRAN.

Moreover, we probably port our libraries to some platforms that Java doesn't even have VM for, so the whole portability argument is FUD, too. If you want to be seriously impressed, go check out the work of the ATLAS project.

Of course more powerful, higher-level languages can make developers more productive in terms of getting projects finished faster. I don't think anyone's disputing that. If you can solve a problem effectively using a high-level language as glue and combining pre-built components, go ahead and knock yourself out, that's what the tools are there for. But somewhere along the line, someone has to write those components, and if performance matters, there's always going to be native code involved sooner or later. This is something the parent poster appears to understand, but the original asker apparently doesn't.

Re:Have you tried coding anything hard?

[Anonymous Coward]

It will soon be one of the five largest databases in the world, and could extend into the exabyte range (you can guess who it's for.)

Microsoft's bug tracking database?

Re:Have you tried coding anything hard?

[kalirion]

Ah, so that's how all our phone conversations are stored.

Re:What?!?!?

[Kethinov]

I know what you mean. In Linux, I used tons of music apps like Banshee and Amarok for their features, but got fed up and went back to XMMS for its speed. JIT languages are NOT appropriate for every task.

-1 flamebait

[Anonymous Coward]

Didn't we already do this with lisp, like 40 years ago?

Re:-1 flamebait

[Karma Farmer]

Noo... I think he meant the other lisp operating system.

Emacs.

Re:-1 flamebait

[procrastitron]

Symbolics was a company that produced Lisp machines. These had special hardware that implemented Lisp, there was no interpreter. And just to let you know, the operating system was called Genera. Of course, Wikipedia is a good resource for more information. Probably, the best page is the one for Lisp Machine http://en.wikipedia.org/wiki/Lisp_machine

Re:-1 flamebait

[Fulcrum of Evil]

Therefore, Lisp can't be used to create an operating system!

Heh, I love it when kiddies try to do logic. Learn some history, damnit!

Its inevitable

[greywire]

As the overhead of interpreted languages gets smaller (through faster systems, JIT, and other optimizations), its inevitable that eventualy we'll all be using one (unless you are one of the few people who have to program the virtual machines, the JIT compilers, etc).

And this is a good thing, because it means more independance from certain CPU architectures.

Someday, you will be able to use any OS on any CPU and any Application on any OS. This is one step in that direction.

Re:Its inevitable

[lbrandy]

As the overhead of interpreted languages gets smaller (through faster systems, JIT, and other optimizations), its inevitable that eventualy we'll all be using one (unless you are one of the few people who have to program the virtual machines, the JIT compilers, etc).

This cracks me up. As we head towards multi-core and massively-multi-core, you are telling me that things are going to get better for interprative languages? Compilers are about to kicked in the pants because we can only do thread-level-parallelism for so long (uh, lets say N=4.. when do those quad-cores come out? Early 07?).... The trend towards parallelism is going make compilers infinitely more importants as (memory bandwidth + computation bandwidth) gets the additions of a new, third term... communication bandwidth. It's just one more thing compilers are going to have to learn to deal with... and interpretative languages are going to fall farther behind... not catch up.

There will come day where we expect our compilers to encode parallel information into the code so it will run faster on our 1024 core machines. Interprative languages are going to be struggling to do that "just-in-time" like they struggle to do any optimizations now "just-in-time".

Re:Its inevitable

[David Greene]

There will come day where we expect our compilers to encode parallel information into the code so it will run faster on our 1024 core machines.

Too late. That day has been around for 20 years already.

Re:Its inevitable

[evought]

Your argument actually points out how much *more* valuable interpreted and JIT languages will get. Are you going to compile new binaries for every architecture and combination of cores? Or, are you going to encode the logic of the application and have your JIT figure out how to optimize for the specific platform. Before you say that JITs cannot hack this, remember that they use exactly the same technology as your 'standard' compilers.

Secondly, if it is a question of taking too long to compile, realize that you can always ship optimized binaries from high-level languages (e.g. GCJ), but you cannot readily make your optimized native code work on a new platform.

Re:Its inevitable

[lbrandy]

If you mean a compiler that takes simple linear code and magically makes it run faster on a massively parallel architecture, I'd be very interested in an argument for how that's even logically possible.

It's done by changing the paradigm. Stream programming, for one? You don't "magically" take linear code and make it fast. You get rid of "linear code". Linear code goes the way of the goto instruction... Very little of the computational heavy lifting is truely and unavoidably "linear".

Re:Its inevitable

[Mornelithe]

Well, that sort of compiler is sort of the holy grail of pure functional languages. The idea goes something like this:

Forget your C/C++/Java/whatever. Side effects and multiple assignment are bad. Program in a pure functional language, such that all functions are referentially transparent---that is, f(x1,x2,...) always returns the same value given the same x1, x2, ..., and has no side effects (print statements, assignment to mutable state, etc.).

Now, since most of your code is made up of referentially transparent functions, the compiler can automatically split independent pieces of code up, and perform them in parallel without fear that a call to b(x) somehow effects the results of c(y).

When you absolutely need side effects (for IO, for example), you use something (uniqueness types, monads; I'm guessing) that explicitly orders the code and in this case, would presumably prevent the compiler from parallelizing it.

Compilers aren't there yet. The things I'm (vaguely) familiar with require specific annotation of potentially parallel paths. Try Occam, for instance. Another example I've read only slightly more about is parallel Haskell, which includes similar annotation primitives (par and seq). However, just because you annotate something as parallel doesn't mean it will be performed in parallel. The compiler/runtime/I'm-not-sure-which decides what to run in parallel from among the massive potential of parallelism in such a program.

If you're asking how it's possible in Java: it isn't. But then, Java already sucks when it comes to concurrency compared to systems designed for it like, say, Erlang (which, incidentally, is VM interpreted, but still blows the pants off most conventional C/whatever programs within its application domain (massively concurrent/fault-tolerant systems), lending some credence to the point of this article, not that the same things necessarily couldn't be done with native code).

Re:Its inevitable

[Lost Engineer]

Your link is a bit vague for me. I have used a Cray cluster lately, and I was forced to handle parallelism on my own, using MPI, UPC and like paradigms. What parallelism do Cray compilers handle automatically?

Re:Its inevitable

[cryptoluddite]

I actually have a dual-core machine at work and the only single program I have ever seen use more than one CPU at a time was written in Java. Even the single-threaded Java programs use like 110% CPU as the garbage collector (or whatever) runs in parallel (this was the genome benchmark from language shootout iirc). As in, "cpu time 110s, wall clock time 100s". Java is already ahead on multi-core.

Basically you are smoking crack thinking that compiled languages are going to thrive on multi-core. They aren't. Hell it's hard enough to keep data access correct with just a single thread. And with a "safe" language like Java the compile *knows* there are no aliases for an array, so some kinds of access can automatically be done in parallel, whereas in a separately compiled/linked language like C there are few ways for the compiler to know this. When there's not enough active threads per core the other core's can GC the inactive programs. Safe languages have huge advantages on multi-core.

On the subject of loosers...

[Kelson]

No, no, obviously, they're loosing grey hair in the same sense that one "looses the dogs" -- i.e. they're setting the grey hair free.

Re:On the subject of loosers...

[Anonymous Coward]

Thank you!

I was beginning to think I had gone mad, or perhaps there was committee that changed the spelling of "lose" without telling me. I honestly haven't seen anyone spell it correctly in months. It's starting annoy me as much as people can't tell they're from there from their.

Re:On the subject of loosers...

[Anonymous Coward]

If I had the opportunity to change the language, I would make more obvious changes, like remove silent letters.

Well, what do you think we've been doing over here? Just that.

We've taken out useless letters, such as colour -> color and catalogue -> catalog. We've simplified superfluous pronunciations, as in aluminium ->aluminum. And we've made the number system more consice and practical, for example thousand million -> billion.

There's much more work to be done; for example, every word that contains an "ough" needs to be reworked. But at least one country has taken up the initiative and made the first few steps towards a more rational language.

Re:On the subject of loosers...

[plover]

i.e. they're setting the grey hair free.

"Cry 'havoc!' and let slip the hares of war!"

Sorry, someone had to say it. :-)

Re:On the subject of loosers...

[popeguilty]

It's "USians" to avoid using "Americans" to refer to 300 million people when there are legitimately over a billion people who can claim the name "American."

Take your synecdoche elsewhere.

Re:On the subject of loosers...

[mrchaotica]

Nooo!! "Havoc" is proprietary; you should be saying "Cry 'ODE!' and let slip the hares of war!"

Re:On the subject of loosers...

[toadlife]

The first time I ever noticed lose spelt incorrectly was in the Game Operation Flashpoint which was released around 2001. In the triggers in the mission editor one of the choices upon activation was "loose". Also in the scripting language, the functions "getdammage" and "setdammage", damage was also spelt incorrectly.

Since creating missions for Operation Flashpoint required in hours in the mission editor tweaking triggers, and scripts, in the various game forums almost everyone would regularly misspell both lose and damage when posting messages. Even those that knew the proper spelling would do it. It became somewhat of a joke, as everyone knew it was wrong but would continue to do it out of habit.

Operation Flashpoint effectively trained thousands of people to misspell both lose and damage.

So don't blame us "USians" for it. Blame those Czech developers at BIS and their kick ass battle simulator.

Re:On the subject of loosers...

[mysticgoat]

I loose my gray hair when I get off work. The ponytail and smoothly coiffed beard are necessary to convey the appropriate image in the office, but in the privacy of my home I let the beard go bushy and the tresses bounce about my shoulders.

But maybe this is more information than you really wanted to know...

Re:On the subject of loosers...

[mysticgoat]

I admire people like the parent poster who have the courage of their convictions and are willing to stand up in front of the crowd and tell someone off when they thing that's called for. So let me express my deep admiration to you, err... Mr Anonymous Coward.

Re:On the subject of loosers...

[jrumney]

Proper way to say it would be "citizens of the USA" or "United States Citizens" or even (longwindedly) "natural citizens of the United States of America"

Or in keeping with this thread, we could start calling them "loosers".

Re:On the subject of loosers...

[Bastard of Subhumani]

We've simplified superfluous pronunciations, as in aluminium ->aluminum

If that's so, why didn't you do it for sodum, potassum, calcum & the rest?

Re:On the subject of loosers...

[QuesarVII]

If that's so, why didn't you do it for sodum, potassum, calcum & the rest?

Because they didn't start out as "sodidium", "potassisium", and "calcicium".

Re:On the subject of loosers...

[cooley]

[i]It's "USians" to avoid using "Americans" to refer to 300 million people when there are legitimately over a billion people who can claim the name "American." [/i]

Wouldn't that logic make the Scottish and the Welsh "British"?

Negligleable performace hit my...

[MBCook]

Have you ever USED a Java application or applet on Windows? Once they launch they perform pretty good. Once they launch.

On every computer I use with Windows it takes up to 20-30 seconds to launch Java. Web page have a little "yes, you have Java" applet? Prepare for a massive slowdown. I'd hate to see what it does with applications that may just appear to hang the computer while Java launches. And don't get me started on taht stupid "Welcome to Java 2" dialog that pops up from the taskbar.

Now on my Mac, things are different. Java applets launch just as fast as Flash if not faster (basically, instantly). This is on my G4 so things would only be better with a CoreDuo. Same goes for applications. I've been using an appilcation called YourSQL for over a year. It accesses a MySQL server and works great. It's very fast, has a perfectly native interface. You would think it is a native app, but I recently discovered that it's Java. The end use would NEVER notice that kind of thing except I was trying to debug a problem in my own code so I went to invesitage how it worked. It was Open Source and when I downloaded it... it was Java.

Java is fantastic on Mac OS X. I don't know how fast it is on Linux. But as long as there is a 20-30 second launching penalty on Windows, Java will never be accpeted. I don't think .NET has this problem, but probably because MS is keeping it memory resident in Vista even if no one is using it.

Then again, maybe Mac OS X preloads Java. I don't know if it has tricks, or if the Windows implementation is just that bad.

Re:Negligleable performace hit my...

[NutscrapeSucks]

Let me add some content to your Apple advertisement :)

Apple's JVM implementation has something called Class data sharing to speed Java startup after the first invocation. The first time is just as slow as always. Since then the feature has been added to Sun Java 1.5, so if you're up to date, you should have this.

Not quite the end yet

[The Evil Evil Muppet]

At this point, there is still a lot of development happening in "native" languages. Additionally, there are projects in motion to turn bytecode from environments like Java and Python into native code. One of the reasons a lot of people are seeing this seemingly massive movement is because of the technologies these "non-native" solutions leverage. Take both Java and .Net - the support libraries are huge and designed to (more or less) work together. All of that said, I'm a bit sick of either having to put up with the limitations of some of the languages that end up as native code or distributing some runtime environment with my app that immediately gives my users an impression of my product. For that reason, I've started to use D - http://blogs.itoperations.com.au/chris/software/la nguages/language-choice-is-a-compromise/. If you can't be bothered reading my convoluted blog (there's more coming on the subject, along with a project release in coming weeks), go on over to the language's home - http://www.digitialmars.com/d/index.html. It has the vast majority of C++'s features (and more), Java/C#-style syntax and ease whilst compiling to native code.

two things

[bunions]

(a) 'loosing': oh jesus christ
(b) the obvious answer is that native vs interpreted is basically simply the balance of developer cost versus cost of end-user resources (ram, cpu, users time). Interpreted code is getting faster every day, no matter what "OMG JAVA IS SO SLOW DUDE" geniuses on the interweb tell you, but there'll always be problem spaces where a 5% speedup pays huge dividends.

Re:two things

[sl3xd]

You forgot high performance computing (ie supercomputing) environments, where electrical costs are measured in dollars per minute (and the job takes weeks).

There are plenty of cases where it is far more cost effective to pay somebody $10k/week to optimize the hell out of a piece of code, because a 1% optimization will save thousands of dollars over the course of a year. The market for supercomputing applications is growing substantially. It's quite frequently cheaper to prototype in a supercomputer than it is to do something 'in the real world.'

I always laugh when I see people point out benchmarks where Java is compared to C in terms of the Linpack benchmark -- entirely ignoring the fact that in both cases, the actual 'work' is being done in neither Java nor C, but in a BLAS library that is written in Fortran. It's hardly suprising they have similar speeds -- they're running the exact same routines, from the exact same Fortran library.

The thing I see is this: The market for interpreted languages is fairly static -- I remember playing simple games written in BASIC on my parent's Apple II. I recall word processors, education software, etc -- all written in interpreted languages.

The region of 'corner cases' where native-compiled code is substantially faster than interpreted languages hasn't changed significantly over my lifetime. High performance games were, are, and will remain native-compiled code for the forseeable future. The same applies to supercomputing. Embedded machines are also a bastion of native code -- simply because they are produced on a scale that favors code written natively-- the tradeoff being more expensive hardware, and the economics never work out such that software (including its one-time development cost) is cheaper than hardware.

There's nothing wrong with either; they are tools, to be used appropriately. Being a rabid fanboy (or hater) of either only proves one is willfully ignorant of reality. Fifteen years ago, an interpreted language kept many of the world's largest mainframes running -- it wasn't Java, it was BASIC (or one of quite a few other interpreted languages).

The languages used may have changed, but the amount of (and use cases for) interpreted vs. native code hasn't changed that much over the decades. Shiny-new Java didn't change it, neither did .Net. Nor will Ruby on Rails. It's the same old song, covered by some fresh new 'hip' band.

Don't think for a second that interpreted languages are taking over; or that they're losing ground. The more things change, the more they stay the same.

Re:two things

[mog0]

I have heard that there are currently a number of games in development on Windows using C# as the performance hit is negligable and C# has a wrapper for all the DirectX libraries. In modern games DirectX takes the bulk of the load and so C# can be used for the rest of the game logic without a significant drop in performance. It may be that these sort of situations increase where you have a high performance library being called from a JIT compiled language like .NET / Java.

Re:What?!?!?

[tomhudson]

It's all bs.

15 years ago I benchmarked assembler vs c for graphics code - c was 200 x slower. There is NO way that any interpreted runtime will even begin to approach the "bare metal", never mind c.

Most of the benchmarks crowing about the speed of JIT compilers ignore the startup and initialization time, as well as the end-run time.

I couldn't believe some of the naive assumptions on one published benchmark - they had the java code print out its start and end time and said "see, only 4x slower than c"; naive is being polite. Proper benchmarking would mean putting a wrapper around both code examples, to handle the start and end time notification.

Re:What?!?!?

[bunions]

They aren't very good for ANY task as far as I can see.

fun fact: slashdot is written in an interpreted language (perl).

wait a minute, the kid might be onto something ...

Why isn't anything compiled natively anymore?

[Crussy]

Outside of introspection and like technologies there is no reason why code cannot be compiled natively. Linux users are aware of compiling java code natively, microsoft is working on a native c# compiler, so why is it that everyone else things it's still okay to compile to byte code or scripts. It's not; end of story. I do not like when every new processor that comes out is stomped on by new programs requiring more resources to do the same job. How many java programmers use runtime reflection or introspection? How many programs is it actually needed? If you're not using that, then you should compile natively. Just because Vista is wasting precious resources on it's silly aero glass, etc, doesn't make it right for everyone else too. What happens when someone tries writing a kernel in an interpreted language? Stage 3 bootloaders'll throw us into a JIT environment now. I could just imagine the efficiency there. Native languages are the way to go and we're in for big problems if they don't stay around.

Someone's been reading too many benchmarks

[Xugumad]

"Regardless of the negligible performance hit compared to native code"

Yeah... people keep saying that. Okay, lets take the benchmark I hear about most: http://kano.net/javabench/ "The Java is Faster than C++ and C++ Sucks Unbiased Benchmark". Unbiased my foot. "I was sick of hearing people say Java was slow" is not a good way to start an unbiased benchmark. Lets have a few more problems:

• This is not Java vs C++. This is Sun's JDK 1.4.2 vs GCC 3.3.1 on a P4 mobile processor.
• GCC is not a fast compiler, it's a portable compiler that happens to be fairly fast. A fast compiler might be something like Intel's own compiler: http://www.linuxjournal.com/article/4885
• Having proven that method calls take almost twice as long under G++: http://kano.net/javabench/graph - the author then several of the tests recursively ( http://kano.net/javabench/src/cpp/fibo.cpp ). When this benchmark came out, various people on /. managed to get around 1,000 times better perfomance (under G++) by switching to a fixed memory usage non-recursive implementation.

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.

Y'know, I think there's a reason for that...

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).

Y'know, a couple of decades ago I was running non-native applications on a 7Mhz system with 1MB RAM (my old A500). They were fast, but not quite as fast as native. I'm now using a system in the region of 500 times faster, in terms of raw CPU, and with 2,048 times more memory. And y'know what, non-native stuff is fast, but not quite as fast as native. Something about code expanding to fill the available CPU cycles, methinks...

Re:Someone's been reading too many benchmarks

[IamTheRealMike]

This really isn't correct. Modern optimizing compilers can do some very powerful and very expensive kinds of optimisation. The kind that double your compile time, at least, but can be worth it - one developer working on a console game claimed that when whole-program optimization was enabled in the newest MSVC++ they got "a ridiculous 30% speedup", for free (his words not mine). 30% sounds remarkably high but it's not impossible in a closed system like a games console game, in which (say) dynamic loading of code is impossible.

Java has several extremely poor design decisions that render it difficult to optimise compared to ahead-of-time compiled static languages like C++:

• The javac "compiler" does practically no optimization at all. It leaves it all to the JVM. Therefore the end user pays the overhead of the compiler instead of the developer.

• Java code can dynamically load other Java code at any point, and there's no way to indicate you'd like this disabled (the std lib does it all over the place anyway). This fact alone prevents many useful whole program optimisations such as call-site optimisation .... say you can prove that a particular method call will always dispatch to a given class (because the variable is typed to be that class and it has no subclasses). A good optimising compiler will replace the virtual method call dispatch with a direct call, saving on a possible pipeline stall and memory reference. No matter how fancy it gets, the JVM simply cannot do that, because at any point some new code may be loaded which subclasses that original class, invalidating the optimisation.

• The language is designed to be minimalist with no way to extend it. Look at how many attributes GCC supports that are optimisation related to get a feel for this disadvantage. The compiler-specific attributes combined with the pre-processor can not only improve correctness of code but give the compiler hints about the program that it can't easily figure out for itself yet. No equivalent in Java

That said, whilst the best C++ compilers can still stomp all over the JVM, it's usually compared in benchmarks to GCC which has only recently started getting the more advanced optimisations developed in the last ten years or so. And by default you need to invoke GCC in certain magic ways to get them, which many developers don't know how to do. This gives Java a sort of built in advantage.

For code where performance matters I just can't see how Java can ever win .... it fundamentally tries to compile "on the fly" which means only very trivial optimisations can be done, no matter how many hotspots you have. It's just not feasable for the JVM to spend half an hour pondering the structure of a complex program in the same way that it is for an AOT compiler.

As A Developer

[miyako]

Of the development I do, about 60% is in non-native code (mostly java) and about 40% is in native code (usually C++). What I have found is this:
Java is the language I use the most, and it's good for small programs. It's definitely noticably slower for large applications, but I don't think that's the big reason that a lot of developers don't like it. Swing is nice, but the problem with Java and a lot of other "modern" languages is that they try so hard to protect the developer from themselves and enforcing a certain development paradigm that the same features that make it really nice for writing small program end up standing in your way for large and complex application development. Looking at the other side of the issue, C++ is fast, it can be fairly portable if it's written correctly, and has a huge amount of libraries available. C++ will let you shoot yourself in the foot, but the reason is that it's willing to stand out of the way and say "oh really want to do that? ok...". This makes it easy to write bad/buggy programs if you don't know what your doing, but if you pay attention, have some experience, and a plan for writing the software, then C++ can be less stressful to develop.
Aside from a reasoned argument, I think a lot of developers are just attached to C/C++. I know that I just enjoy coding in C++ more than in Java. Not that Java is bad- and it can be fun to code in at times, but the lower level languages just give me more of a feeling of actually creating something on the computer- as opposed to some runtime environment.
Finally, one major reason to stick with C++ is that many interpreted languages aren't really as portable as they pretend to be. A language like C++ that really is only mostly portable, and then only if you keep portability in mind, can sometimes be more portable than other languages that claim to be perfectly portable and then make you spend weeks trying to debug the program because things are fouling up.

Cross Platform not related to language

[Mr. Sketch]

The choice of language does not determine if something is cross platform. It has more to do with the choice of toolkits. If you are using GTK or wxWidgets you are pretty safe for being cross platform. C/C++ are cross platform languages, but if you use MFC and COM, they're not.

Even if I use Java or C#, but don't use a cross platform toolkit (e.g. Windows Forms would not be cross platform), the application won't be cross platform.

It doesn't matter if the language compiles to byte code, if that byte code doesn't use a cross platform toolkit, it won't be cross platform.

Re:What?!?!?

[Midnight Thunder]

For heavy number crunching interpretted is not there yet. Then again compiled code is not great for everything either, sometimes you have to write hardware specific assembly code. On the other hand if you are doing something that spends more time waiting in the user than actually working, then an interpretted language is great. Like everything you need to make a choice when you are going to use one approach or another. Remember you want to get a program out of the door and making it available to as wide an audience as possible so you will write in the language that is best suited for the task. If you know where to delegate the heavy number crunching then you can spend the rest of the time making a great program. Look at some of the programs written in Java using OpenGL. They are fast, but that is because they hand off the necessary heavy lifting to low-level APIs, heck even compiled languages like C/C++ do the same. See here for example: https://jogl.dev.java.net/

Java and Mac OS X

[Kelson]

Mac OS X treats Java as just another app framework, equivalent to Cocoa or Carbon. (I'm fairly certain I've seen an older version of that diagram that also listed Classic in that layer.) I imagine they've done a bunch of optimizations to tie it into the system, though I don't know whether it launches the runtime at boot or not. You've probably noticed that on Mac OS, you get your Java runtime from Apple, not from Sun or IBM.

The downside is that things don't work quite the same as they do in Sun's Java runtime, so there are differences between Java-on-Windows and Java-on-Mac. For instance, my wife is an avid Puzzle Pirates player, and the game client is a Java app. There've been Mac-specific bugs in the past, and at one point a major slowdown appeared when the game was run on a Mac. It hasn't been fixed, so while she can still do crafting on the Mac, whenever she does anything multiplayer, she has to switch to the Windows box.

Not today, not tomorrow.

[Perseid]

Silly question. The answer is and will always be: No.

Commodore 64 BASIC was interpreted. Computers now are obviously powerful enough to run 64 BASIC code very quickly. Does that mean native code should have been abandoned years ago because technology advanced enough to allow C-64 code to run quickly? JIT code will always be slower than native code and because the complexity of both JIT and Native code programs will get more complicated as the technology advances interpreted code can never catch up.

GRAMMAR NAZI

[illuminatedwax]

List of things you cannot loose:
- your gray hairs (unless you can command them somehow)
- control
- the big game
- your way

List of things you could be loosing:
- the hounds
- your belt
- an arrow
- responsibility

CPUs still have *A LOT* to evolve

[mangu]

Interpreted languages have been OK for a long time, for applications where performance isn't the most important parameter.

Now find me one CPU that can do a decent simulation of the physics of continuous media. Why isn't there any game where you ride a surfboard realistically? Why do meteorologists use the most powerful number crunching systems in the world to be wrong in 50% of the cases when predicting weather a week ahead?

And what about artificial intelligence and neural networks? Find me a CPU that can do a decent OCR, or speech recognition. What about parsing natural language? Why can't I search in Google by abstract concepts, instead of isolated words?

No matter how powerful CPUs are, they are still ridiculously inadequate for a large range of real world problems. When you go beyond textbook examples, one still needs to squeeze every bit of performance that only optimized compilers can get.

Re:CPUs still have *A LOT* to evolve

[An Onerous Coward]

You seem to be under the impression that these problems you cite display inadequacies in the hardware, rather than the software. But, in the words of some fictional professor from a book I can't remember: "If you speed up a dog's brain by a factor of a million, you'll have a machine that takes only three nanoseconds to decide to sniff your crotch." Given the current software and algorithms available, more computing power alone wouldn't solve any of the problems you describe.

Re:CPUs still have *A LOT* to evolve

[IamTheRealMike]

Highly accurate general purpose speech recognition is an AI problem, which as others have pointed out, currently hits the limits of our knowledge not our hardware.

Well, yes and no

[BigCheese]

Don't you hate that answer?

Yes, we are seeing more development in non-native code but, it gets it's power from the underlying libraries and core code that is native. The line between them gets fuzzy when you toss in JIT and scripting to native code compilers. It really depends on the problem area. If I'm just parsing apart a bunch of log files to make reports Perl or Python would be the best. Web apps seem to benefit from the safety net of non native code but I'm sure there are exceptions.
OTOH there are plenty of apps that need all the speed and memory the machine can provide. My current job involves real time financial data delivery. Writing that in Python or Java would (probably) not work out too well. OS code that works directly with hardware will probably stay in assembler or C. Fast low level stuff is what allows the slower high level stuff to be useful.

Either way you still need to know what you're doing because in the end both native code and interpreted code run as opcodes on a CPU and use hardware resources. You need to mind memory use in Java just like C. Just in different ways. You've need to watch what you do in inner loops in both Python and C++. Linear lookups can cause scaling problems in Perl, Java, Python or C/C++.

It all depends on how fast you want to get from problem to solution, how much hardware you can throw at it, how complicated the problem is, how much time you have and many other factors.

Languages are tools, not a religion. The broader your knowledge the more tools you have at your disposal. Pick the best one for the job at hand.

Depends on the task

[DigitalCrackPipe]

Ok, assuming the post isn't flamebait... This issue keeps coming up. A good programmer should understand that the language choice depends on the task at hand.

If you're making a pretty GUI, you may want to use an easy-to-use and portable language and may not care about performance as much. If you're creating a high-performance backend, or doing some realtime processing, an interpreted language is practially useless.

Before deciding which paradigm is superior, you must narrow down the question to a type of task. Since the variety of tasks we use software for does not seem to be shrinking, it seems that this issue will not be resolved decisively anytime soon.

LISP, BASIC, FORTH, P-Code, Java+Netscape

[billstewart]

LISP was a simple, elegant language that demonstrated that almost any language written after 1961 was unnecessary, except for demonstrations of concepts like Object-Oriented programming that could then be re-implemented into LISP, and that any code written in older languages could be replaced with something better :-)

BASIC had its problems, warping a generation of programmers (including me), but it was small and light and didn't take long to learn unless you wanted to enough find tricks to get real work done.

FORTH was smaller, lighter, and faster. It was overly self-important, considering its reinvention of the subroutine to something new and radical, but if you wanted to program toasters or telescopes it was the language to use. Postscript was somewhat of a Forth derivative.

P-Code was a nice portable little VM you could implement other things on.

And then there was Java, which grew out of Gosling's experiences with NeWS, a Postscript-based windowing system. If you wonder why you're not using Netscape and maybe not using Java, and why you've probably got Windows underneath your Mozilla, it's because it became obvious to lots of people that Netscape+Java was a sufficiently powerful and easily ported environment that the operating system underneath could become nearly irrelevant - so Microsoft had to go build a non-standards-compliant browser and wonky Java implementation and start working on .NET to kill off the threat. It wasn't that conquering the market for free browsers was a big moneymaker - it was self-defense to make sure that free browsers didn't conquer the OS market, allowing Windows+Intel to be replaced by Linux/BSD/QNX/MacOS/OS9/SunOS/etc.

Re:LISP, BASIC, FORTH, P-Code, Java+Netscape

[killjoe]

I agree with you but...

I have started to believe that the proof is in the pudding. I don't know lisp but I know some zope. Zope much like lisp is elegant, innovative, comprehensive, well designed and capabable of almost anything. Just like you probably scratch your head and wonder why people code in PHP or java when they could code in lisp I wonder why people code in PHP or java when they could have used zope and python.

But I am ready to give that up. I am now under the imression that zope isn't everything I thought it was. I mean if zope is so great then how come there are only three or four blogs written for it and not one of them is 1/10th as good as wordpress which is written in PHP? How come not one ticket tracker written in zope is 1/10th as good as eventum written in php?

I ask those questions rhetorically though. I know the answer. The answer is that zope if very hard. You have to be a very smart and very dedicated person to climb the ladder of zope and attain zope zen and there are just not enough people in this world that are willing to put forth that much effort.

In the end it's better to be easy then to be good. Look at how gracefully ruby balances on that rope. ROR is easy and it's innovative. That's why great software is being written in rails while the zope folks are pounding on zope3 trying to make it easier for developers to write decent software.

BTW I am not even going to attempt to learn zope3. I have to break up with zope. Thanks for the great times guys.

Re:LISP, BASIC, FORTH, P-Code, Java+Netscape

[julesh]

if zope is so great then how come there are only three or four blogs written for it and not one of them is 1/10th as good as wordpress which is written in PHP? How come not one ticket tracker written in zope is 1/10th as good as eventum written in php?

You might think you know the answer, but you're wrong. The real answer is very obvious. It is this: zope has a low installed base at ISPs. Perhaps this is because PHP is easier than Zope, I don't know. I suspect it's just because more people use PHP because more people have tried PHP, and that's because PHP is what *everyone* knows is what you use for writing simple web applications (either that or ASP). More complex apps? Java servlets, or ISAPI extensions. If you're a hacker? mod_perl.

This is common wisdom, so this is what people do. So this is what the ISPs support.

Seriously, that's the reason. I'm currently working on a major web application in PHP. Would I rather be doing it in Python? Sure; it's a much better language, much cleaner syntax, does everything I need it to more effeciently than PHP does. So why am I using PHP? Because I want portability between as many ISPs as I can feasibly arrange, and when I ask ISPs if they have Python/Apache mod_python installed, most of the ones in the price range I'm targetting say they don't. All of the ones in my price range can support PHP. About a third of them can support ASP.

Embedded Platforms

[Anonymous Coward]

I'm a Software Engineering Consultant who works in the avionics industry. While the enterprise application market may be moving that way, avionics certainly is not. I program about 80% C code, 15% C++ (helper apps), and 5% Assembly Code. The cost involved in certifying any sort or interpreter or JIT compiler is not worth it to anyone doing saftey critical RTOS work. Any speed in application development would be offset by several orders of magnitude in the effort to make that language available to the embedded platform through a certification process which would likely take a large team of developers several years. And maybe by then the cost of the hardware will have dropped enough to support it. Right now the product I work on has 512kB of Flash and 1MB of RAM, and it runs on a ultra low power 20MHz processor.

But for all you folks working in the application sphere, I'm sure things are heading that way as portability becomes a larger issue between OS's and architectures as the market moves away from a Windows based x86 monoculture. But for those of us working on products that include hardware, extra cycles aren't in the budget since they drive up the per unit cost.

Re:What?!?!?

[Anonymous Coward]

You seem very self-impressed. Fifteen years ago, before you were senile, I'm sure your benchmarks were of reasonable conclusions. Your C skills must have never been much to flaunt if they were compiling to a result 200 times slower than the "bare metal". I'm hoping for your sake that was exaggeration, but somehow I doubt it. The harsh reality is that working years of brilliant minds have pushed forward to develop compilers capable of pushing out code that would put your best work to shame. Optimizations you likely haven't thought of are regular passes in modern compilation.

JIT techniques, much like compiler optimizations, are developing day by day. Efficient caching techniques and dynamic recompilation and optimization are paving the way to an era of practical programming where an interpreted programming language can present comparable speeds to match against its compiled predecessors.

Like an old man harping about the "good ol' days", you are simply blinded by your years of experience and afraid of change. You cry "naivete" with respect to those who even suggest that there may be performance merits to interpreted languages while showing very little real-world modern figures or statistics. Naive! Naive! Naive!

Friend, blindly disregarding established JIT theory or advances in interpreted programming language performance sounds fairly naive to me.

It depends

[Sloppy]

Interpreted & JIT languages are "within a constant factor" of native code's speed, and CS students are taught that such things don't matter. ;-)

And for many types of apps, they really don't. Ten times slower than instantaneous, is instantaneous.

But people use computers for lots of things, and believe it or not, some of those things are still CPU-bound, and take so much work that humans can perceive the delay. Your word-processor is 99% idle so surely it doesn't need to be native, but you know that somewhere on this planet, a poor shmuck is staring at an hourglass icon, waiting for a macro to finish. The real question is: who cares? Is that guy's time worth more, or is the programmer's time worth more?

Re:What?!?!?

[tomhudson]

If you want to see a beautiful programming language, how about one that allows one to express code as data?

In assembler, its all code / its all data. The difference is only a JMP away.

One of the neat things was te 4k graphics demo contests - try to write the most impressive graphics demo with only 4k of assembler. There was a LOT of code writing code in memory, code using other code that had already run as raw data for designing the next iteration, then using it again as code ... a 4k program that could take you through a 3-dimensional roller coster ride for 20 minutes, never repeating, all done in real time, on hardware that you wouldn't deign to pick out of the scrap heap.

Re:What?!?!?

[An Onerous Coward]

I was right with you until you started gushing about the beauty of assembly. You might be able to write a single, heavily-used subroutine in assembler, and make a thing of beauty out of it. But the moment you try to do something truly ambitious, you abso-friggin-loutely need layers of abstraction. CPU cycles are one thing you don't have an unlimited amount of. Brain cycles are another.

Re:What?!?!?

[VGPowerlord]

Firstly, the compiler doesn't spit out C. It spits out machine language, the same thing your assembler spits out.

In this day and age, the compiler is probably smarter than you are. It can be told which processor your executable is targetting and use its instruction set as appropriate. This is particularly important for x86 chips, as there have been a number of SIMD extensions added to the instruction set in the last 15 years.

15 years ago, 3D graphics on a computer was unheard of. Now, they are ubiquitous. Programming 3D graphics is theoretically possible with assembler, but it is a much better idea to use something like C and an API like OpenGL.

Analogies suck, but...

[mangu]

the lower level languages just give me more of a feeling of actually creating something on the computer- as opposed to some runtime environment.

One of the oldest analogies in computing is comparing algorithms to cooking recipes. We even have books like "Numerical Recipes" and "Perl Cookbook".

Well, to me, interpreted languages are like frozen dinners. They will do if you come home late at night and are too hurried and hungry to cook a proper meal. But C is like a fully equipped kitchen. It takes *much* more skill to cook a proper meal than to heat a frozen dinner in a microwave oven, but the results are incomparably better, not to mention the pleasure you get from doing it the right way.

Re:Analogies suck, but...

[Abcd1234]

but the results are incomparably better

By what metric? Expressiveness? Ease of implementation? Ease of maintenance? Error rate? Because, last I checked, low-level languages like C fail on all those points compared to a higher-level language.

Re:Analogies suck, but...

[Itchy Rich]

By what metric? Expressiveness? Ease of implementation? Ease of maintenance? Error rate? Because, last I checked, low-level languages like C fail on all those points compared to a higher-level language.

It's a little unfair to pick on the low-level language programmers. There'd be more of them here to defend themselves but they're all so busy looking for memory leaks and buffer overflows. ;-)

If we all quit using native languages....

[Dcnjoe60]

If we all quit using native languages, then what are we going to use to a) write embed code, b) write drivers, c) write operating systems and d) write the interpreted languages that we use to replace our native ones?

Re:What?!?!?

[tomhudson]

... and only a compiler can write code to use SIMD extensions? You forget history - that originally, it was people abusing the fpu (in assembler) to have it process multiple chunks of data with one instruction that gave rise to SIMD extensions, formalizing what was already going on. We're seeing the same thing again, with people using the gpu on graphics cards to process non-video data.

Re:What?!?!?

[Waffle Iron]

In most cases, unless you're using specialized vector processing units, there's probably not a massive difference in performance between C code written by someone who really knows what he's doing and assembly code. (A good C coder will have a good understanding of how each line of code will get translated into machine code, and will avoid creating performance problems.) I've been coding in both for more than 20 years now, and whenever I disassemble a modern optimized compiler produces, it's almost always very good code.

The main thing is that the optimized compiler can tirelessly work on millions of lines of code, doing a good job of fully utilizing the hardware at each point, whereas the human assembly language coder will peter out juggling registers after few hundred lines of code. Past that point, the human coder will start creating manual layers of abstraction (subroutine calls, assembler macros, etc.) that just don't get optimized at all.

After you've written your graphics masterpiece and gotten it fully debugged, then you can profile it. If you can then identify some inner loops that you can't fix up by tweaking the C code, then maybe you should write a few dozen lines of inline assembler code. Anything beyond that is likely to be an unportable, counterproductive waste of effort.

Re:What?!?!?

[larry bagina]

take a look at GNUStep Web, the FREE version of WebObjects. It's Objective C but otherwise satisfies most of your criteria.

The thing about modern computer performance

[stevenm86]

Software will always expand to fill available resources with useless secondary gimmicks. I mean, look at Vista and its requirements. You would hope that when purchasing a PC that the available resources you are paying for will be used by applications you use. Instead, looks like the OS will be eating most of that up. It is the operating system's job to facilitate applicatons' access to resources, not to squander them on mostly useless (although arguably pretty) features.

Re:What?!?!?

[tomhudson]

whereas the human assembly language coder will peter out juggling registers after few hundred lines of code

I guess we can call that the new peter principle - every piece of code rises to its coders level of incompetence :-)

Every year we hear stories about how c is dead, but its still alive and kicking. The "java chip" that the Java OS was supposed to run on never materialized. Various other managed languages are either unmanageable (hello, perl! - sorry, had to throw that one in) or just can't compete on speed.

What's the BIGGEST problem with c? Buffer overflows and forgetting to free memory. These are both the same problem - somebody making a mistake in their code. Its not the language's fault - its the programmers. Falling back to managed languages because people are too lazy to check for corner conditions just promotes bad code in general. If you don't have the discipline (and curiosity) required to check for corner conditions, you don't have the discipline and curiosity to write good managed code either. But that's just my 2 cents.

After using the "P" languages over the years (Perl, Python, PHP), I still find c to be my favourite (probably because I really like the preprocessor).

Re:Someone's been spending too many dollars

[uniquemorgan7]

Misconception #553: The Intel C++ compiler costs money for hobbyists. Fact: Intel distributes its C++ compiler for free under two conditions: compilation must be for non-commercial use and you don't get committed support. Given that these are 'hobbyists', then these are perfectly reasonable requirements. See http://www.intel.com/cd/software/products/asmo-na/ eng/compilers/clin/219856.htm.

All is native, all is managed

[davidwr]

When I run so-called-compiled code under an emulator like Bochs, *poof* it's no longer native. In theory, it can be very managed if the emulator is capable of doing sophisticated things like moving threads around virtual processors based on the potentially-changing resources available on the underlying host environment, adding processors or memory on the fly (assuming an OS that supported such things), etc., things clearly beyond the abilities of most "native" PCs.

The reverse is true if I pass my java source- or byte-code through a compile-once/not-JIT "native" compiler. Managed code suddenly goes native.

I predict people will work in the environment that is most efficent for them, where efficiency takes into account development costs, maintenance costs, run-time costs, political costs, etc. etc. etc.

There's also the question of "what exactly is managed code." If your program compiles against an exception-handling library, as most large programs today do, is that not a primitive form of code management? Granted, you may have to write your own management layer, but it's still not totally unmanaged. Even running as a process in a modern OS is a form of management, since a fatal-to-the-process error can invoke OS-level clean-up routines to close files and return resources.

To borrow from Shakespear: Managed or unmanaged, that is the question.
The answer depends on your perspective.

Horses for courses

[Nefarious Wheel]

It's still horses for courses, mate. Look at the niche markets -- embedded systems for example -- and you'll find opportunities to shave a few cents by using a smaller configuration that would profit from having tighter code.

Thinking back a few years, iirc the first Apple Mac had the Quickdraw graphics package written in machine language, didn't it? Not assembler, but instructions made of hand-mapped binary digits. It's the reason why those early Mac GUI's were able to extract such amazing graphic performance out of the Motorola 68000.

You can still buy Zilog Z8's, and embedded applications still exist for them.

Re:Horses for courses

[Nefarious Wheel]

Not entirely true, back then. The assembler of the day (think it may have been Motorola's own) provided only a subset of the options available to the chip hardware; some of the more esoteric middle-bit operation modifiers weren't covered by mnemonic+qualifer options.

PHP vs ASP vs C++ vs JavaScript

[PassMark]

We wrote the same search engine code in 4 languages, PHP, ASP, C++ & JavaScript. The results are published here, http://www.wrensoft.com/zoom/benchmarks.html

In summary, C++ was 4 times faster than PHP, and in turn PHP was 3 times faster than ASP and JavaScript was truly appalling. I can't think of many applications that wouldn't benefit from being 4 to 12 times faster.

Re:PHP vs ASP vs C++ vs JavaScript

[NotQuiteReal]

But it will take you 4 times longer to write it in C++...

So, the question is what is more important? Time to code or Time to run?

If you have a one-off task, and your developer costs money, you want quick-to-develop.

If you are going to run the program a bijillion times (a lot), you quick-to-run at whatever developer cost.

I've coded C++, Java, and .NET services that all did what they needed to do (long running data collection applications).

There is more than one way to skin a cat, and the end result all tastes good with enough hot sauce.

Re:What?!?!?

[atrus]

Half of what you want is in the C++ STL.

And no, the STL does not suck.

Re:What?!?!?

[_merlin]

That's rubbish. I can get over twice the performance of GCC on palette-based video blit on PowerPC. GCC wastes far too much time performing loads and stores. It can't think like a human. I wouldn't write a whole app in assembly language, but it's worth it for small, performance-critical parts.

What makes you think Java won't rule the client?

[Latent Heat]

A lot of people are dismissive of Java as having failed on client GUI apps. What is it now, 2006, and Java came out around 1996? I know we talk about "Internet time", but major software concepts can take years to evolve, and Windows started out sometime in the 1980's but it wasn't until Windows 95 that it started kicking backsides and taking names. So maybe Java will eventually have its day.

I am a Pascal programmer from ancient days and have been pretty much a Delphi person on account of my Pascal affinity and other requirements, but I have implemented GUI apps in C++, C#, Java, Matlab, and VB. I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi. Java simply couldn't do in 1997 what I was doing even at that time in Windows, just plain couldn't from the standpoint of features and performances. Java is not-quite-there-yet with the features I use in Windows, but it is much farther along in 2006 than in 1997 and is closing the gap with graphics acceleration and other features. It may surpass Delphi for what I do if it proves to be easier to do multi-threaded apps to take advantage of multi-core.

While my complex data visualization stuff is a long way off from being done in Java, the sort of simple data visualization stuff that I was doing in 1997 under Windows works quite well under Java, and it works equally well under Linux. If anything will get me to switch to Linux it will be that I have a collection of graphical data visualiztion programs for the work I do written in Java that will work equally well under Linux. While I can write a faster program with more features in Windows, the Java implementation is proving good enough for a lot of stuff that I am doing and it breaks me loose from Windows as well.

SUN seems to be in this Java business for the long haul, seemingly spinning their wheels making it available for free and always being a step behind Windows in features. But at some point Java/Swing programs will have accumulated enough performance and features that they are good enough for what people want to do, and they have the added advantage of not being tied to Windows. This idea that something like Java could transcend the OS may yet happen for client GUI apps.

You could always try "D"

[lokedhs]

You might find that the D programming language is right up your alley. It seems to match most of your requirements.

Re:What?!?!?

[twitchingbug]

Well really the compiler spits out assembly, which sends it to the assembler that turns it into machine code.

and no a compiler is not smarter than you are. There are some amazing assembly code written by people out there that no compiler would ever be able to compile. Of course the compiler does well enough, cause who want to write even 5% of their app in assembly these days?

Teh funnay!

[chris_eineke]

The irony of the tagsoup is delicious...

No, stupid programming maybe... yes.

It's a name, not an adjective.

[Kadin2048]

Except that "South America" != "America".

I'd think that computer people could understand the difference. The 'South' in 'South America' is part of the string, it's not a prepended descriptive modifier.

"South America" is not a region of a larger area known as "America." "South America" is the name of a particular region (actually, an entire continent), period. (In the same way that "South Dakota" is the name of a place, and not just a southern region of some place called "Dakota.") Occasionally we confuse the issue by calling North America, Central America and South America collectively "The Americas", but there you have to be aware of the plural 's'. "The Americas" means 'multiple Americas.' If the area being dicussed was actually 'America,' then there'd be no need for the plural.

So to sum up:
"North America" is a continent, and includes the regions claimed by the United States of America, Canada, and Mexico.
"South America" is a different continent entirely,
"Central America" is a distinct geographic region between North America and South America, although it's considered to be part of the continent of North America.
"The Americas" is a term used to refer to North America, Central America, and South America collectively,
"America" is a shortened or common term for 'The United States of America,' a country located in North America.

The common uses of the words really have no conflict; it's all pretty clear to me.

Re:It's a name, not an adjective.

[telekon]

"America" is a shortened or common term for 'The United States of America,' a country located in North America.

Sure it is, from the perspective of a resident of the United States of America. My Canadian friends, however, lament such shorthand, because although they are 'Americans,' they would be horrified for such US-centric shorthand to confuse the issue of their nationality, especially when travelling to Europe. My Quebecois friends insist on the term États-Unisiens. (United-Statesians)

I'd think that computer people could understand the difference. The 'South' in 'South America' is part of the string, it's not a prepended descriptive modifier.

Despite being counted among both of the aforementioned groups (residents of the Untied States of America and 'computer people'), this part of the argument strikes me as the most absurd. Why would you invoke the constructs of a set of abstract artificial languages to (erroneously) explicate the workings of natural languages?

Despite the status of "South America" as a proper noun, and as such a 'bracketed' piece of syntax, one would do well to remember in natural language context precedes the identity of discrete sentence fragments; etymology is never put out of play. Context, in this case, can easily be established by glancing at a map. Through careful study and observation, one will soon discover that 'south' is damn well a modifier, placing one bit ot the larger set 'america' in geographic relation to the other bit, in this case, specifying it as being 'south' of the 'north' bit.

Not a modifier, my ass. Natural languages are vastly and inordinately complex, to the degree that they make C++ look like COBOL. But this one is a bit of a no-brainer. Then again, maybe there's a reason nobody expects engineers to be poet laureates.

Re:Huh?

[dwlovell]

You wonder what low-level control has to do with non-native or interpreted languages?

One word: pointers.

Virtual machines (ie: runtimes) handle garbage collection and memory management. In low-level languages, you, the programmer handle it. Dont confuse a vmware virtual machine with a runtime like the java virtual machine, or the .net framework runtime which performs JIT and memory mangement.

Managed and interpreted languages take a perf hit for using special threads to run a generic (albeit engineered) algorithm to manage objects that no longer have references. In low-level languages, you have complete control over when objects are created in and destroyed from memory. So you have more power to optimize memory usage for your application, but also more power to make mistakes regarding memory. (ie: buffer overrun/underrun, bad pointer math).

So I would say that "low level control" has a great deal to do with "interpreted languages" since virtual machines are what perform the native tasks that you would normally be responsible for.

Then again, maybe you were just making fun of his grammar and already knew all of this.

-David

Re:What?!?!?

[tomhudson]

Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.

--- In other words, the lousy formatting of the source that follows is not my fault

To get a real comparison, just try running these two programs:
#include <stdio.h>

int main(int argc, char* argv[], char* env[]) {
        int a, b, c, d, e, f, total;
        total = 0;
        printf("Content-type: text/html\r\n\r\n");
          printf("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">");

        printf("<html><head><title>c cgi test</title></head>");
        printf("<body>");

        printf("counting ...");
        for(a=1; a<=44; a++)
        for (b=a+1; b<=45; b++)
        for (c=b+1; c<=46; c++)
        for (d=c+1; d<=47; d++)
        for (e=d+1; e<=48; e++)
        for (f=e+1; f<=49; f++)
        total++;
        printf("%d", total);
        return 0;
}

and

<?php
        print "counting ...";
        for($a=1; $a<=44; $a++)
        for ($b=$a+1; $b<=45; $b++)
        for ($c=$b+1; $c<=46; $c++)
        for ($d=$c+1; $d<=47; $d++)
        for ($e=$d+1; $e<=48; $e++)
        for ($f=$e+1; $f<=49; $f++)
        $total++;
        print $total;
?>

You know< the c one is going to be more than an order of magnitude faster. (and if you didn't, I just tested them, but don't take my word for it ... you have the source, trivial as it is :-) Native code is faster, as you would expect.

Re:What?!?!?

[masklinn]

C is a lot easier to debug

In which frigging paralell universe are you living please? I want to go there. C being orders of magnitude faster than interpreted languages I agree with, but C easier to debug? Either you've never tried interpreted languages (say Python or C#, PHP is not a language) or you never got past "hello world" (hell, even hello world is harder to debug in C).

• Open source
• Written in C (or minimally-invasive C++ with standard C bindings)
• Solid regular expression integration
• Ability to obtain a standard C string representation with little or no penalty (to interface with legacy APIs)
• Reasonable error checking and reporting throughout the API for maximum security and debuggability
• Explicit retain/release, with automatic retain on allocation, instant destruction on final release---none of this garbage collection crap....
• Standard CGI parse code built on top of them (with get/post variables in a hash, for example)

In a word, you want D.

Or another nice high-level compiled language. Most of them are functional though (Haskell, *ML) so you may have some trouble adapting. And they usually don't allow variable-length strings, being functional and all.

Re:On the subject of looses...

[stfvon007]

That why eye always use May spill checker. There art know spilling miss takes in this post. And ewe forget to capital eyes Nazis.

The problem: our native-code languages are bad

[Animats]

The problem isn't native-code vs interpretive code. It's that our native code languages are terribly flawed.

Programming backed itself into a corner with C and C++. They're useful languages, but they're not safe. Now this has nothing to do with performance; you can have safety in a hard-compiled language. Ada, the Modula family, and the Pascal/Delphi family did it. The problem is that, because of some bad design decisions in C (the equivalence of arrays and pointers being the big one), you have to lie to the language to get anything done. This makes safety hopeless. The basic problem of C is that you have to obsess on "who owns what" for memory allocation purposes, and the language gives you no help with this. The language doesn't even adequately address "how big is this". With those two design defects, we're doomed to have memory safety problems. Which we do.

C++ at first seemed like an improvement, but as it turned out, C++ adds hiding to C without improving safety. Note that this seems to be unique to C++; no prior language did that, and no language since has taken that route. Attempts have been made to work around the problem within the structure of C++, but with limited success. The "auto_ptr" debacle and the endless problems of trying to make sound reference-counted allocation work reliably indicate the fundamental limitations of the language. You just can't fix those problems in C++ without breaking backwards compatibility. (See my postings in comp.std.c++ over the last decade for more details on this.)

Java was invented mostly to get around the memory safety problems of C and C++. The fact that Java is usually semi-interpretive has nothing to do with the language design; that's a consequence of Sun's original focus on applets. There are native-code compilers for Java; GCC contains one. There are competitive advantages of locking the user into a giant environment (J2EE in the Java world, .NET in the Microsoft world), which is part of why we're seeing so much of that. But it's not a language design issue.

Microsoft came up with C# as their answer to Java, and most of the same issues as with Java apply.

What's so embarassing about all this is that it's quite fixable. The solutions were known twenty years ago. If you have a language where the language knows how big everything is, and the subscript checks are hoisted out of loops at compile time, you get safety with high performance. There were Pascal compilers that got this right in the 1980s.

On the allocation front, you can use either garbage collection or reference counting to automate that process. Java and C# are garbage-collected; Perl and Python are reference-counted, and in practice, programmers in those languages seldom have to think about memory allocation issues. Allocation overhead can also be hoisted out of loops. Java compilers are starting to do this, allocating temporary variables on the stack. Reference count updates can be optimized similarly. There's nothing to prevent using these techniques in a native-code compiler.

And that's how we got to where we are today, with buffer overflows, zombies, and blue screens of death, papered over with a layer of inefficient interpreters. Fortunately the hardware people have held up their end and made it possible to live with this, but we on the software side should have the understanding and grace to be embarassed by it.

Re:The problem: our native-code languages are bad

[IamTheRealMike]

Well, programming languages are about the man/machine interface. Their design is very much a tradeoff between the needs of the humans that'll be using them and the needs of the computers that'll be running them. Simple example - adding features to a language makes it harder to learn but potentially more efficient.

The other thing is you have to separate language from implementation. Java isn't just slow because of the design of the language, but many other choices that went into it like using a virtual machine, having a massive class library, making it portable etc. It'd be possible to create a Java-like system that was as fast and as resource efficient as C++.

Programming languages are like real human languages ... we have a bunch of words, and people can use those words to communicate meaning, but some ways of putting words together will be "more efficient" than others. There's no one correct way to say it's raining, you could say "It is raining" or "Apparently our planet decided to send us the gift of precipitation today" - equivalent yet one is faster to say than the other :)

Re:The problem: our native-code languages are bad

[David's Boy Toy]

The tired old "in C++ you have to worry about memory management" myth. I've written substantial
C++ servers where the only 'delete' call was in a thread safe reference counted smart pointer class.
90% of the server code didn't need to be fast. I used std::string, and stl containers, no pointers
or C style arrays. Only where speed mattered (gigabytes being moved over TCP) did I use C style
arrays, memcpy. and the like. The program has had very few bugs, and none of these where memory
corruption related.

Program in C++ correctly and its as safe as the castrated languages. But your free to do "dangerous"
things when you need to, and it really does matter. Its usually a small percentage of the code where
most of the CPU time goes. In an interpreted language your screwed, want to do something the libraries
don't provide, your out of luck. Keep your dangerous code limited and encapsulated, and it becomes
quite safe. Small sections of dangerous code can be understood sufficiently to verify that they indeed
do what they are supposed to.

Re:The problem: our native-code languages are bad

[Animats]

But the _real_ issue is that there are times: 1) when you want arrays and pointers to be the same thing, and 2) when you don't

No, the real issue is that you can't talk about the size of variable-sized data in C.

If C had syntax like

int write(int fd, size_t length, char buf[length]);

instead of

int write(int fd, char* buf, size_t length);

then size information would be carried along with the data, and checking would be possible. In the syntax we have now, you're lying to the compiler; you're saying you have a pointer to a char, but you really have a pointer to an array of char of indeterminate length. That's the problem. Most buffer overflows arise from this language design error.

C++ tries to paper this over with collection classes, but raw pointers keep leaking out, and the hiding thus doesn't quite work.

Bingo

[Dr. Zowie]

I do a lot of interactive data processing. I use PDL a variant of Perl (which, recall, is JIT-compiled) that is designed for array handling. For most of what I do PDL is great -- the CPU spends most of its time waiting for me to make up my mind what I want to do, and moving my ponderously slow fingers to type the command at 110 baud. But some of the stuff I do (magnetohydrodynamic simulation) is exremely CPU-bound, and that stuff I write in C.

A lot of folks use languages like PDL, IDL, MatLab, Octave, or even NumPy to do array processing, and tout the fact that for large arrays those languages run "essentially as fast as C". But that's bullshit. All those languages vectorize their operations in exactly the wrong order - if you have a hundred million datapoints and you want to do six operations on each one, each of those vectorized languages will dutifully swap each of your hundred million datapoints out of RAM into the processor, multiply it by seven (or whatever), and push it back out to RAM before pulling them all back in to add six to each one. What you really want is to vectorize in pipeline order, doing all the operations you plan to on each data point once and for all so that you can take advantage of your processor's nice, fast cache. Nobody has (to my knowledge) figured out a way to do that, that is robust enough for an interactive/JIT language, so just writing it in "C" and getting the loops nested in the right order can speed you up by a factor of more than 10 on a modern AMD or Intel CPU.

Re:What?!?!?

[Sparks23]

I think the original poster meant that it's easier to debug the entire behavior of a C program than a Java program, which which I agree.

In Java, some of the behavior -- indeed, a lot of the underlying behavior -- when it comes to fine-tuning for performance, or 'why does this thing eat 400 megs of RAM?!' is hidden from the user; it's part of the underlying interpreter, and beyond the view of the debugger. In C, I can track my memory allocations and performance much more readily in a debugger than I can in Java.

I suppose I would've phrased it more that debugging a simple process is easier in Java or other interpreted languages, but debugging to performance-tweak is way, way easier in compiled languages than interpreted ones.

Getting lazy?

[twazzock]

Why is it that as soon as processors get more powerful, memory becomes cheaper and hard disks get bigger, the next operating systems and applications suddenly need a lot more of it; but still present you with essentially the exact same thing?

Programs written in interpreted languages need higher systems specs to run at the speeds we are used to. Sure, the modern systems can handle it no problem; but shouldn't faster computers mean faster programs and response times? Instead we get the same or only slightly faster results because we program them in slower ways because it's easier and faster for us to do it that way. Maybe we're all just getting lazy.

And with operating systems, I mean Vista in particular: by the system requirements you can tell it's a resource hog. I was horrified by the system requirements of XP when it was released, and after I upgraded and started using it I asked myself: 'What was the big deal? How is this better than 2000 besides a shinier interface?' What about Vista requires the system specs it asks for? The even shinier interface?

My one guess

[xant]

One guess where 99% of the ccycles arae in that

I'll take a guess! And it's even the one you want me to guess. The db2 instance. That's the fucking *point*. The fast C code that's executing has already been written.. some of it is in the python interpreter, some it is in the ksh and php interpreters, most of it is in the db2 interpreter. Very fast algorithms doing what they do best: optimized, super fast loops operating on static types.

That is WHY python and other interpreted languages achieve the speed they achieve.. because what they do is allow you to glue together C code written by other people. And, because the Python code is much simpler, you can understand the interactions between the fast code more easily, and see where your code fails to perform well. It's always because you're putting loops together inefficiently and making poor design choices, not because of the speed of the interpreter--and now that your code is short enough for you to see that, you can fix it.

Your application logic doesn't need to be super fast. It needs to be super agile, so you can refactor and accommodate changing requirements and make smart decisions about which pieces you are going to use and how you are going to use them together.

C won't die, at least, not for a long, long time*, and that doesn't bother me, a hardcore Python programmer, in the least. Somebody has to do the dirty job of writing those fast loops. Meanwhile I'll be here zipping through the application implementation.

*It will eventually be replaced by Pyrex, of course.

Re:My one guess

[nettdata]

Well said... too many people lose sight of the goal, and think that all eficiency boils down to CPU cycles.

In reality, it is a compromise between many factors, including cost, flexibility, rate of change, manageability, and performance.

The only REAL requirement is that it does its job at a cost that is reasonable and sustainable to the company.

If you spend 10 times more on development and increase time to delivery in order to save a small fraction of that on hardware, you've lost.

For what it's worth, we do ALL of our development in interpreted languages, mostly Java, some PHP, Ruby on Rails, etc., and it all comes down to whatever is the best tool for the job. Very rarely do we ever come across a situation where 2 clients have needs that result in the exact same tools being used, unless it's just to use tools that we're more familiar with so that we can get the job done faster for them.

It's all about balancing compromise.

Re:What makes you think Java won't rule the client

[vtcodger]

***What is it now, 2006, and Java came out around 1996?***

1990 actually. vs 1987 for PERL, 1990 for Python, 1995 for PHP, and 1995 for Ruby.

VMs have more information to make better choices

[bwbadger]

I think the parent has this almost completely backwards.

As the complexity of enviornments increases (many cores, multi-chip packages etc) it's going to be harder to compile a program to binary that can take advantage of the resources on all the systems it will run upon. It may work really well on one configuration, and may run on many, but it won't make the most of the resources in many cases.

VMs have access to information about the runtime environment and can dynamically compile byte codes to binary to take the best advantage of the available resources - some can even re-compile on the fly to tighten up performance based on feedback from the environment. From a developers POV a program can run on many platforms, and can run as well on all of them.

Re:What makes you think Java won't rule the client

[JulesLt]

I'm not sure that we've moved that much. I think Gosling and the other originators of Java are still pushing in the wrong direction with GUI; see his remarks on Eclipse / SWT.

It is not a Java problem per se, but goes right back to the issue of creating cross-platform client apps in the first place. Many of us like to think of the OS as something that provides services - disk access, windowing, etc - that look like they can easily be abstracted - and they can. However, as well as being OS, Windows, OS X, KDE and GNOME are platforms - a set of programming APIs and a philosophy.

Rather than transcending these differences, Swing is yet another variation. Potentially you could make a Swing app that did look and behave identical to a Windows app - but it would feel plain wrong on OS X. The reverse is equally true (well, just about - I don't think you can use the top-of-screen menu bar in Swing apps).

I think SWT may be the better approach - it's not write-once run-anywhere, but you are reducing the amount you need to port. And as said above, you need to consider the philosophical differences between platform HCI anyway.

Ironically one of the few really successful Java GUI apps I know is a data visualisation tool - it mostly consists of OpenGL calls so it's a bit of a misnomer to say it's Java, but it's back to the point that it's the APIs that count. OpenGL is a nice x-platform API.

Punctation!

[Anonymous Coward]

Java and C# are garbage-collected;

That's
Java and C# are garbage, collected;

Euro-English

[Doc Ri]

The European Commission has just announced an agreement
whereby English will be the official language of the EU rather than
German which was the other possibility. As part of the negotiations,
Her Majesty's Government conceded that English spelling had some
room for improvement and has accepted a 5 year phase-in plan that
would be known as "Euro-English".

In the first year, "s" will replace the soft "c". Sertainly, this will make the
sivil servants jump with joy. The hard "c" will be dropped in favour of
the"k". This should klear up konfusion and keyboards kan have 1 less
letter.

There will be growing publik enthusiasm in the sekond year, when the
troublesome "ph" will be replaced with "f". This will make words like
"fotograf" 20% shorter.

In the 3rd year, publik akseptanse of the new spelling kan be
ekspekted to reach the stage where more komplikated changes are
possible. Governments will enkorage the removal of double letters,
which have always ben a deterent to akurate speling. Also, al wil agre
that the horible mes of the silent "e"s in the language is disgraseful,
and they should go away.

By the fourth year, peopl wil be reseptiv to steps such as replasing "th"
with "z" and "w" with "v". During ze fifz year, ze unesesary "o" kan be
dropd from vords kontaining "ou" and similar changes vud of kors be
aplid to ozer kombinations of leters.

After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor
trubl or difikultis and evrivun vil find it ezi to understand ech ozer. Ze
drem vil finali kum tru!

Re:Euro-English

[andymadigan]

I'm a USian and I can read it as well, I hope I'm not the only one who noticed that read straight through it sounds a bit german.

Re:Euro-English

[santiago]

This is a recent adaptation of the 1946 article "Meihem in ce Klasrum" by Dolton Edwards published in Astounding Science Fiction (and, on the internet, usually incorrectly attributed to Mark Twain, like a great many other humorous things whose origin most people are uncertain of).

See http://www.spellingsociety.org/news/media/spoofs.p hp#meihem for some historical versions.

The End of [Insert Something]

[suv4x4]

I'm sick of cliched sensationalist articles with the sensationalist titles, how about you?

As always this is a non-existant problem hyped up by people that don't have a clue.

First, the performance hit of managed code is not "negligible". For tasks that rely on raw math power it can be significant, like 3D engines, data processing and so on.

But if you're doing, say, a rich client, your code will most likely just call existing multimedia, communication and input API-s. Then managed code's performance hit is next to nothing since most of the time is spent processing the commands from the API-s, not your own code anyway.

Thing is: can we drop the raw power of native code and go all managed: hell no. And we never will. While plenty of consumer applications have good performance on managed code, there will always be a class of professional software where 20% better performance means potentially tens of hundred of dollars saved for a middle-sized company.

But the big miss in the article is that managed and non-managed code can coexist. In .NET this is pretty easy: "unsafe" sections and "managed" sections can originate in the same project and even the same source code, so you can optimize those critical 10% of your code where 90% of the time is spent (you prolly know the cliche), and use managed to take benefits of the advancements in the platform.

So wait, we were talking about end of what again?

New binaries for every architecture

[amightywind]

Are you going to compile new binaries for every architecture and combination of cores?

As a Gentoo user that is an emphatic yes!

you'll learn

[m874t232]

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.

Re:you'll learn

[arevos]

You've gotta be kidding me. Whatever. Listen, if you suck so bad that you can't just jump into a language and write, you should go back to school.

Your ignorance of the limitations of programming languages demonstrates that you're young, and still have a lot to learn. Your ability to devise a coherant argument is also somewhat lacking.

Again, I'm being rather blunt, which, admittedly, may not be the most diplomatic approach.

Consider this tutorial. It demonstrates how, in 20 minutes, you can construct a simple wiki using Turbogears and Python. If there is no disadvantage to using C++ in any programming task, then it should be a relatively simple task to achieve the exact application in C++ in the same time period.

I'll be honest with you: I couldn't write a wiki that fast in C++. It would take me 20 minutes just to get to grips with CGICC and the MySQL C++ API. I'd be lucky if I got it saving a single page, let alone an all-singing, all-dancing, AJAX-enabled wiki.

This example is loaded, in that C++ doesn't, to my knowledge, have a rapid-development MVC framework like Turbogears. However, it's loaded for a point; a programming language is more than the sum of its syntax. The worth of a programming language is also determined by many external factors, such as the libraries and frameworks written for it, the speed of the compiler, what IDEs support it, and so forth.

That's not to say syntax isn't important, but it's easier for me to demonstrate the worth of libraries than it is to go into the more abstract benefits of metaclasses and higher level functions.

If you want to argue your case, come up with a decent argument against the points I've raised. If you can't, then at least consider the possibility that you may be incorrect.

simple

[m874t232]

There are several reasons.

(1) Java's market presence for UI applications has been decreasing: applets have largely disappeared, and the JRE is preinstalled on fewer and fewer desktops.

(2) Even on OS X, where Java is pre-installed and exceptionally well supported and integrated, there are few applications written in Java, and even fewer written in Java using Swing.

(3) Java's UI classes don't integrate well with native desktops, and it is impossible with them to write a cross-platform UI that conforms to every target platform's conventions.

(4) Within the span of just a couple of years, Mono and .NET have already far surpassed Java desktop usage on their respective platforms (and Mono makes both sets of APIs cross-platform if you want).

(5) Sun's licensing and compatibility requirements have made Java unattractive for Linux desktop distributions, and it seems doubtful that that will change (it looks like Sun may open source their implementation, but the specs will probably remain restrictive).

(6) As far as cross-platform GUIs go, the most widely used tools are wxWidgets, Qt, Tcl/Tk, and Gtk, plus their various language bindings (even Eclipse uses its own toolkit, not Swing).

But at some point Java/Swing programs will have accumulated enough performance and features that they are good enough for what people want to do, and they have the added advantage of not being tied to Windows.

And that attitude is why Java/Swing isn't succeeding. As a Linux and Mac user, I don't want cross-platform scraps thrown to me, I want high-quality applications that integrate well with my desktop. And given that people are creating those based on Gnome, KDE, ObjC-Cocoa, and Mono, I have no incentive for using Java applications. Of course, Windows users don't have any interest in third-rate Java replacements for their native apps either, and .NET is a better platform for developing Windows apps anyway.

Even better, the Gnome, KDE, and Mono apps even run on Windows, so that even Java's cross-platform aspects are uninteresting.

SUN seems to be in this Java business for the long haul,

Well, that's another problem: I think many people are unconvinced that Sun is in anything for the long haul; the company has serious problems.

Re:simple

[julesh]

As a Linux and Mac user, I don't want cross-platform scraps thrown to me, I want high-quality applications that integrate well with my desktop.

What few people seem to have realised is that the best way of achieving cross platform portability is not to throw out the systems you're porting to and implement everything from scratch (the AWT/SWING approach). This just results in applications that feel wrong whichever system you run them on. The answer is to use native widgets in a way that is flexible enough to allow the toolkit to decide look & feel issues rather than the programmer. Sure, it's a little harder to write for (you'll probably find yourself doing stuff like writing an XML definition of how the interface should work rather than directly manipulating controls, which is a little more abstract and maybe a little harder to work with if you're aiming for something other than trivial interactions), but the results are so much better that in most cases it's worth the tiny extra effort involved.

Article title should be: Java/C# vs C++

[zaphle]

- Any decent C++ programmer will always put the OS-specific code in an abstraction layer. C++ has many ways of allowing this, ranging from macro's to templates and everything in between. These features even enable portability without sacrificing speed, since the choice of function happens at compile-time. So this so-called portability issue just doesn't hold.

- For a lot of applications, optimal performance simply is the only way to get the job done. JIT Languages often have high-level objects providing functionality that takes lineair time where one would expect constant time performance. Building these objects yourself int a JIT language simply isn't going to make things run any faster, since the atomic components have to much overhead to be good candidates for such low-level operations. C++'s STL templates on the other hand have well-defined operation times. By the way, these lineair/constant time issues won't just go away as computers get faster.

- With JIT-languages, you have no control over the underlying virtual machine on which the program will be running if it's a program that will be downloaded by many people and run on a client machine. If that VM has a security flaw, then your program will have one too. With precompiled programs, you can choose your compiler and have full control over security. You can even decide to link statically to minimize the number of external dependencies that could be a security threat. He who controls (or manufactures for that matter) the VM also controls your program. God knows who's out there wanting your program to be less performant than theirs. And how will you ever find out?

And finally, just take a look at topcoder.com to see what programming language is used most by the people occupying the top 10 highest ranks. It's not a JIT language, but C++. That alone says a LOT to me.

Am I biased? I've written in both C++ and C#. While I even enjoyed writing in C#, I never felt the power as I felt while writing in C++. True, for every downside there's an upside to the JIT languages, but IMHO, the cons of the JITs just don't weigh up to their pros.

Native code will and should always be around.

In 1997

[lapagecp]

I had a pentium 2 233 with 64 megs of ram and a 6 gig harddrive. I primarily used my computer to run windows, ms office, diablo, IE and Netscape, winamp, and an antivirus program. Today I have a brand new computer and do almost the same thing. I run a "better" version of windows and office, I have a "better" video game or two, I run a newer improved IE and Firefox, still have winamp but its "better" than the v2 I had, and I have antivirus from the same company. The only thing new is a divx player. So how come with 10 times the processing power and 8 times the memory and 50 times the harddrive space its not really all that much faster and in some ways it slower. Could it be how things are coded these days. No that can't be. Newer is better.

Philosophical reason why higher level is key

[eyefish]

There is a philosophical reason to go to a high-level for all this. If you observe evolution in all its forms it always goes from low-level stuff to high-level stuff (from tools making to society behavior, with countless examples in all fields like business, economics, etc). In our brains, it just make sense for us to always think in ever-higher levels, because if we had to keep track of all the previous details we'd spend more time dealing with details than with the goals of what we're trying to accomplish.

Note that this is nothing new in software engineering. Most software a few decades ago was written in low-level code, even assembly language. If you did a survey then about the ratio of low-level to high-level coding, and compare it to a survey today, you'd realize that we do not even ponder about where things are going, as there is plenty of evidence today to tell us that going higher-level is the path the software industry is taking.

Native coding will become more and more of a niche, first to do Operating Systems, Drivers, Kernels and such. But eventually I can see even a fully-operational OS being written in a high-level language. In a sense that's what's happing today when you combine all the Web Services and tools we find today on the Web.

So, it's just a matter of time before everyone codes in high-level languages, and even today's high-level languages will seem low-level by what we're going to replace them in the future.

Scoping

[Goblez]

The level of control you need as a programmer is related to the work that you are doing. If you are writing an O/S, low level network app, embedded system app, etc, then you'd better have the control afforded by non-managed code. If you are just writing web-based business logic programs then higher level languages are a better fit. Overall though, as they move languages to fit the lowest common denominator those of us that were forced to learn the lower languages will find their value increased. Not to mention that those understand the more diffcult programming concepts encompassed by managing memory or multithreading are going to better grasp other languages and complex concepts (if you don't believe me, study compliers and see how related all programming language concepts are).

Now who else thinks the first 100 comments on this thread are what make slashdot a venting forum for offtopic issues?

Swing/SWT and Open Source Java

[beemishboy]

Well it's time for another opportunity for Java to take off on the client side. I think it might have a chance should a couple of things happen.

First, Sun needs to open source Java. There are tons of bugs in Swing and that section of the code could benefit the most from the open source community in my opinion. Sun has been negligent of Swing off and on in favor of more profitable ventures on the server or on mobile phone specific stuff. If, instead of voting on your highest priority bug on sun's dev site, people were actually able to *fix* bugs...If, it were set up so that new features could be added fairly quickly, Sun could see Swing swing into action. If they don't open source Java or have too much bureaucratic work involved, then Swing might just be left as a hobbyist prototype-like portion of Java.

Second, I wonder if SWT will catch on. Eclipse is doing some very good work with 3.2 and the synchronized release of several projects in Callisto (http://www.eclipse.org/callisto). They are making it easier to do SWT client-side apps. If they execute well and developers pick up on this, Java could also make it big on the desktop.

I think both have to occur for Java to really take off on the client side though. We'll see.

More Java Propaganda..

[Fejimush]

This is another fine example of an article, by a member of the Java community, which attempts to wrestle the Java language from its stereotype of being used in mostly CPU idle applications. The whole notion of moving completely towards interpreted language applications is laughable. Java has its place and uses; web applications, gui interfaces, and anything else that's sits idle 99% of the time. The argument that processors are fast enough to run all applications written entirely in an interpreted language follows the comment, "Who needs more that 640k of memory?" That's easy to answer, everybody that likes to push the performance envelope, write a deterministic application, benchmark their system to death, or tweak a system to the hilt for sh*ts and giggles. There are a lot of folks in this category. Embedded application engineers relying on deterministic behavior would be foolish to get in bed with Java. Sure Java can make it last longer, but we want a quickie this time. Sorry, no time for foreplay. Trying to get something to happen every 5 microseconds, such as a good portion of modern medical equipment, would be tough with Java garbage collection and etc. looming nearby. Have fun sorting that out. Sure it can be turned off but there are numerous Java related barriers preventing high performance deterministic behavior. Found a bug in the JVM? Ugh, try debugging that or worse try to get Sun to do it without a truckload full of cash. Writing a cutting edge game? Could you imagine a project manager asking engineers, how can we make this Java coded game run faster without impacting the schedule much? Oh..Oh..Oh...me! I can answer that! Try C/C++ with inline assembly where needed and throw out the Java code. He'd pass out. The Java versus C++ battles are as contrived as they can get. Why does the Java community pick on GCC and a limited set of code examples? Then they use Sun's flagship Java implementation against an open source compiler. That's like pitting Pee-Wee Herman against Mike Tyson. The simple reason is Java can't hang with a reasonably complex high performance application written in C/C++. A better route than trying to push Java bloat on the rest of the developer community would be to deep six Java all together and push for a standard C++ threading model (boost threads), network interfaces (many already exist), a windowing framework (give us something better than the FLTK), and etc. With these tools in hand code written in C++ can be compiled for a wide variety of platforms more easily. We get the speed, flexibility, multi-platform usage with the same code base, and most importantly we can say bye-bye to Java.

Redundant, but...

[bryonak]

If I had to have a programmer code a not-so-trivial application for me, then...

I wouldn't trust him to do it properly if he had no experience with low-level languages, because it is my opinion that a good coder must understand what happens between his code and the hardware aswell as he should have some knowledge about optimization and mission-critical algorithms*.

I wouldn't pay him if he had no experience with high-level languages, because he'll end up using too much time coding and optimizing instead of planning and designing the application structure, management, etc.


Of course, if I needed a non-mission-critical GUI-app to be coded within a short timeframe, I certainly wouldn't ask for a programmer with years of C-experience, but still the additional knowledge wouldn't hurt.
Once again, The-right-tool-for-the-right-job (tm) is the way to go.

Replacing most of the native code with interpreted one? Nah. You wouldn't want your database software/search engine/OS/compilers (calm down, just kidding) coded in a high-level language, would you?
IMO, low-level won't die, since there will always be need for mission-critical programs... and there's still something the high-level code needs to run on.

*Yes, these are necessary. How many search- and sort-algorithms do you know and know how to code? How many modern applications can do without? How many of those algorithms can be, of course after some optimization, executed in C (or Assembler if you really need those cycles...) much faster than in any high-level language?