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

[Maxo-Texas]

Thank you.

The entire question was ruined by that one idiot word.

I can understand if a casual poster let's loose with a few loose looses.

But the *editor* and creators of content should spell the word correctly or they just
come across as ignorant.

What really doesn't make sense is that "loose" is LONGER than "lose".

And it's not spelled like it sounds.. "Looze" which I could also understand.

So it is inefficient AND sounds different than the word is spoken.

Re:What else

[fyngyrz]

It's maroon if you red carefully, anyway.

Re:What else

[EonBlueTooL]

I find it ironic that it was spelled correctly the second time.

Re:What else

[Dasch]

I know a guy that works at IO Interactive (maker of the Hitman series,) and he told me they only write in C++ and ... Assembler. Hows that for interpreted?

Not that I wouldn't like to use Ruby for all tasks...

Re:What else

[Hognoxious]

Alanis? Is that you?

Re:What else

[frank_plenty]

Your entire posting was ruined by one idiot apostrophe... "... let's loose..." Aaaargh!

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

[Overzeetop]

I once worked for a guy who interviewed a programmer candidate, and the candidate was very smug in his suggestion that he coded in every language available at the time (this was circa 1988). When the candidate asked which language we used for our system, the interviewer replied, "we use machine code". It turns out that, at the time, we were _extremely_ sensitive to how the code ran. We had a number of early 1970s era machines which were used in the timing of 200ps laser pulses reflected off satellites in 5000-9000km orbits, and were detecting motions in the earth's crust using those laser time-of-flight measurements. In out case, we couldn't trust a commercial compiler. Now, in the era of $99 laser measuring devices which are accurate to 1/4" in 100', the project seems relatively simple. When I was there, we had this "new" system coming on line that used this new device called a CCD to detect the return photons (and, yes, at times we were counting individual photon returns in a 30" telescope).

Re:What else

[merlin_jim]

I've done benchmarks. I've run simulations. I've compared native code to managed code for the same thing. I used to hand code assembly routines for optimisation, so I know a thing or two about optimising native code too.

Most of the time the difference after loading is so similar that its not measurable. You see the big performance hit in .NET when loading or installing your libraries and they get translated to native code...

DirectX gets between 90 and 95% native performance when running through the managed libraries.

The only native code I called directly in that project was the Intel Performance Primitives - and that was only because it had an existing FFT library, and it could do MMX / SSE / SSE2 array moves (cost of 0.3 clocks per 32-bit word)

I'm speaking as someone with experience; I would absolutely write a game (or any other high performance app) in an interpreted language - its faster development, better code with fewer errors, and the performance difference is so little that I don't let it bother me...

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.

Re:What else

[gbjbaanb]

I recall the Quake 2 port that some people did and posted on MSDN. (they took the native quake 2 code, compiled it using the new .net compiler in native mode, then they added the 'run in clr' mode switch and made as few modifications as were needed to make it compile under the managed runtime. No other changes at all, pretty much exactly the same code was compared.)

So for an absolutely objective test, the managed version was 10% slower. While the article said 'only 10% which si nott very much nowadays', it is still a significant performance hit. Now, if you write code using the libraries and easy-to-use features in the managed system, you'll likely see a larger hit simply because you're not handling memory (especially) or other resources as efficiently as you'll be using the stuff that 'does it for you'. An example: I wrote a simple database update tool for a one-off upgrade task. As it was a one-off I thought I'd knock it up using .NET as it'd be easy. And it was. Trouble is, it was so slow it was unusable. So I spent some time optimising it (stringbuilders, removed the datagrid GUI part, etc) and it was still too slow. We looked at what it was doing and it spent a lot of time allocating and freeing memory (a *lovely* sawtooth memory graph, lol). So I rewrote it in native oledb, and the performance difference was huge, instead of several hours, it came down to 12 minutes.

Now I'm not an expert .net programmer, but I am very experienced, and I tried everything I could to fix the .net problem, and I think it was the .net db-access classes I used doing things for me and not worrying about memory internally that was fine for a small dataset, but useless for a large real-world database. (I understand it uses xml internally... what a mistake, no wonder it was slow)

So, managed code is fine, depends on what you're doing, but never ever expect it to be just better than native because it says so on the tin. Apart from poor programmers using it as a crutch to doing things properly, it won't necessarily be beneficial. (another quick anecdote: I was called in for a job interview for a performance engineer - the company had rewritten their email archiving software in C# and it performed extremely badly. Terribly actually, and they *had* to get it fixed otherwise the company was in trouble - what with the amount of money they'd spent on rewriting it. Remember that when anyone tells you you must rewrite in the latest, coolest new language toy).

Re:What else

[mausmalone]

The real future of interpreted language programming is on the web. With advances in Javascript, CSS, browser compatibility, and server-side languages, you can pull off a lot of really cool stuff in a web application. A web application that can be accessed at any time from anywhere. For many tasks, it's quite helpful.

Re:What else

[mjmalone]

If you're writing higher end programs like games, I would recommend cross-platform libraries in a native language.

FWIW, an interpreted language has pretty much the same benefits and drawbacks as using a cross-platform library in a native language. In fact, it pretty much is a cross-platform library in a native language...

Re:What else

[Citizen of Earth]

Red ship crashes into blue ship - sailors marooned...

Re:What else

[Maxo-Texas]

Ah, but I'm a casual writer of a quick off the cuff post not an editor or a content creator.

And I don't habitually u'se apostrophe's incorrectly.

Re:What else

[ealar dlanvuli]

Repeat after me, JIT compilers are not interpreters. If your code is important enought to hit the compilation phase, it turns into native code.

It's a really simple concept.

Re:What else

[ealar dlanvuli]

Garbage collector collection phases are not a performance bottleneck. In fact, a GC language is amortized faster than a language where deletes happen as soon as possible. It is possible to code a real time garbage collector for Java at least (I don't see a problem with C# but I've never studied the internals).

Just because some poorly written virtual machines are slow, does not mean garbage collection phase has to take an appreciable amount of time.

Re:What else

[TheUser0x58]

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.

Losing the finer grains of computer science? Such as pointer arithmetic and inline assembly code? Ill have Java or Python's take on computer science over C/C++'s any day.

Re:What else

[Just Some Guy]

Sure, if you're writing apps that are fine slow, interpreted doesn't matter.

Assuming, of course, that "interpreted == slow" (and that bytecode language are "interpreted") - which is demonstrably false. The trick is to let the language do as much as possible. For example, writing mylist.sort() in Python is infinitely preferable to writing your own list sorting function (in Python) and using that instead. Similarly, using map() to apply a function to each value in a list is almost always going to be faster than manually iterating across it.

Again, let a language do what that language does best: implement itself. Learning what it's capable of and taking advantage of that will give you reasonable performance in all but extreme cases.

Re:What else

[SnprBoB86]

The editors would not have had this problem if they were using Word 2007 Beta 2 :-)
http://blogs.msdn.com/jensenh/archive/2006/06/13/6 29124.aspx

Re:What else

[w1ll0w]

I've only known one company that used managed code for a game. They used c# to write it. I admit I never looked at the code and don't know what kind of optimizations can be done on managed code but it ran horrible, like 20 frames a second plus the hiccups when garbage collection happened. The simple fact is that interpreted languages have overhead, nobody can deny that. If you are writing a game any cycles taken away from the game is bad. So business apps are fine in my opinion, I use java to write those sometimes, but for applications that can't afford the hit need to be written in something lower level.

Re:What else

[merlin_jim]

but it ran horrible, like 20 frames a second plus the hiccups when garbage collection happened.

Yeah the trick there is never garbage collect. The program I wrote was an interactive music / sound-driven visualization app for club light effects - and at the price clubs were paying for it, it had to run without a glitch.

Doing high-resolution FFTs on the data, applying that to a genetic algorithm cellular automata to draw the pretty visuals, and using DirectShow and DirectSound to interact with hardware, I was hitting 20 fps consistently on a 1.2 GHz mobile processor.

It took some minor optimisation to get there, but nothing serious. Biggest things I did was change a few arrays to unsafe fixed - making them traiditional C-style arrays, basically - and the things I did need to allocate from the runtime I only allocated once. After my initialisation code is done I never allocate anything. That would be the only way to write a managed code game unless you aren't real time enough for garbage collection to matter...

The only other really difficult thing when working with managed code in game writing is typing - there are certain types (such as the signed shorts for audio data) that don't have a managed representation - I forget how I got around that one, but I know it involved using unmanaged code libraries to work with the data unless I absolutely had to. I think when I needed to access the sample data directly I ended up doubling the word size and using signed ints...

Re:What else

[Mark Programmer]

While there are some libraries that blur the line, I'd have to sincerely disagree.

Take Python for example, and compare it with C++. You can do the same things in both languages. But what C++ cross-platform library or framework gives me runtime object mutation and reflection? First-class functions? Namespaces (importable at any point in the runtime)? Type safety and introspection? Universal serialization (or "object save and load," or "pickling", or whatever one's favorite buzzword is for having a default strategy to contain any data in a static long-term storage form)? A built-in debugger? An interpreter that can allow me to pause execution and modify the runtime environment while a program is executing (including modifying the source code, re-compiling it, and re-inserting it into the environment without restarting the process)?

And more importantly... if I have those features in library A, how do I get them in library B?

While one can obtain some features in a low-level language through proper choice of libraries, a high-level language demands those features exist in all code, and that they be accessible through an agreed-upon syntax. As Paul Graham notes in this Lisp-related essay, that's one of the reasons one would bother to learn a new language---because languages are different at a level deeper than the libraries available to them. Remember, C++ started as a simple extension to C---eventually, a point was reached where it became its own language, and there are in fact valid C programs that are not valid C++ programs.

On the flip side of the Python/C++ coin, by the way: how does Python give me pointers and explicit memory management?

Re:What else

[mjmalone]

I think you actually do agree with me, to a certain extent :).

What I meant was that there are few disadvantages to using an interpreted language when compared with a native language + libraries. As for things like introspection, first class functions, etc. many of them actually _can_ be imitated in a native language using a library/framework. In C++, for example, you could use multiple inheritance to define an 'interface' of sorts that returns class identification info to build in a naive form of introspection (assuming you don't want to use the C++ RTTI facility). Then you simply require all classes inherit from that 'interface'. As for first-class functions, you can create a similar base-class function object (or functor) by overloading the () operator. Whether either of these solutions is elegant is irrelevant (they're not), the point is simply that it's possible.

I take that back, that's not the point at all... The point is that these fancy 'hacks' that imitate things like introspection and first-class functions in native languages are no more efficient than the mechanisms that are provided in interpreted languages like Perl, Python, PHP, etc. So why not just use the high-level language that is easier/cheaper to work with? I've begun to take 'premature-optimization' seriously, as I have found that I end up wasting inordinate amounts of time trying to make code more efficient, then finding that the 'slow' wasn't even a bottleneck in my application. Seems to me that it's quicker/easier to write in an interpreted language, then optomize any bottlenecks (perhaps even by implementing a particular function in a native language!).

Re:What else

[WhyMeWorry]

Your comment suggests that you only do one thing on your computer at a time. I am generally running many background low-IO processes on my computer at the same time. Wasted cycles for the interpreted language interfere with productivity.

Re:What else

[w1ll0w]

Yeah I almost laughed out loud when I found out that java didn't support unsigned chars, then I cried. It sucked having to work around all that. I've heard that to that having a large memory foot print helps and then not dynamically allocating. But on these consoles dynamic allocation is a must due to the limited resources, there are ways around it like memory pools.

Re:What else

[frank_plenty]

Hmmm... fair point. For the record, I do think that 'loosing' had the effect on my brain of switching from 'this is interesting' to 'this is written by somebody who can't spell', but then I don't buy food from shops who advertise sandwich's! All the best...

Re:What else

[julesh]

Absolutely. I've worked on projects using the Java language but targetting a native code environment through an ahead-of-time compiler. It's not the way the language was designed to work, but it can be made to work, and there are advantages to doing it that way (in this case, a lighter-weight distribution package due to not having to include a JRE, and faster start-up times due to lack of JIT overhead).

Re:What else

[julesh]

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.

Two problems with this statement:

1. An interepreted environment does not necessarily mean that mark & sweep garbage collection is in use. 2. With a generational garbage collector, you don't usually have to scan pages that haven't been modified since the last scan (as these are in old generations and their pointers are already represented in the set of roots for the newer generations), which means you usually only scan stuff that's already in core (except in exceptional low-memory circumstances).

java.io really sucks for some types of apps as it basically forces you to have one thread per socket

Agreed. Java's IO packages are pretty bad; I wasn't really thinking about Java when I wrote this. :)

Re:What else

[petermgreen]

2. With a generational garbage collector, you don't usually have to scan pages that haven't been modified since the last scan (as these are in old generations and their pointers are already represented in the set of roots for the newer generations)
But surely sooner or later those older generations still have to be scanned in a long running application. What happens then? loads of swapping in i bet!

Re:What else

[jma05]

Unless you are working on SDL itself, using SDL from C++ or should show no performance differences in your game.

Re:What else

[jma05]

> Unless you are working on SDL itself, using SDL from C++ or should show no performance differences in your game.

The above should be...
Unless you are working on SDL itself, using SDL from C++ or an interpreted language, it should show no performance difference in your game.

The angle brackets I used in the previous post swallowed the text as a tag.

Except Java, none of the other languages are obsessed with being "pure" and make liberal use of native extensions for performance. This is the optimal way to program.

Re:What else

[eonlabs]

From the sound of everyone's argument, the benefits of an interpreted language can be completely matched by a well coded kernel library of higher level functions.
There is no point to interpreting a language if the same functionality is already available in native code. Since the hardware within a given machine is fixed, converting an interpreted byte code into the native with an AOT compiler seems to be the most sensible use for interpreted code. It should be done once on install.

This is the modern CISC/RISC argument, in which people want to have all the functionality of a high level language without any of the complex code in the base. Interpreted code does not run faster than native, and the use of hybrid code supports that statement. Comparing how something like DirectX or OpenGL handles in java to C++ or C is not a valid comparison. It's two batches of native code.

The fact that garbage collection seems to be more efficient than sporatic cleanups makes sense, and should probably be considered when writing in a compiled language. Some variant on smart pointers would allow that principle to be used in C or C++

The arguments for an interpreted language can all be covered by a high level API in a native language. Why waste clock cycles interpreting every single add. It just slows down the system, and while the individual program may have no problem running, the overhead causes plenty of annoyance when you try to run 3 or 4 moderate programs at a time.

The only saving graces for interpreted languages are they tend to have a significant codebase to start from, and the same (compiled to byte code or raw) code will run on any supporting platform. This means anyone writing in java has a standard pattern to work from, and if they code well, anyone with experience in java can understand the code relatively easily.

If a compiled language started with a significant common api that was guaranteed to perform consistantly on various platforms, the 'problems' posed by them would be a moot point. This is why libraries like MING and SDL exist. They are an attempt to solve this. The major issue is they're being written for languages with such an extensive swamp of code that the odds of a standard surfacing are slim to none.

Re:What else

[Watson Ladd]

Then a mark-and-sweep is used. It only has to deal with a few unreachable objects as the generational collector was working on the active region. That's why generational GC is used. It is cheap, and makes other GC's cheaper when they are run.

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?

[Ant P.]

I'd still be coding the frontend in PHP, since any sane admin with something that size wouldn't be running webservers and database servers on the same machine anyway.

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?

[bryxal]

Maybe you should ask Yahoo...

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?

[Geeko Roman]

Some of us program things that will always and only be on one platform, and for us at least, we require real-time accuracy and access to the lowest levels of the processor. I am not opposed to the idea of using an intrepreted language, but as it is, I have to convert C++ to C, then to assembly, then hand-tuned to optimize, so I doubt this will be an option for us for a long time if ever. Yes the hardware will increase in speed across the board, but our capabilities/features per box would expand to match ( to soak up all available resources )

Re:Have you tried coding anything hard?

[protohiro1]

Uhh, the display layer? That is a great architecture a lot of people with huge apps are using. Backend in compiled c (including the RDMS of course) and display layer in php/perl/python. Scales all the way up to the size of yahoo and google.

Re:Have you tried coding anything hard?

[rammadman]

I worked on a data analysis application, which can insert 10 million records per hour. The machine was a 4 by processor AIX box running IBM's J2EE server with DB2 backing the database. The data was loaded through the java engine running in the J2EE environment. Queries were low because only managers had access to the system. The incredible rate proves modern JIT systems compare very well with native code. However poor object use can cause the modern platform independent languages to come to a halt trying to recover memory.

Re:Have you tried coding anything hard?

[ceoyoyo]

The other problem with interpreted languages has always been GUIs and ease of use. Java has gotten a LOT better. A few years ago AWT was klutzy and Swing was VERY obviously not native. The Java applications that people package as part of a .app on OS X can almost be mistaken for native Cocoa apps. I assume it's much the same under Windows and Linux.

There's nothing to show that a Python app on OS X isn't a native Cocoa app. Not sure if things are that advanced on the other platforms, but it's pretty impressive.

Re:Have you tried coding anything hard?

[minion]

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.

You just hit queries per hour, what our software hits in 12 seconds. We average 5,000 queries a second, for a large EMR (Electronic Medical Record) application, with approximately 4,000 users. Our software is web based, written in C, using MySQL as the backend. We're currently sitting at 16T of storage as well, with a growth of 2G per day of new data.
 
PHP has its places - extremely large, mission critical applications are not one of them.

Re:Have you tried coding anything hard?

[Bodrius]

I'll take that guess at the 90% of the $$$: development, just like in any non-trivial development project.
If his 90% of dev cost is less than your 90% of dev time, he has a lot more to spend on chips for his cycles.

Even so, without looking at the code, I wouldn't be so quick to take that guess on the cycles. I've seen my share of crappy native code, and you're more likely to find unfounded skepticism on the perf issues ("it's impossible this code is the problem, it's native!").

The native vs managed code is misleading anyway, because neither the greatest benefits nor the biggest disadvantages of either side is tied to the concept of a VM.

X Language != Y Language just because they have (or even share) a VM, and the feature price can often be paid elsewhere for the differences that matter:
- strong vs weak typing?
- implicit vs explicit memory management?
- declarative vs functional vs procedural?
- etc. etc. etc.

Re:Have you tried coding anything hard?

[afgates]

My response to this would be that you described a data warehouse, not a monolithic data application. When you have multiple RAID arrays with the accompaning dozens of read heads, dedicated 4x processors for each box(8-16 production boxes with 4 to 8 failovers I estimate?), you can solve your speed problems with scalability, but at a major cost in equipment and support. This isn't an example of good programming, its just an example of good systems architecture. Call me back when you have to do this same task with a single processer in a 1 meg embedded memory space.

Re:Have you tried coding anything hard?

[donglekey]

He just said that it worked for him, who are you to tell him it doesn't?

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?

[jcr]

There's nothing to show that a Python app on OS X isn't a native Cocoa app.

Actually, since a PyObc app is using the Cocoa libraries directly, saying that they're not "native" is a bit of hair-splitting. I wouldn't necessarily say that an app written in an interpreted or JIT-compiled language isn't native.

-jcr

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?

[chachacha]

I'm with you.

I would bet that most of your app is proprietary libraries and it's all written in native. In the parent's case he's farming out a significant amount of the processing to a database (db2) which is not proprietary, but I'd bet it's written in native code. Funny how when people say "I wrote a php program" they usually mean "I wrote glue code".

So in both cases the heavy lifting is done in native code. FYI, most of the work we do here is in Perl and we see /major/ performance problems constructing complex object trees.

Re:Have you tried coding anything hard?

[tacocat]

PHP has its places - extremely large, mission critical applications are not one of them.

I keep hearing people putting down PHP. It's not the only interpreted language. I also hear of Python being the best thing in the toolbox.

Seems to me that if you can put your personal bias aside then just about everything can be run with some form of an interpreted language playing a core component of the overall application. After all, isn't HTML/Javascript considered interpreted?

Apache is written in C. So are all the databases one might use for a backend. All you are describing is the use of a middleware that isn't written in a compiled language being a viable candidate for enterprise applications.

I would tend to agree simply because I work in a Java house and I work on Perl and I can develop an application in Perl about ten times faster then can be developed in Java. Am I an Uber Coder? Not a chance. But I can get feedback on my applications performance as I write it making it less error prone and easier (IMHO) to debug.

Re:Have you tried coding anything hard?

[Alomex]

50,000 inserts per second? What the fsck are you doing that for? Are you logging each packet individually? 50,000 inserts per second means 72 million transactions per day. Only the largest web sites in the world see that type of transaction rates.

Re:Have you tried coding anything hard?

[orkomedix]

I think you hit the nail on it's head:

C, lets consider C is stuff like GTK, is not as hard to program with as it used to be ! I have done in my (poore) experience at the universitiy image processing tools in Java and they where not that slow, but I am doing now some programming for real time video processing with a gtk-lib and it is just as easy as java. A lot of work, when you need something to be done quickly, is nice in Python/Ruby/Java or whatever, but SOME parts need to be quicker than the rest. So I think the User-Part (I am talking of a little more than a simple GUI) is perfect in Python or whatever youre taste is like, but the core still needs to be done in C. And C is faster on a single core and on a double core. And since there are lots of wrapper you can use the C-powser easy with your Python. Why are discussions like that often like "It needs to be this or that, black or white, good or bad..."

Modern programming is more about combining the strength of different "tools" than finding the one and only tool.

Re:Have you tried coding anything hard?

[jspraul]

I'm pretty sure the only important part in your list is the 'db2' part.

Re:Have you tried coding anything hard?

[julesh]

PHP gets messy past about 2000-5000 lines of code [...] no closures of course

As I'm currently working on a PHP project that's about to hit 8,000 lines of code and is showing no signs of stopping that upward climb in the near future, I understand most of your concerns. But none of them are killers.

You should be aware, BTW, that closures can be simulated quite easily in PHP, as they can in any dynamic language that supports 'eval' thus:

<?php
    function makeclosure ($object, $method)
    {
        $name = uniqid ('closure');
        $GLOBALS[$name . '_object'] = $object;
        eval ('function ' . $name . ' () { global $' . $name . '_object; return $' . $name . '_object->' . $method . '(); }');
        return $name;
    }
    class A
    {
        function b () { echo "A::b()\n"; }
    };
 
    $a = new A;
    $c = makeclosure ($a, "b");
    $c ();
    ?>

(I leave handling of function parameters as an exercise to the reader; it's fairly straightforward, but detracts from the readability of the example)

Re:Have you tried coding anything hard?

[zootm]

PHP? No. What about Java? It's more than capable of doing this as well as a native solution.

Re:Have you tried coding anything hard?

[dodobh]

pl/perl. Push your Perl code into Pg.

Re:Have you tried coding anything hard?

[jellomizer]

Well spare us with the big numbers. This is what clients do to try to scare off potential venders. Because these numbers don't say anything. I am probably assuming you more then a P4 Linux Server with MySQL and Apache on one box. So the question is how much time do you loose coding in native code vs. PHP and compare it with how fast you native code is compared to PHP. Now we figure out the cost of your time, Including benefits, and for maintenance of your code. Now compare that with getting an other computer to share the load and admin time to set it up. Now if it simple application (and yes a simple application can give the load that you explained get over yourself) It may be worth it. But if it get big and takes a lot of code changes and real long to develop and the specs will change every week then you are normally better off with an interpreted language where you can code you changes quick and deploy them easily and any performance hit you can normally push to more Boxen.

Re:Have you tried coding anything hard?

[FireFury03]

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.

Whilest the query rate has a bearing on the design of the front-end system, the total number of rows in the database shouldn't since that should be handled by a high performance database backend and the frontend shouldn't know or care. You then have to weigh up which is more important: the language you're using vs. the amount of hardware. Web servers can often be clustered so you can just throw hardware at the problem if writing it in PHP is deemed necessary.

The problem is more important for workstation apps though, where you really don't have the option of throwing more hardware at the problem.

However, the idea of using java for applications (not applets) is crazy IMHO: You already know what architecture the app is going to run on when you package it (practically all java applications seem to have native installers), so you may as well just use a portable glue layer and compile for each architecture natively. The whole thing becomes even more crazy when you see FOSS applications in java, since there's no reason to avoid distributing the source which could be compiled natively anyway.

Re:Have you tried coding anything hard?

[rufty_tufty]

I disagree (but then this is a philosphy thing).

Regardless of if you are a performance critical app or not, the philosophy of code in as high a level language as possible and then profile your code/redesign from scratch many time learning what you did wrong is still valid. Anything that makes code easier to maintain is _always_ a good thing. And in most embedded environments, the code simply has to go fast enough - if the performance metric is reached, you can stop worrying! i.e. if your java prototype that made full use of objects, structures and other gubbins of a high level language , and it happened to run fast enough, who cares that it is sub-optimal?

Now I'd certainly agree that in most embedded environemtns any garbage collection is unviable because they are not suited to a real time system. I'd also conceed that if you know in advance 90% of your code is going to be performace critical then it might be better to just keep everything in a low level language like C.
I'd similarly conceed that in some embedded environments the processor is the main cost (in $ or in power) so minimum cpu cycles is worth the development time.

As long as you know you're making that tradeoff...

Re:Have you tried coding anything hard?

[rufty_tufty]

I'd also add the argument, that in a higher level language, the code to mundane functionc is likley to be quite optimal.
e.g. I'd bet that the standard C compiler makes a more optimal for loop than I would unless I really thought about it.
i.e. in a high level language, the compiler is probably using optimising tricks at every single iunstruction, in a low level language I'm only hand optimising the bits that I believe will matter.

i.e. 10% of my code in a low level language may be at the absolute optimum, but the other 90% of the code i didn't think mattered is vastly sub-optimal.

With this in mind it bothers me that cross language support and profiling tools aren't better.

i.e. why isn't there a decent high level language* like python that lets me embed C, when the profiling tells me i need it, or assembler** when I really need it.

*C++ or system C don't count! :-p
**Yes know i can embed assembler in C, but not C (or similar low level language) in most other languages.

Re:Have you tried coding anything hard?

[GoatMonkey2112]

That's what server farms are for.

It all depends on where you want to spend your money, developers or hardware.

Re:Have you tried coding anything hard?

[m874t232]

Given your comment, I know one thing: I don't want you anywhere near the code. If you knew what you were doing, you'd realize that you already have an interpreted language in there: SQL. And that's likely your performance limiting factor. Whether you write the rest of the application in C/C++, Java, or PHP is immaterial from a performance point of view.

And if it's about coding something "hard", then C/C++ and Java are clearly the wrong choices because they result in big, bloated, complicated systems; you need something much more high level.

Re:Have you tried coding anything hard?

[gbjbaanb]

We throw shitloads of big boxes at it

so the only good part of your architecture is the ability to scale... makes sense, I've never seen a single enterprise Java app that didn't *have* to scale horizontally. :-)

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?

[Zod000]

If you don't mind me asking, what python ETL software are you using? Is this something available commercially, through open source, or something of your own design. I have been looking for software to replace the ease of SQL Server DTS for quite a while and using DB2 (if necessary) would not be a problem.

Re:Have you tried coding anything hard?

[ipmcc]

Since insert traffic far outstrips querying traffic, I'd have to make an educated guess that he's talking about some audit/logging application. Either that or something with heavy read caching.

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:Have you tried coding anything hard?

[bogado]

The fact that a app has to endure 50,000 inserts per second does not mean that it does have to do it every second. It probably mean that in some peak moment it does reach this level, but most of the time it have a much lighter access ratio.

Re:Have you tried coding anything hard?

[kmortelite]

What about desktop applications? I use Lotus Notes, Firefox, and Eclipse, all Java based, and let me tell you, it can be PAINFULLY slow if I have all three apps running at once.

OTOH, I can run many instances of Word/Excel/Virtually anything linked and not notice a big difference.

Based on my experiences, I want to shy away from interpreted code for desktop applications.

Re:Have you tried coding anything hard?

[ArikTheRed]

The thing is, databases aren't fast because they tend to be written in native languages. Databases are fast because they optimize queries and index data to ultimately reduce disk access, which are orders of magnitude slower than the processing itself. HSQLDB is a pretty damn good database, and it's 100% Java.

Re:Have you tried coding anything hard?

[xmartinj]

No. I make great money coding things that aren't hard, using the right tool for the job, producing elegant solutions that improve productivity for people who don't care how it's coded.

Re:Have you tried coding anything hard?

[Citizen of Earth]

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

There's no job that four-million lines of BASIC can't handle!

Re:Have you tried coding anything hard?

[ben there...]

Firefox is written in C, with interpreted XUL, javascript, etc. layered on top for the GUI.

Notes is not Java either, I believe. Wasn't Notes around long before Java was even used for any large software packages like that, without any significant rewrites other than Domino? I could be wrong, but I don't believe its a Java app. Probably C/C++ as well.

So the only one written in Java is Eclipse.

That said, I hate most Java desktop apps, and especially Java embedded for the web. It has crashed Firefox way too often for me.

Re:Have you tried coding anything hard?

[minion]

He just said that it worked for him, who are you to tell him it doesn't?
 
I believe this topic was in reference to the story about native coding vs. interpreted languages. Which asked specifically, " Is it time to jump in the boat of interpreted/JIT compiled languages?"
 
So, was I telling HIM it didn't work? No. Was I voicing my opinion about interpreted languages for the benefit of the slashdot community? Yes... Why does every damn poster on slashdot always have to jump down someone else's throat, and think that every post is a personal attack?
 
So, in the spirit of the original topic, I stand by my opinion (happy now, I clearly said its an opinion!), that those languages are not ready for the volume enterprise computing requires.

Re:Have you tried coding anything hard?

[ealar dlanvuli]

I still see this post every time this topic comes up. You do realize you're doing embedded code, a very small market and completely unrelated to normal code?

Also, if you were starting this project today, with no legacy code, and you did not investigate your real time java solutions, you would be doing your company a disservice.

Re:Have you tried coding anything hard?

[minion]

I keep hearing people putting down PHP. It's not the only interpreted language. I also hear of Python being the best thing in the toolbox.

Seems to me that if you can put your personal bias aside then just about everything can be run with some form of an interpreted language playing a core component of the overall application. After all, isn't HTML/Javascript considered interpreted?
 
Seems a recently posted slashdot story is in order for this: http://developers.slashdot.org/article.pl?sid=06/0 6/06/0451239
Allow me to quote from the article: "BASIC has become the leading cause of brain-damage in proto-hackers...As it is, it ruins thousands of potential wizards a year."
 
When I develop content for my personal web page, I usually turn to PHP, as its quick, easy to code in, and I can build fairly complete web sites easily. When I need system administration stuff done, I write bash scripts to accomplish the task.
 
There is no personal bias here agaist PHP or interpreted languages - I just strongly feel that it doesn't belong in the enterprise, especially when you're talking healthcare, and people's lives are on the line. And I do agree with the other article that interpreted languages hold back decent programmers from becoming great programmers.
 
  But I can get feedback on my applications performance as I write it making it less error prone and easier (IMHO) to debug.
 
I feel that gdb and a core file are a great way to debug, so once again, a difference of opinion.
 
M.

Re:Have you tried coding anything hard?

[Doctor Faustus]

so the only good part of your architecture is the ability to scale... makes sense, I've never seen a single enterprise Java app that didn't *have* to scale horizontally.
If that covers it, though, why complain?

Re:Have you tried coding anything hard?

[jesuscyborg]

You can't always throw more hardware at the problem. If your PHP app bloats to the point where it needs to parse thousands of lines of code and perform all sorts of initialization every time request is made, having many CPUs won't make the pages not take half a second load. Clustering usually doesn't improve response time, only the number of responses per minute your setup can handle.

Re:Have you tried coding anything hard?

[kmortelite]

I didn't know that about Firefox.
When I start up Lotus Notes, the splash screen has Java all over it, and occasionally I'll get the Java Console popping up, informing me of something going wrong with Notes. I'm using version 6.5.2.

Also, if I look in the task manager, "javaw.exe" or "java.exe" starts up every time I start Eclipse, Firefox, Notes, and even Matlab.

Re:Have you tried coding anything hard?

[ceoyoyo]

It's using the native GUI toolkit, but the language you're coding in isn't native.

I see what you mean though. Especially in that case there's a little more going on than just GUI. How about not ENTIRELY native? It seems to be a really nice approach though. Make wrapping really easy, wrap most or all of the system toolkits and then you're completely free to code in an interpreted language. Not so great for cross platform development, but to me interpreted languages are more about the ease and speed of development anyway.

Re:Have you tried coding anything hard?

[Dare nMc]

> You do realize you're doing embedded code, a very small market and completely unrelated to normal code?

Do you realize that every piece of high level code written relies on dozens of embedded controllers to accomplish anything. so saying it is unrelated shows the ignorance of your typical high level programmer.

IE they have no idea how many GPU's/CPU's/PLA's in drives/disk controllers/Graphics cards/montiors/usb devices, etc that they are totally reliant on working for that piece of code to work.
You are correct that the majority of coders don't need to change anything at that level, and with the exception of not being a well rounded programer, don't profit from knowing what is working.

As the grandparent mentions power savings, that cuts across the board. The more efficient the code, the lower the CPU load, the lower the CPU requirements, the less environmental impact... It may not seam like much to your high level programer that their database sort takes 5 seconds more than it could, and runs 100* a day, and thus loads the server more, so more servers are needed with the next app... That is not lost on the google GUI programers of the world, who realize their code will not get run a 100 times a day, or a hour, or a second. but over 10000 times a second. If you aspire to have your code help everyone on the internet repeatedly, then take some pride and learn what really happens behind the scenes. If your happy to make 6 figures for many years until your job is outsourced to a cheaper code monkey, and will cry about it endlessly on BBS's that they setup for you, then don't sweat the small details.

Re:Have you tried coding anything hard?

[Fulcrum of Evil]

I'm intimately familiar with this application. When I say that only a few dozen queries a day are scanning a hundred million rows in a given day, it is the case.

And you also say that there are upwards of a million queries per day. In my book, 30 out of a million is uncommon to say the least.

First off, cycles? really? what an simplistic way to think about such a system

And cycles are a convenient shorthand for all of that. It's not like you're likely to be writing a network heavy application the way you've described things.

And cost? You're implying that the 90% of the cost is spent on hardware apparently because python is wasting cpu cycles.

No, I'm implying that DB2 is where all the heavy lifting is, so that's where you spent your hardware budget. The php servers are cheap because they don't do much.

But on this "hard" project those technologies far outperformed what native code would have achieved.

I would wager that the DB design had the most to do with your success. Fitting the schema to the usage patterns reduces the load and potential resource contention.

Re:Have you tried coding anything hard?

[jsebrech]

It's more cost-effective and reliable to throw a lot of cheap boxes with redundancy at a problem than one large machine. That's why google is not some gigantic server somewhere in the continental US, but tens of thousands of cheap PC's spread out throughout the world.

Re:Have you tried coding anything hard?

[Dem_Gnomes]

Oh please. I get that much in Viagra ad spam every day. Respect the Yahoo!

Re:Have you tried coding anything hard?

[gbjbaanb]

Why does no-one get the point? I even put a smiley in just make sure.

I was criticising java (J2EE at least) as a platform that requires multiple boxes scaled out horizontally. The most cost-effective and reliable way to scale up a system is not to need to do this in the first place, but you never get that with J2EE systems.

The architectural technique is good nevertheless, but remember that the more boxes you put in, the more maintenance will need to be managed and that starts to cost much more past 3 or so boxes. Think of the Hard drive MTBF as one reason why it starts to get expensive.

Re:Have you tried coding anything hard?

[Alomex]

you are doing 743 queries per second, great-grand parent post claimed 50,000 queries per second. That is two order of magnitudes larger. Google itself doesn't see that transaction rate.

Re:Have you tried coding anything hard?

[Memnos]

No, it's actually a list of all males who buy "feminine products" at noted stores. We'll track and remind you of such purchases at the most inopportune times, unless you pay my Russian friends a "convenience fee :)

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

[Ant P.]

Yeah, someone built an entire self-hosting operating system around a Lisp interpreter. The name escapes me at the moment...

Re:-1 flamebait

[Karma Farmer]

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

No, because people who know Lisp also understand that "native code", "interpreted", "interactive", "virtual machine", and "low level" all share a "loose" relationship, but are not interchangeable ideas.

Re:-1 flamebait

[Karma Farmer]

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

Emacs.

Re:-1 flamebait

[procrastitron]

Well, this is partly a self-serving post because one of the systems is my own, but there are at least three separate lisp operating systems available for x86 architectures. However, none of these systems has grown past the proof-of-concept stage (yet).

The first such system is Movitz (http://common-lisp.net/project/movitz/). This one is based on common lisp and even has an emacs clone running on it (http://www.emmett.ca/~sabetts/).

The second is DrScheme (http://www.drscheme.org/) which has been ported to run on bare hardware.

Finally, there is my project (http://losak.sf.net) which is aimed towards keeping everything as simple as possible, but is also the least functional of the three options.

On a side note, one of the biggest lessons I have learned from working on the system is that interpreting code is far too slow for operating systems. A kernel really needs to be compiled. Of course, this does not have any affect on the language used. Any language can either be interpreted or compiled.

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!

Re:-1 flamebait

[filesiteguy]

Flamebait?

I demand a recount! I - in my executive power as me - hereby declare the above post to be +5 funny. Obviously the /. moderators need another Jolt Cola before they start modding these things down.

Lisp...heh!

Re:-1 flamebait

[Karma Farmer]

Heh, I love it when I make write six painfully, obviously, and blatantly false statements in a row (and even go to the trouble of numbering them!) and some kiddie gets all happy when he discovers I'm wrong.

Re:-1 flamebait

[feijai]

Heh, I love it when I make write six painfully, obviously, and blatantly false statements in a row (and even go to the trouble of numbering them!) and some kiddie gets all happy when he discovers I'm wrong.

Statement #1 was true. Oh, wait, are you including your statement count above as one of the false statements? Self-reference at its best.

Re:-1 flamebait

[sdfad1]

Whack!! Language implementation and language design are two separate
things.

CL-USER> (lisp-implementation-type)
"SBCL"
CL-USER> (lisp-implementation-version)
"0.9.9"
CL-USER> (defun test (x y)
       (declare (type fixnum x y)
            (optimize (speed 3) (debug 0) (safety 0)))
       (the fixnum (+ x y)))
STYLE-WARNING: redefining TEST in DEFUN
TEST
CL-USER: (disassemble #'test)

---Slightly modified for readability----------
ADD EDX, EDI               ; no-arg-parsing entry point
MOV ECX, [EBP-8]
MOV EAX, [EBP-4]
ADD ECX, 2
MOV ESP, EBP
MOV EBP, EAX
JMP ECX
NOP
BREAK 10                   ; error trap
BYTE #X02
BYTE #X18                  ; INVALID-ARG-COUNT-ERROR
BYTE #XCD                  ; EBX

NIL
CL-USER>

That was all typed into the REPL, ie interactively. The function was
incrementally compiled, so read time, compile time, and runtime, while
distinct, are all available at the same time. EDX and EDI contains the
first and second arguments to a function, while EAX contains the
funobj, and ECX the argument count.

Compare the output from gcc -O3 -s

int test(int x, int y){
  return x + y;
}

becomes:

test:
    pushl    %ebp
    movl    %esp, %ebp
    movl    12(%ebp), %eax
    addl    8(%ebp), %eax
    popl    %ebp
    ret

At this stage, which output is better becomes a question of whose
compiler is better, and has nothing to do with the fundamental design
of a language.

Other implementations of common lisp might do things differently, for
example, clisp compiles to bytecodes that runs on a virtual machine.

At this moment, Karma Farmer was enlightened. (I hope).

PS: Lameness filter sucks.

Re:-1 flamebait

[RoadWarriorX]

1. Lisp is interactive.

This is about the only statement you got 100% right. Lisp is interactive and it is a plus, IMO. It's nice that a drops back to a REPL when condition (execptions in Java/C++) is signaled. I can query the environment state, inspect variables, or provide restarts. But, it does not have to be.

2. Therefore, Lisp is interpreted.

Not necessarily. Most Common Lisp implementations can either interpret their code or have their code compiled.

3. Therefore, Lisp uses non-native code.

Most Common Lisp implementations can be compiled into native fast-loading files (FAS) or byte code. Some implementation can even create stand-alone executables.

4. Therefore, Lisp runs in a virtual machine.

Not really. Common Lisp run in an environment and executes either native code or byte code, depending on the implementation. CLISP is the only major Common Lisp implementation that I know of that does not compile to native code. Hey, it was good enough for Paul Graham when developing Viaweb. I was even shocked by that.

5. Therefore, Lisp is incapable of direct memory addressing or interrupt handling.

Not sure. There are some people creating Lisp operating system, it might be possible, right?

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

Hmmm. I guess creating a Lisp machine in hardware is not enough, huh?

Re:-1 flamebait

[masklinn]

Loose relationship as in "interpreted code can also be compiled n/p"?

Re:-1 flamebait

[Karma Farmer]

No, Lisp is not interactive.

Nearly all implementations include a REPL, but it's not a requirement.

Re:-1 flamebait

[Karma Farmer]

Statement #1 was true.

Lisp isn't interactive, because the REPL isn't required. However, I agree that any discussion of Lisp is incomplete without a recursive error.

Re:-1 flamebait

[Karma Farmer]

At this moment, Karma Farmer was enlightened. (I hope).

Yes, I am. The introduction to Steel Bank Common Lisp is greatly appreciated.

Re:-1 flamebait

[Karma Farmer]

Finally, there is my project (http://losak.sf.net) which is aimed towards keeping everything as simple as possible, but is also the least functional of the three options.

This is sweet. Thanks for the link.

BTW... I apologize for the earlier snark-post. It's difficult to take anything seriously on Slashdot, and this article was worse than most.

Re:-1 flamebait

[blackest_k]

interesting reference i liked this section

"Around this time Symbolics (Notfsker's company) began operations- it had been hindered by Noftsker's promise to give Greenblatt a year's head start, and by severe delays in procuring venture capital. Symbolics still had the major advantage that while 3 or 4 of the AI Lab hackers had gone to work for Greenblatt, a solid 14 other hackers had signed onto Symbolics, the lion's share of the AI Lab's hackers. There would be two exceptions, two AI Lab people who did not get hired by either: Richard Stallman, and Marvin Minsky."

where have i heard these names before :)

Re:-1 flamebait

[RoadWarriorX]

Hmmm. My definition of interactive may be different from yours. Sorry for the confusion, though. But I think I agree with this statement.

Re:-1 flamebait

[feijai]

I don't believe I've ever seen a Lisp system in my life without an REPL. It's a defining feature of the language.

Re:-1 flamebait

[heson]

Yeah, I love it, its my favourite OS, but the editor is quirky, couldnt they have put in a better one.

Re:-1 flamebait

[Karma Farmer]

I don't believe I've ever seen a Lisp system in my life without an REPL. It's a defining feature of the language.

I'll grant that the REPL is a defining feature of the Lisp development environment. Only simplest environments don't provide one.

Re:-1 flamebait

[Karma Farmer]

I'm sure it's possible to create languages where compiling interpreted code is NP.

But those languages probably suck.

Re:-1 flamebait

[masklinn]

I'm sure it's possible to create languages where compiling interpreted code is NP.

Aah so you don't know Lisp?

Re:-1 flamebait

[Karma Farmer]

Is compiling Common Lisp NP? If it is, I'm guessing it must be a consequence of the macro system?

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

[blincoln]

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.

Um, like using thread pooling? 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.

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

[Abcd1234]

Actually, researchers have been working on auto-parallelization for quite a long time. The problem is that it's *exceedingly* hard to do, and in fact may very well be an NP-class problem.

Re:Its inevitable

[lbrandy]

Before you say that JITs cannot hack this, remember that they use exactly the same technology as your 'standard' compilers.

Except they do it online, not offline. Neglecting that difference is obviously unwise.

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.

That's exactly my point.

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

[Brandybuck]

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.

You can do that now... if only there were standards for the CPU, OS and application. You won't be able to do it in the future without these standards. Don't tell me about Java, because I've seen enough IE-only Java applets and Windows-only Java applications to know better.

Re:Its inevitable

[samkass]

This is a good argument *for* JIT compiling, because the JIT has information available to it at runtime that a static compiler lacks. Such as how many times a loop tends to be run, or a piece of code tends to get executed, or the miss rate of caches. Theoretically, a good JIT-compiled piece of code should be able to optimize circles around C++. In practice, you don't want to spend TOO much time optimizing most code, because it tends not to get run a zillion times. That's why Java's so great on the server and sometimes lacking on the client, IMHO.

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

[try_anything]

Except they do it online, not offline. Neglecting that difference is obviously unwise.

Yes, it is. Optimizing code using data from real use is fairly potent stuff, and it's rarely done for languages compiled "offline," despite people knowing about the potential for a long time. JIT compilers have made it available to the masses thanks precisely to the online nature of the compilation.

Re:Its inevitable

[rhesuspieces00]

Someday, you will be able to use any OS on any CPU and any Application on any OS.

1997 called. They want their wishful thinking back.

Re:Its inevitable

[morcego]

That is a very valid point.
When you think you Java, you have several different VM implementation. Just like you have several different OS.
So, instead of having to wonder if the program will run on Windows, Linux etc, I'll have to wonder which VM it will run under.
I really don't see any gain there.

Re:Its inevitable

[Jeremi]

In practice, you don't want to spend TOO much time optimizing most code, because it tends not to get run a zillion times.

True, but what if you store the results of your optimizations back to disk (say, as attributes of the executable file) so that they can be re-used the next time the executable is run? Then instead of having to re-optimize for the same code every time the program is launched, you only have to optimize the first time... after that, you'll get better-than-compiled performance every time, with no slowdowns due to optimization.

Re:Its inevitable

[EvanED]

In full generality, it's undecidable.

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.

Re:Its inevitable

[digitalove]

Compilers cannot make up for multi-core CPU fiasco IMHO. A multicore CPU exposes an abstraction of separate processors which the OS (generally) uses to do SMP. Once at this level, besides doing openmp like vectorization using threads the compiler actually doesn't do anything else. Compilers will OTOH play a significant role for VLIW architectures like the Itanium.

JIT is another form of compilation. Its however "fast" compilation with an eye towards optimization and targets only performance centric areas in the running program. The biggest advantage of a JIT against a compiler is that it uses run time profile information to optimize the code. Something which gprof and gcc would do but I am sure nobody bothers. A JIT based compilation technique is bound to succeed in the future for the following reasons:

1) Multicores can do compilation and execution of the program on separate cores.
2) For most desktop application work, there is a good room for optimization based on profile data. Oh course this is only my hunch :)

Another important factor is garbage collection. The primarily used compiled languages today (C/C++) don't have garbage collection (talking about non-conservative gc). Most recent languages have seen the benefits of garbage collection and have adopted it besides also adopting JIT. This alone can lead JIT into the mainstream.

Re:Its inevitable

[ardor]

Well, then show me how to insert a parallel architecture in your typical 3D game. Multithreading can work only in very high levels, by separating stuff into a sound thread, networking thread, rendering thread, physics thread, and a main one (usually containing the gameplay). But you cannot insert multithreading into the graphics subsystem; its pointless, except for expensive precalculations (like relief map voxelizations or some PRT stuff). There is just no point in using multithreading for scenegraphs, the synchronization overhead kills any speed gain. And, the aforementioned separation certainly helps in reducing latency (critically important for networking), and that is the REAL benefit in most cases.

Re:Its inevitable

[jcr]

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

Cray did a pretty good job of it. Google for the papers on their vectorizing FORTRAN.

-jcr

Re:Its inevitable

[Billly Gates]

One of the benefits of java as it can scale nicely and it has nice multithreading libraries.

I am just a begineer with java programming but I am impressed that the top web servers run java servlets that seem to scale quite nicely. Something that cgi and lamp can't do that well.

I assumed the JVM can run on several processors so the problem wouldn't be hard on an smp system. I could be wrong since I am not a software engineer or experienced yet.

I think AMD is approaching the opposite angle by having several processors act as one in a giant core. I know they plan to introduce this in a later chip. That way the multithreading is done in hardware rather than in software on the OS. I think that is a great idea.

Re:Its inevitable

[TeknoHog]

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

As others have pointed out already, interpreted languages may have an advantage as they can scale up on runtime. A somewhat related point comes from my experience with Fortran 90 (and higher): its builtin matrix data types and operations are inherently parallel, and the compiler can make use of this for SIMD and multiprocessor machines.

In other words, the programmer often knows what can be parallelized. But that information is sometimes lost, for example if you're operating on vectors (each component in parallel) and writing it as a sequential loop. To retain the information you need a higher level language -- in fact, the higher level, the more information you can pass while staying cross-platform. Lower level means you're focusing closer to a specific architecture, so it won't be as efficient when compiled to other archs.

Re:Its inevitable

[epine]

This thread is hardly worth the bother, but I'll stop to make one point before whisking off to greener pastures.

In a template-metaprogramming language such as modern-idiom C++, what the JIT has to work with is the same as an intermediate representation of the compilation process. Pull your head out of your Javole.

Byte-code != source code - comments;

Re:Its inevitable

[David Greene]

What parallelism do Cray compilers handle automatically?

Vectorization, multithreading and multistreaming over multiple processor cores (X1 and X1E). I was mostly thinking of multithreading in my response. The compiler generates code for hundreds of threads on the MTA machine.

Re:Its inevitable

[SpinyNorman]

Well, then show me how to insert a parallel architecture in your typical 3D game

Base it on OpenGL or Direct3D, and let the massive parallism that's inherent to the task of 3D rendering be handled in parallel by the multiple shaders/etc of your graphics card.

Re:Its inevitable

[zootm]

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.

What about JITted languages? Compiler advances apply equally well to them, and they can often apply the changes without even having to redistribute the executable — the JIT engine simply gets more efficient, learns how to use these systems, and suddenly the bytecode of your old app is optimised on-load to use them too.

That does apply to purely-interpreted languages, though, but how many of them are there really these days?

Re:Its inevitable

[ameline]

so how long will it take to jit 25 million lines of code?

Re:Its inevitable

[zootm]

I don't see how non-native languages can't just change paradigm as well. This is not a native vs. interpreted/etc. issue at all.

Re:Its inevitable

[ardor]

Well, I did not mean the GPU parallelization. We are talking about Multi-Core CPUs, right? How am I supposed to write a 3D game taking advantage of multithreading? I already mentioned some separations, but they all help with latency, not speed (well, in multicores speed is increased too, but this is just a side-effect in that case).

Re:Its inevitable

[rufty_tufty]

"But you cannot insert multithreading into the graphics subsystem"
Are you serious? Are we even talking about the same thing?
You know the whole point of a GPU is to parallise everything right?
You know each pixel can be rendered in parallel?
You know each sprite can usually be drawn to polygons in parallel?
You know most of the physical simulation can be done in parallel?
You know that with the correct architecture all of the above can happen in parralel to each other?

Even the sound thread can be parralised. You've an input queue of sound events that need playing, each sound effect can be a separate thread within that.
Networking thread? Well I need to communicate many things, let me have one thread talking to each other player perhaps, and then within that a thread to do each of the things such as communicating my character's current position/action, communicating other character's position, triggering game events, handling player-play communication etc.

Now I agree this requires communication between threads which current architectues/languages don't do well. But that doesn't mean that the problem isn;t parallel, merely our expression and solution of the problem that lacks parallelism.

Re:Its inevitable

[ardor]

I am NOT talking about the GPU. I am aware of parallelization there. I am talking about parallelization in scene management, which is pointless there (no net gain).
As for physics, networking and sound.... i ALREADY mentioned them. Did you even *read* my posting?

Re:Its inevitable

[Dracolytch]

Um... It's already been done, FYI, and not recently, either.

Here's an easy example: You write a for loop that iterates through an array, performing some action on each item in the array. These actions are independant of one another. Let's say, making a string uppercase. There was a supercomputer (1 master control CPU with 1024 parallel PUs, if I recall correctly) that had a special compiler command to parallelize such an operation. It would take the for loop, and assign one iteration to each processing unit transparently. That way, if the string was less than 1024 bytes long, it would all get capitalized at the same time.

I'd have to go back to my grad school notes to find out what system it was.

~D

Re:Its inevitable

[rufty_tufty]

Did you read mine?
Scene management is one thing that is hard to parralise, fine. but i quote "Well, then show me how to insert a parallel architecture in your typical 3D game"
Which I did. each of the items you listed as threads i suggested how thay could be further parallelised - that was why I mentioned them. So I assert that your statement of "Multithreading can work only in very high levels" is false as I have suggested how it could be further parrallelised.

I agree there are some segments that cannot be split up in themselves, but there is no reason why you cannot be having the serial scene management thread running while all the other parallel things are running. As my understanding of modern 3d games goes, scene management is a relatively small part of the CPU time.
Even if there are 100 things that cannot themselves be parralised within their own algorithm, they can often be run in parrallel with the correct architecture.

Re:Its inevitable

[lbrandy]

Multithreading can work only in very high levels, by separating stuff into a sound thread, networking thread, rendering thread, physics thread, and a main one (usually containing the gameplay)

You do realize that rendering is a stream-style computation that we've already broken out into a parallel architecture, yes? Physics is embarassingly parallel... also, and it's headed in that direction. AI is embarassingly parallel (19 actors, 19 A* searches at once). How about a few processor for adapative AI? Training the neural net or bayesian classifier? I know very little about games, but I do know afair bit about AI. I could fill all the processors with complex AI and AI-training myself with enough time. Game developers would likely be more clever.

Re:Its inevitable

[m874t232]

JITs amortize their overhead over other operations, so that, whatever you do, the JIT-related overhead is small. But that's just the amortized cost; you have to weigh against that the optimizations that JITs perform that no batch compiler can perform, and JITs often come out far ahead in that comparison.

Re:Its inevitable

[ardor]

Well, one thread per sound is insane, NO ONE will do that. It is common to have ONE thread for the ENTIRE soundsystem, and this thread handles optional sw mixing, 3D positional updates etc. You do not WANT and NEED one thread per sound for this.
Networking: depends on the game. For a server, one thread per player is reasonable, for a client it is not.
As for scene management etc., it is not only very hard, it is often absolutely pointless. The data structures are too dependent of each other. The amount of mutexes guarantee a net benefit of 0%.
As for high-level: well, low-level would be one thread walking the scenegraph for renderable nodes, while another thread serializes the thing to a disk, a networking thread adds nodes etc. It is absolutely crazy to think that this would actually HELP performance. Since nowadays everyone seems to be keen on using multithreading everywhere, I wouldn't be surprised to see such atrocities in some games soon.

Re:Its inevitable

[rufty_tufty]

Seems like we're hitting some problems on assumptions here. You seem to be assuming I'm talking about a tradition von Neumon like CPU architecture. I'm not. I'm assuming that context switching and communication can be free. Which they can, depending on your solution architecture. Modern OSes though don't have free context switiching and communication though, so you're right, choosing the correct degree of serialisation vs parallel is a difficult decision.

I'm saying that conceptually the problem could be as parallel as you want it to be, right down to one thread per sfx. one per client etc.
With _current_ _common_ cpu architectures i agree this would be insane.
If however we are talking about possible future architectures, or past architectres such as the inmos transputer, (occam etc) then I believe a finer grained parallism such as i propose is much more appropriate. I propose this partly because in my last job I was designing sound processing hardware that did process each stream in parrallel because that was the simplest thing to do in hardware. So it is possible, and it is sometimes desirable if it is appropriate to your solution architecture.

i.e. I;m trying to say that the problem is inherently parrallel if you want it to be. If your architecture forces you to serialise stuff, then that's fine too, but just because on current architectures you think about a problem as being particularly serial, doesn't mean that it always and forever has to be.
for example, if you knew that context switches and communication channels did not have a performance penalty (no mutexes) then would your design decisions be the same?

Re:Its inevitable

[ajs]

There will always be a need for fairly low-level code. The definition of low-level will slide, but it's sliding with respect to mainstream code at an order of magnitude lower rate. For example, C++ is currently considered "low-level" in most of the industry, and having seen some very modern, high-performance C++ in the last few years, I can honestly say that interpreted languages pose no threat whatsoever in those application domains that actually need performance.

The thing is that most applications need "responsiveness" not "performance". For example, when I click on a button on a GUI, I need it to respond fast enough that it doesn't "feel" slow. If it doesn't my customers will not use the application. But that's just spot-performance, and can easily be wrapped into a low-level library that high-level code calls (as modern toolkits do).

However, I might have an application that takes in a live stream of data and do some serious thinking about it 24/7. That requires a certain level of performance (relative to the flow rate of the data, its complexity and the complexity of the "thinking" that needs to be done over it). This is a likely candidate for a low-level application.

Operating systems, real-time systems for high-data rate processing, many embedded systems, high-performance elements of video games, and many other elements of your average end-user's experience will continue to be written in low-level code. Many casual programmers will continue to write code in high-level languages, and some end-user applications are already written in high-level languages such as Perl, Python, C#, Java, Lisp, Scheme, Haskell, etc.

Re:Its inevitable

[ealar dlanvuli]

None of the advantages you listed were because Java is run in a virtual machine. Compile time evaluation of almost everything is possible, you just can't use a language that lets you make a pointer to the bit that toggles your keyboard lights with the exact same syntax as you do elementary string operations..

Re:Its inevitable

[poot_rootbeer]

Before you say that JITs cannot hack this, remember that they use exactly the same technology as your 'standard' compilers.

Yes, but JIT compilers have the added requirement that whatever optimization they do, they have to get it done QUICKLY. A classical compiler can take hours to determine optimal output (if the user wishes), analyzing the code flow of the entire application, reordering instructions and unrolling loops until the cows come home. A JIT needs to start having machine code ready to execute within a few moments of being invoked.

And while JITs have the added benefit of being able to analyze actual behavior of the program, rather than just predicting expected behavior, having the analyzer constantly running also takes away resources that could otherwise be used by the program. It's a tradeoff.

Re:Its inevitable

[P3NIS_CLEAVER]

Vectorization is more a feature of the fortran language, although you could argue that this just facilitates things for the compiler.

Re:Its inevitable

[evought]

Well, one of the advantages of JIT compilation is compile-on-demand. If only 10.2 million lines of code are used in the course of a use of the application (say, the help system and macro system and template system and make-me-an-orange-julius subsystem is never loaded), then that is all that has to be compiled. If the program runs for an hour, it has that long to compile and optimize the code. If something is demanded before it is ready, the code can be interpreted the first time. The JIT has up-to-the-moment statistics on what is being used most and what is costing the most performance to concentrate optimization where it is needed.

Now, one advantage of compiling off-line is that you can add additional power (parallel compilation) to make your build go faster and spend more computing power on optimizations. However, much of that power is wasted on routines that real users will hardly run--- unless you have the time/money to get a panel of users to generate real and detailed profile information. I have seen this actually done once in my entire carreer. Generally, optimization is "best guess", especially when you do not have a large enough lab to get the profiling information on every sub-architecture your system will need to run on (Windows-single, Windows-dual, Windows-core-duo, Windows-quad, Linux-single, Linux-dual, Linux-core-duo, etc, etc.

As a quick reply to the Gentoo user, I would almost consider Gentoo a hybrid of online and offline compiling, where it is compiled specially for the user's own machine. Shipping Java byte-code (or whatever) and compiling it on platform is not much different.

That all being said, I think that the interpreted or byte compiled langauges will probably be designed better for this role in the future. Java byte code is not all that well designed for use as an intermediate compilation step. There are a lot of ways things can be improved to better convey the program intent and increase opportunites for optimization.

Re:Its inevitable

[Sloppy]

As we head towards multi-core and massively-multi-core, you are telling me that things are going to get better for interprative languages?

Sort of, yes. Although the issue isn't really compiled-vs-interpreted, but overall level of abstraction. Working at a higher level will tend to increase opportunities to take advantage of parallelism.

It is so trivial right now for me to write apps in python and use the threading, Queue, and Event classes to make massively-parallel apps that don't have any sync bugs, race conditions, etc. Of course, the current implementation of CPython has some performance issues under-the-hood when it comes multithreading, but that's just an ephemeral detail.

You can do that same kind of stuff in lower-level languages, but I see the day coming when, using a high-level language, the use of this stuff is at the language level rather than just library calls. Imagine a "for loop" in a language that tells the underlying machine, "every iteration of this can be done in parallel" and then the underlying guts just makes it happen, without the programmer having to even think (beyond using the correct language structure) about the parallelism. When it gets that easy for people, everyone is going to use it.

Re:Its inevitable

[David Greene]

Are you thinking of array syntax? Cray compilers go way beyond vectorizing simple things like that. Cray compilers vectorize C just fine (well, assuming restricted pointers and such). There's a lot, lot, lot more to vectorization (and parallelization in general) than SSE-type stuff.

Re:Its inevitable

[Sloppy]

Well, then show me how to insert a parallel architecture in your typical 3D game.

Throw out the fancy 3D GPU, and raytrace the whole scene, every frame. Now every pixel is a thread. ;-)

Re:Its inevitable

[mac1235]

In a template-metaprogramming language such as modern-idiom C++, what the JIT has to work with is the same as an intermediate representation of the compilation process. Why do you say that? The Java *implementation* of templates suffers from this loss of metadata. The .net bytecode does not.

Re:Its inevitable

[greywire]

You can do that now... if only there were standards for the CPU, OS and application. You won't be able to do it in the future without these standards. Don't tell me about Java, because I've seen enough IE-only Java applets and Windows-only Java applications to know better.

To some extent. You could run a virtualization system (vmware) and get any OS running, even at the same time. And using interpreted code (or bytecode, or some other IM based code like .net) run any software on any of those os's. We're not at the point of running the OS's on any CPU (efficiently, anyway) unless you're talking linux and compiling it...

Yeah we are close.. in fact it occurred to me that virtualization software could become the new Operating Systems of the future, where you then layer the Operating Envirionment (windows, linux, etc) on top, and then the applications on that...

Re:Its inevitable

[bill_kress]

As someone else pointed out, your arguments are FOR interpreted languages. Another example is your bandwidth point. One of the earlier bytecode interpreters was put into excel. Why? To reduce code size.

Bytecode tends to be significantly smaller than compiled code. Smaller bytecode = less bandwidth.

On top of this, a bytecode interpreter can make much more intelligent thread-level optomizations, possibly even multi-threading an app not written to be multi-threaded.

Right now we are at the tipping point where the Java bytecode interpreter is about as fast as a compiled language (about twice as fast in some cases, half as fast in others if you don't consider the FPU problem). From here on, the bytecode will continue to gain in speed while the compiled languages will stay the same--C compilers are already about as optomized as they are likely to get because there is not much you can do with it.

Re:Its inevitable

[greywire]

1997 called. They want their wishful thinking back.

1985 just called:

"An interpreted language like C? Rediculous.." (php, perl, javascript, java [ok, bytecode, but still]...)

"Emulate the Amiga? Impossible.."

"C++ is pretty cool but there's too much overhead"

"C will never be as fast as pure machine code, you can't write games in C..."

How far back do you want to go?

There was a time when if you had said this room sized computer would fit in the palm of your hand they would have said you were crazy.

Sure, an operating system written in an interpreted (or even an intermediate language like .net or java) language may seem rediculous now, even full blown apps are not as fast.. but it will happen. (and yes I am sure there OS research projects probably written this way now..) It may not be for another 5 or 10 years but it will happen.

The benifits of high level languages (including ones yet invented) are clear. And certainly, there is a time and place and always will be for machine code, c, c++, etc...

Re:Its inevitable

[SpinyNorman]

Well, above the rendering level you have the physics of the objects being rendered, which is only just starting to see specialized hardware (physics accelerators) thrown at it, so plently of chance to increase performance by using the main CPUs for that, and even above that I'd have thought that the movement of various self-propelled objects (people, etc) are independent and could be parallelized, and other tasks such as collision detection can also be divided up between threads on basis of objects involved.

Re:Its inevitable

[John Harrison]

Are you at least smart enough to grasp that you don't get it?

Re:Its inevitable

[LordMyren]

i believe parent was talking about 1024 cpus on a chip.

ps, using all 1024 threads was indeed hard.

Re:Its inevitable

[sjames]

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

For every program that can actually utilize that, there's 1000 more that have no use for it. Those thousands will be interpreted or JIT.

In some cases, an interpreter will do better than a compiler. It has to parse the code, but it doesn't have to guess how many cpus it might get or how busy they might be with other things.

Re:Its inevitable

[jnf]

To be fair, using goto *can* be an unclean way for optimizing your code.

Re:Its inevitable

[Pseudonym]

Yeah, I write all of my web apps in High Performance Fortran.

Re:Its inevitable

[lbrandy]

Are you at least smart enough to grasp that you don't get it?

Actually I'm smart enough to realize that I don't have the time nor the patience to start from scratch and explain why people don't understand the actual advantages of JIT'ing versus the observed advantage of JIT'ing because of implementation details. People don't understand that native compilers can do many of the optimizations that they attribute to JIT'ing.. and many neglect the overhead penalty because they aren't used to writing code where it matters. People who writing user-apps don't care about things that actually matter in a discussion between JIT and non-JITed code.

I've learned not to spit upwind, and arguing with people who literally do not exist in the same world I do is pointless. User apps/development-speed/etc/etc versus real-time/response-time/framerate/computation. But nice try at a troll. I give it a 3/10.

Re:Its inevitable

[lbrandy]

You've actually hit the nail on the head. Pretty much everyone who replied to me gave me a lecture about how online optimization is better because it lets you tune to the system. Every single one of them neglects the fact that this can just as easily be done offline in an unsupervised fashion and it will create faster code. It is true that precompiled binaries don't react well to changing system conditions, however, "high end" code should be running in a quiet system, anyway. Keeping in mind this thread is about the death of native code... I point merely to my world of high-performance code... where there is absolutely no chance of this ever happening. Any alpha-programs like scientific computing or even games will, for the entire foreseeable future, do the heavy lifting natively.

Re:Its inevitable

[try_anything]

Keeping in mind this thread is about the death of native code...

True, but death is always an overstatement. From our perspective, assembly language is thriving in a permanent niche. From the perspective of a programmer from the 70s and 80s, assembly language has died a dramatic and impressive death.

In the end, I don't think a fair comparison between native compilation and virtual machines really matters. The popular and finely tuned virtual machines are designed to support dynamic languages and to prevent or recover from many classes of errors, whereas the popular and finely tuned compiled languages are mostly static and don't do any dynamic checking the programmer doesn't specifically request. For example, the effort put into statically compiling Java code will never begin to compare to the man-years put into the major JIT Java compilers, so it doesn't really matter whether statically compiled Java could theoretically compete with dynamically compiled Java. Similarly, we'll probably never see the full potential of byte-compiled C++ or Fortran. (You can compile C++ for .NET, but the runtime is designed to be a "nicer" platform than bare metal and support nice languages like C#.)

Re:Its inevitable

[Olivier Galibert]

Connection machine at a guess. The beautiful era of vector cpus and data parallelism. Which got scaled up and down at the same time to modern MMX/SSE/Altivec and friends.

    OG.

Re:Its inevitable

[rhesuspieces00]

the hurdles are economic, not technological.

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]

> It's starting [to] annoy me as much as people [who] can't tell they're from there from their.

I'm not from there. I'm sorry if it annoys you, but, really, I'm not.

(You should probably put some quotes in there somewhere).

It's usually USians who get these things wrong, of course. Those I've talked to really don't seem to care much and explain it away as "evolution of the language".

I guess there's an argument there somewhere, but I look to history and find 'reports' of 'people' (iirc, Webster) deliberately changing the language - not out of ignorance, but just to piss off the English. It worked - and is still working.

Just another example of 'Embrace and extend' - part of the US culture (is that an oxymoron?). The USA is the 'Microsoft' of the English language - copy it, then change it so that it doesn't work properly with the original version. ... and you lot complain about China.

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

Wow - you actually used 'correctly' correctly! Awesome! Obviously, you're not an Apple user, else you'd spell it different.

BTW, for anyone who's interested, it's not "British English", it's just "English". The Scotts, Welsh and Irish each have their own language - some even use them.

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

[EvanED]

It's usually USians who get these things wrong, of course. Those I've talked to really don't seem to care much and explain it away as "evolution of the language".

I guess there's an argument there somewhere, but I look to history and find 'reports' of 'people' (iirc, Webster) deliberately changing the language - not out of ignorance, but just to piss off the English. It worked - and is still working.

And I can give you many examples of where typical British use (I don't say "English use" so as to remain unambiguous) has changed in the last couple hundred years and US use hasn't. Is England allowed to change the language and the US isn't?

Present-day British is no closer to that earlier [16th century] form than present-day American is. Indeed, in some ways present-day American is more conservative, that is, closer to the common original standard than is present-day British. [p. 179] .... On balance, it is hard to say which variety of English, American or British, is the more conservative and which is the more innovative. [p. 180 of Language Myths, Bauer and Trudgill, "America Is Ruining the English Language"]

part of the US culture (is that an oxymoron?)

We're still behind Europe in some sense, but we're also a quarter as old as most European countries.

Even given that, we're by no means devoid of our own culture. Would you like me to go through and name some American* authors, artists, composers, etc.?

Wow - you actually used 'correctly' correctly! Awesome! Obviously, you're not an Apple user, else you'd spell it different.

Heh. That always did bug me.

BTW, for anyone who's interested, it's not "British English", it's just "English".

"British English" is "the English language as spoken or written in the British Isles; esp. the forms of English usual in Great Britain, as contrasted with those characteristic of the U.S.A. or other English-speaking countries." [The OED under "British"]

The Scotts, Welsh and Irish each have their own language - some even use them.

What does that have to do with whether there is a British English?

*American. I know you apparently don't like this term. To be honest, I'm not exactly happy about it either. However, I cannot think of a term for us that is pronouncable and doesn't sound stupid. ("USians" is too hard to say if you pronounce it "U S ians" and stupid if you pronounce it "us ieans", and isn't consistant with not pronouncing "The US" as "The U S".) "Americans" is generally understood as referring to inhabitants of the US, especially in context, so for lack of a better term I'll use it.

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

[Jeremi]

There is no reason to refer to the people of North, Central and South America as "Americans".

There is one reason: it's the blindingly obvious thing to call people who... live in America.

Re:On the subject of loosers...

[mysticgoat]

It's starting annoy me...

Grammar nazis who don't proofread their posts are starting [to] annoy me...

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

[popeguilty]

There's this thing where someone is full of rage, or despair, or hate, or somesuch, and they can't help but project it upon the rest of the world. Psychiatric help: the life you save may well be your own.

Re:On the subject of loosers...

[Baddas]

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"

Perhaps simplifying it to 'US citizens' is best, as really, the USA is composed of several cultures intermeshed in a single country (try introducing someone from rural west virginia to someone from Los Angeles County. Statistically speaking, odds are 50/50 they don't speak the same native language)

Re:On the subject of loosers...

[chrylis]

Grammar Nazis...

Re:On the subject of loosers...

[GunFodder]

That's just sour grapes from over 700 million poor people. Why get hung up about our appropriation of the name of an Italian mapmaker?

Re:On the subject of loosers...

[csrster]

Perhaps you _are_ going mad and are just imagining all these people agreeing with
you about the spelling of "lose".

--
Yours Faithfully
yr. diseased imagination

Re:On the subject of loosers...

[Olix]

You could go for "Yanks". Apparently, in America, you use that term to refer only to people in the North-east, but the rest of the world uses it as a general term for all the people from the USA. "Seppo" is pretty cool, too, if you are want to pretend to be Cockney.

Re:On the subject of loosers...

[nettdata]

Is this before or after you try and get an audience with the French PM?

Re:On the subject of loosers...

[Schraegstrichpunkt]

American. I know you apparently don't like this term. To be honest, I'm not exactly happy about it either. However, I cannot think of a term for us that is pronouncable and doesn't sound stupid. ("USians" is too hard to say if you pronounce it "U S ians" and stupid if you pronounce it "us ieans", and isn't consistant with not pronouncing "The US" as "The U S".)

"Usians"... pronounced similar to "Asians", but with a leading "yoo" instead of "ay".

<troll>... and why shouldn't a name for people from the U.S.A. sound stupid? It's quite fitting.</troll>

Re:On the subject of loosers...

[cartman]

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

Wow - you actually used 'correctly' correctly! Awesome! Obviously, you're not an Apple user, else [sic] you'd spell it different.

BTW, for anyone who's interested, it's not "British English", it's just "English" [sic]. The Scotts [sic], Welsh and Irish each have their own language - some even use them.

Your own English usage is hardly impeccable.

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

[HaydnH]

The English language was started in the late 5th century AD when the Angles, Saxons & Jutes emigrated from what is now Northern Germany & Denmark. The Angles had a rise to power over the other tripes and hence all three tribes were known as the Angles in early documents. All three tribes spoke what was called Anglish - Later this was known as Enlisc and later due to vowel & language changes it became Inglish and then English.

If you're telling me that a language spoken in the same country for the last 1500 years has suddenly become "British English" just because other countries speak the same language I'm afraid I'll just have to laugh! Further, while the Welsh, Irish & Scots do mainly speak English these days they all have their own languages which are still widely spoken today (except maybe the Scots... not too sure about their language).

And before you say I'm just saying that because I'm English, I'm not, I'm Welsh. Our language is even older, in fact it's one of the oldest languages still spoken today except for possibly Chinese, Greek & Latin. The Celts were in the British Isles as far back as 600BC... and yes... most of my family do speak Welsh, but if I ever have to call it Welsh Welsh you can take a running jump!

Re:On the subject of loosers...

[Hognoxious]

I think that confusion arises because there is a word "allot", meaning something similar to give or allocate.

Re:On the subject of loosers...

[zoney_ie]

> We're still behind Europe in some sense, but we're also a quarter as old as most European countries.

Actually, the USA is far older than most modern European states. Many were part of larger states until the last century. The larger states have been involved in the World Wars and earlier conflicts, and lost various places to independence, and so have been through (several) major incarnations since the USA was established. Even some places on the periphery like Sweden and Norway have changed a lot in just the last 200 years (the US is older than that) - they used to be in a Union.

My particular country in "Old Europe", Ireland, is only 84 years old (and the UK not only changed when we left, but changed subsequently with the British Commonwealth and loss of colonies/empire). France and Germany are even younger (the fifth Republic, and re-unified Germany - even West Germany wasn't even 50). Spain and Portugal were fledgling democracies only 20 years ago. The Italian Republic is only 60 years old. The Kingdom of the Netherlands is only 52 years old. Belgium is one of the few states independant nearly as long as the USA, from 1830, but it is a very different constitutional structure now, and a federal state.

The USA, although changing in size, has been pretty much the same government structure for far longer than even the western European countries.

Re:On the subject of loosers...

[mpcooke3]

Even given that, we're by no means devoid of our own culture.

Look the truth is you stole our language but got the spelling mixed up.
Then in return you destroyed our quaint little community oriented high streets replacing them with chain stores like McDonalds, Starbucks, Subway, etc,

We're still behind Europe in some sense, but we're also a quarter as old as most European countries.

Oh god. What else do you have planned? :)

Re:On the subject of loosers...

[giorgiofr]

Go to Friesland in northern Holland. Listen to the native speakers. If you want to retain the purity of your language, I suggest you start asking them for lessons.

I'd rather suggest a visit to Iceland. Or maybe a trip back in time to discover what real Indoeuropean sounded like! And I'll stop at that because we don't really know what was there before the Indoeuropean arrived.

Re:On the subject of loosers...

[robthebob]

I've got to say, I don't really feel that your argument stands up here. As an example, you say "The Kingdom of the Netherlands is only 52 years old" which stands in stark contrast to a Golden Age of maritime dominance starting in the 17th century. Your position is too pedantic to avoid taking into account the addition of Hawaii in 1959 and therefore the USA is only 47 years old. Claiming that a change of government or style of government destroys a country and creates a completely new one is naive in the extreme.

Re:On the subject of loosers...

[chthon]

tripe = cured entrails

Re:On the subject of loosers...

[robthebob]

Why do they have to be poor?

Re:On the subject of loosers...

[Principal Skinner]

I like the word "simplication". I can't figure out whether that was supreme cleverness or just an amazingly fortuitous typo.

Re:On the subject of loosers...

[squoozer]

Their they're itll all be alot better soon.

Re:On the subject of loosers...

[Haeleth]

Go to Friesland in northern Holland. Listen to the native speakers. If you want to retain the purity of your language, I suggest you start asking them for lessons.

Why? The language they speak today is not particularly closer to Old Frisian than modern English is to Old English.

Re:On the subject of loosers...

[zoney_ie]

The US is the oldest surviving presidential republic in the world.

The complete change of form of governance that most if not all European countries have had in the last century is indeed an entirely different matter to the addition of states to the federal USA.

I stand by my claims that European countries today are completely different to 100 years ago. Mine is - it's quite some difference being under British rule or not. France and Germany and all of Europe involved in World War II in particular is a different place.

Yes many things remain the same, but its not comparable to the USA, which is indeed a truly old country stuck in its ways.

Re:On the subject of loosers...

[Ricin]

"The Kingdom of the Netherlands is only 52 years old"

Where did you get that idea?

King Willem I (1772-1843), King Willem II (1792-1849), King Willem III (1817-1890), When King William III died in 1890, his only daughter was too young to reign. Queen Emma acted as regent until her daughter Wilhelmina came of age in 1898. Queen Wilhelmina (1880-1962), then Queen Juliana (1962-1980) and Queen Beatrix (1980-now). (Link here)

After the Spanish occupation, but before the monarchs, Holland was mostly a republic of some sort.

Re:On the subject of loosers...

[popeguilty]

You've never actually been south of the US, have you?

Re:On the subject of loosers...

[jcidiotashram]

Just another example of 'Embrace and extend' - part of the US culture (is that an oxymoron?). The USA is the 'Microsoft' of the English language - copy it, then change it so that it doesn't work properly with the original version. ... and you lot complain about China....
being able to embrace and extend is an important part of a language. if it can't be embraced or extended then i guess british will be the only people who will be speaking english (ofcourse apart from the fact half of the world was once their colony). the fact is there are so many borrowed words from many languages in english, while so many classical languages like Sansktrit are almost dead because it didn't allow extension..

Re:On the subject of loosers...

[Handpaper]

if I ever have to call it Welsh Welsh you can take a running jump!

What, as opposed to Patagonian Welsh?

Re:On the subject of loosers...

[HaydnH]

That's obviously Argentinian Welsh =P

Re:On the subject of loosers...

[GoatMonkey2112]

Because USA is the best one, so it is obviously the default.

U.S.A.
U.S.A.
U.S.A.
U.S.A.
U.S.A.
U.S.A.

Re:On the subject of loosers...

[tolan-b]

If not for the Russians you might be too,

Re:On the subject of loosers...

[zoney_ie]

See my comment above. The current "Kingdom of the Netherlands" includes Netherlands, Netherlands Antilles and Aruba, and is a federation from 1953.

However, I'll admit this is pretty pedantic.

Re:On the subject of loosers...

[Siward]

It's usually USians who get these things wrong, of course. Those I've talked to really don't seem to care much and explain it away as "evolution of the language".

Yep, we definitely have a monopoly on stupidity here in the states. Who explained it away as "evolution of the language"? A 14 year-old? Come over here and ask anyone with an English degree or an English minor and they'll tell you how much they despise things like this. Just because you have a prejudice against us doesn't mean that everyone over here is uneducated and dull.
Most of us who say "British English" call it that because saying "English" over here doesn't mean to us what it does to you. Do Australians always refer to the English they Australian English? Get over yourself.

Just another example of 'Embrace and extend' - part of the US culture (is that an oxymoron?). The USA is the 'Microsoft' of the English language - copy it, then change it so that it doesn't work properly with the original version.

Excuse us while we treat companies as plural nouns, inferring that every employee in the business had something to do with the current topic of conversation. Now I'm going to go complain about how Yanks drive on the right-hand side of the road, and insinuate that this makes them want to marry their sisters.

For any sane, rational Brits with common sense, this isn't directed at you. Just the ridiculous people who us as driving down the road in our Confederate-flag-sticker, gun-rack-with-hunting-rifle, open-beer-drinking, NASCAR-playing-on-a-four-inch-battery-powered-TV-w atching laden cars. I have plenty of respect for Britain and enjoy the BBC shows I do watch, but I don't want to put up with this stupidity any more than you do.

Re:On the subject of loosers...

[rjshields]

"British English" is "the English language as spoken or written in the British Isles; esp. the forms of English usual in Great Britain, as contrasted with those characteristic of the U.S.A. or other English-speaking countries." [The OED under "British"]

There's no need to use the term "British English" unless you're differentiating against some other form of English. English by definition is from England. That's not the case for American English or any other bastardised version of the language.

Re:On the subject of loosers...

[tvon]

Go ahead and call 10 people in each country in the Americas and find out how many identify themselves as "American"

I suspect you will get 10.

Re:On the subject of loosers...

[Feanor124]

We have America in our country name therfore, Americans. Canada - Canadians, Mexico - Mexicans, Colombia - Colombians, Brazil - Brazilians, Peru - Peruvians. What's the problem here? I don't want to be classified as part of a continent, because people from a continent rarely share equal cultural bonds, which is really what these name clasifications are about. Personally, I think that we reserve the right to call ourselves Americans if we damn well please, because if you don't like it, we'll just give you all back to Hitler. The point is, we've been calling ourselves that for long enough that we aren't going to change, it's a matter of national pride. That being said, this is the most pointless off-topic contibution to Slashdot in a long time. I wish I could mod everyone down who was off-topic. (That includes me)

Re:On the subject of loosers...

[twistedsymphony]

I've never hear anyone but those outside of the US use the term "yanks"; however, people from the south-east do refer to north-easterners as "yankees" (it has to do with the Civil war). Though people in the north-east only refer to those living in New York as "yankees" (that mostly has to do with Baseball). Because of that If you call someone from Massachusetts a Yankee you're likely to get yourself shot.

Re:On the subject of loosers...

[twistedsymphony]

DAMNIT I even previewed my post and couldn't manage to get through it without a grammatical error.

Re:On the subject of loosers...

[mpcooke3]

Atleast we'd have better beer.

Re:On the subject of loosers...

[tvon]

("USians" is too hard to say if you pronounce it "U S ians" and stupid if you pronounce it "us ieans", and isn't consistant with not pronouncing "The US" as "The U S".)

Why does everyone on this thread not get that "USian" is shorthand for "United Statesian"?

Re:On the subject of loosers...

[SnapShot]

Claiming that a change of government or style of government destroys a country and creates a completely new one is naive in the extreme.

The flip side of your argument is the specious claim that since Native Americans lived here 20,000 years ago the United States is 20,000 years old. Countries are defined by political borders and borders are established, negotiated, and fought over by governments. Do you think that Japan post-WWII is the same country as pre-WWII? Or Italy? Is the UK the same country pre and post Magna Charta? How about pre and post the War of the Roses? How old is Russia? Does it date back to Ghengis Khan, to Peter the Great, to Lenin, or to Boris Yeltsin and Mikhail Gorbachev? How about China? Is it the same country as it was before Mao? Can valid arguments can be made for all of these opinions?

I think the grand parent makes a valid point. The U.S. is an "old" country in many respects and suffers, somewhat, from being stuck in it's ways. There's still an interesting bias in the history books (or at least there was when I was in school) in the U.S. that we're the young underdog against the established European powers. This mindset persists along side a bias that the U.S. is the sole superpower and guiding light of the world. The human mind is increadibly powerful in it's ability to maintain two contridictory opinions at one time.

Re:On the subject of loosers...

[CamonZ]

The english language also has many french words in it wich came from the migration of the normands to the british isles. i think the different terms as british english, american english, are for the dialects spoken in each region. the language is called english, but dialects differ from one place to another. you should go to belgium, they have flemish, wich is the collection of dialects that come from dutch that they spoke. even 10kms away from the place you live in belgium people talk a completely different dialect. Although for technical purposes the language is refered as dutch. we have that as well everywhere in latin america, our language is spanish (except for brazil) but it varies in coloquial words from one country to another and within regions of the same country

Re:On the subject of loosers...

[Jesapoo]

Uuuuhm... No.

Although you could argue that the United Kingdom really only existed from the Act of Union of 1800 onwards, I would argue that the various laws and acts which have created the UK are really just a continuation of government as has been in place since the English Monarchs were in control - more of an evolution than a revolution.

If, instead, you wish to point to Parliament, it has existed in various forms since 1066, although you might point to dates such as 1215 as the first point when those other than the monarch exerted control over government action, or 1265 when the first form of parliament truly first emerged. Maybe 1295, when the model parliament was formed? How about 1660, the date of the restoration?

Even the 11(?) years following the Civil War (the "Interregnum") when the Cromwell's were essentially Dictators, Parliament still existed, simply without the upper house. After the restoration, the country was returned to essentially exactly the same state it was in beforehand. Other than that, there has been a constant, fluid, evolution of government.

Lets take a looksie...

England as a country in pretty much the modern form has existed since Athelstan of England.

Wales and England have, essentially, been governed together since 1284. Officially they were united in 1535.

Scotland and England were similarly governed together since 1603, and officially since 1707.

The same thing with Ireland from the 15th-17th Centuries, officially since 1800.

The Republic of Ireland separated in 1922. Would you say that was a good point to say the UK existed from? I don't, and so I would argue that all the other changes that you state are just as much of a continuation of government as this.

If you lived in Germany over the last 70 years, I think there are several points where you could say, "Yes, this is a different country" - but i don't think any such drastic changes have happened in the UK which would make an observer say the same thing.

I'd say the UK has been in existence since 1284, and since then it has just added on extra bits :) If you don't like that date, how about 1295, when the entity that can be traced as the direct form to which the modern Parliament evolved from was first formed - i.e. the initial incarnation of the modern form of government, still in use today? Even if you use 1603, based upon monarchy, that still beats the US by a fair whack ;)

Re:On the subject of loosers...

[MadHobbit]

Re: The name of Canada: It depends who you ask.

The name "Dominion Of Canada" is generally put forth as the long form of Canada's name. It's in the 1867 Constitution Act, but not the 1982 Constitution Act, nor the 1982 Canada Act. It's been used by the federal government to a greater or lesser degree throughout Canadian history, and according to the federal government, Canada's official name is still "The Dominion Of Canada":

http://www.pch.gc.ca/special/flag-drapeau/defi-cha llenge/reponses-answers_e.cfm

On the other hand, the CIA World Factbook says that there is no long name for the country of Canada, and I don't recall ever seeing/hearing the phrase used in any current context.

(FWIW: The CIA World Factbook gives "United States", not "America", as the short form of "United States of America". But that's the thing about colloquialisms...they're not "official", just widespread and commonly understood.)

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

Re:On the subject of loosers...

[First Circle]

I'm from Vermont, and people in the north-east most definitely do NOT refer to New Yorkers as "Yankees", with the one exception of those working for George Steinbrenner. Yankees are New Englanders. Hence the title "A Connecticut Yankee in King Arthur's Court" and Yankee Magazine. New Yorkers are just another variety of "flatlander" (i.e. anyone not from VT, NH, or ME).

Re:On the subject of loosers...

[popeguilty]

Not really- that's a flawed analogy. It might be analogous if it were common to refer to the English and only the English as "United Kingdomers."

Re:On the subject of loosers...

[khaustic]

I hate it when people can't tell the difference between their they'res, their there's, and their theirs.

So their.

Re:On the subject of loosers...

[cooley]

But America is a land mass, and the parent I was responding to seems to believe we should refer to all persons from that land mass as "Americans". Isn't Britain a land mass?

Re:On the subject of loosers...

[swv3752]

You forgot Basque which is older and some theories claim it is the Neanderthal language.

Besides, modern English is as much Norman (French) as it is Anglo-Saxon (German).

Re:On the subject of loosers...

[Richard Steiner]

Come over here and ask anyone with an English degree or an English minor and they'll tell you how much they despise things like this.

One doesn't have to have an English degree in order to dislike incorrect or lazy English usage. It isn't difficult to use proper English, or something approximating proper English, even in casual conversation.

I think too many Brits watch cowboy movies. Most folks in the US grow up in an environment which is quite different from that stereotype. Just ask anyone from the east or west coasts, or the midwest, or any large metro area. :-)

Re:On the subject of loosers...

[swv3752]

It is considered that the Virginia accent is closer to Elizabethan English than Modern British English is.

Re:On the subject of loosers...

[blackfacetwin]

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.

This has been driving me crazy, too. When I've complained about it to people who don't primarily read text generated by techie-types, however, my rants have been met with vacant stares. So maybe it's a nerd thing.

I had an office-mate in graduate school - he's a mathematician now - who complained that he could never remember which "oo" sounds required only one "o" and which required two. He was constantly prooving theorems involving smoth functions.

Re:On the subject of loosers...

[jedidiah]

It's not just that. A number of European countries didn't exist as independent countries or distinct nations or unified ones until relatively recently.

Re:On the subject of loosers...

[hesiod]

Despite the trollish phrasing, you are correct. Mr. "Baddas" has no idea what he's talking about. I am originally from West Virginia and people there do not all sound like ignorant hicks. In fact, it's more likely that the people from LA would not understand WV residents than the reverse. Seriously, people in California don't usually have difficult-to-understand accents, except for maybe hispanics and visitors from other places. And as long as someone is speaking english (or close to it) and you actually try listening, it's not that hard to understand them -- unless you are complaining for the sake of complaining or have your direct attention turned elsewhere (like when you're trying to get phone tech support).

Re:On the subject of loosers...

[spectre_240sx]

By that logic wouldn't "Alunium" make more sense?

Re:On the subject of loosers...

[An ominous Cow art]

Speaking for myself, eating "cured entrails" would be likely to cause "sick entrails"...

Re:On the subject of loosers...

[Siward]

I absolutely agree, but only included those with English degrees and minors because they are more authoritative sources. If an English professor said that grammar, spelling, and usage were unimportant, that would have greater repurcussions than the average lay English speaker believing such things (especially given the "i dont tink speling shud effekt ur opinion of other ppl" crowd).

Re:On the subject of loosers...

[robthebob]

I'm not 100% sure what you mean. I think you're assuming that I'm from the US to start with, which is false. Are you also suggesting that the reason they are annoyed is *because* they are poor, and if they were rich they wouldn't mind? I'm not quite sure what you're getting at here.

Re:On the subject of loosers...

[popeguilty]

I'm suggesting that being born south of the US is in most cases a recipe for very poor living conditions.

Re:On the subject of loosers...

[Bastard of Subhumani]

So what about Iridium - should it be Irdium? Absurdium maybe.

Re:On the subject of loosers...

[robthebob]

Ok, I guess you misunderstood me. I wasn't saying they they were poor because it was their own fault or anything, the OP seemed to be saying that their opinions counted less because they were poor. Either way, I didn't see what relevance it had.

Re:On the subject of loosers...

[spankfish]

And we've made the number system more consice and practical, for example thousand million -> billion.

And yet you persist with incredibly inconsistent anachronisms such as imperial measurement ;-)

Re:On the subject of loosers...

[hesiod]

Pardon my presumption. Obviously, I've never been to Los Angeles County. :)

Re:On the subject of loosers...

[Haeleth]

It is considered that the Virginia accent is closer to Elizabethan English than Modern British English is.

If by "it is considered" you are referring to the opinions of some non-specialists who are in no way qualified to discuss the matter, then yes. If you thought you were referring to any kind of serious theory that holds credence among specialist linguists, then I'm sorry to break it to you, but no, that is a myth.

The Virginia accent preserves some features of Elizabethan English that have been lost in certain modern British dialects. But it has also lost features of Elizabethan English that have been preserved in most modern British dialects. There is absolutely no reason to suppose that Shakespeare would find rural American speech any more familiar to his ears than metropolitan British speech; both have changed drastically over the centuries.

Re:On the subject of loosers...

[angel'o'sphere]

Hehe,

while I find your post interesting, this makes no sense to me: aluminium ->aluminum

Why do you remove the *I*????? After all the word is spoken aluminIIIIum. So you are to lazy to speak the I?, Oki ... but then you went one step farer than in your colour -> color example. In colour, the *u* is indeed not spoken, but in aluminium, the *I* is spoken!! At least all over the world outside of USA!

angel'o'sphere

Re:On the subject of loosers...

[angel'o'sphere]

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

Last time I checked my dictionary (what I rarely do), they did.

but rereading your words: sodium, potassium and calcium, is more correct .... and aluminium, is of course the correct SPEAKING, so why write it without an *I*?

Likely because you SPEAK it WRONG. In other words you don't speak the *I* .... but thats your problem. In Europe EVERYONE speakes it ALUMINIUM, so everyone writes it liek this, its completely silly idea to remove the I (in our eyes, erm, ears).

Anyway, I'm getting used to US ppl speaking old words wrong like Zeus -> ZOOOS instead of how it is spoken correctly: Z(joy)ce.

angel'o'sphere

Re:On the subject of loosers...

[rsidd]

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

Eh? They are British (even if some of them would rather forget that fact). They aren't English.

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

[Eideewt]

Of course, that problem goes away if the VM is pretty much always in use, since it's been loaded already. Especially if the whole OS is coded on top of it. Then you do have the problem of it always sucking resources though.

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.

Re:Negligleable performace hit my...

[Billly Gates]

That is because there are over 100,000 methods in the java api!

All those need to be dynamically compiled so the java applications can link to them. One of Java's best strength's is its api. You can look it up by going to www.java.sun.com and selecting javadocs?

I am sure perl or python would be even slower if it had that many api's to dynamically compile into bytecode.

Java is semi native and not %100 interpretted so it can be just as fast as C or close to it if the section of code is already compiled at runtime to the JavaVM that runs on your native processor. Perl or python are alot slower as more interpretation is used.

Re:Negligleable performace hit my...

[MBCook]

The computers I use with Windows and Java have 1.5.06 and it is still very slow. Once it gets running Java is nice and fast on Windows. But it just takes forever to start up. Even if Java was running 1/2 hour ago and I've used other stuff since, it's slow.

On my Mac, it never takes much time at all. It's quite quick. I may not use Java for 2 days (I don't turn my Mac off) but the next time I go to use Java it pops up quite fast.

I remember the MS JVM and how much faster it was. That was nice. Still, with Windows being such a HUGE platform you'd think they'd work on better performance for it.

Re:Negligleable performace hit my...

[MrSquirrel]

What are your PC specs and your Mac specs? Proc, RAM, HD speed, OS, browser, anti-virus, anti-malware. All those things make a big difference in computer performance.

Re:Negligleable performace hit my...

[MBCook]

I agree. But whether it's my mother's 2.16 GHz P4 laptop or one of the brand new P4 HT desktops at my school, there is a delay. It's slightly better on the newer computers. But on the older computers I have access to (and by older I mean early P4, late P3) the computers just DRAG when you start Java and can sometimes almost seem to be frozen. All of this is on computers that are quite responsive opening other apps and such.

Re:Negligleable performace hit my...

[tepples]

My PC specs: 0.866 GHz PIII; RAM: 128 MB; OS: Windows 2000 with latest service pack; anti-virus: HouseCall; anti-malware: Spybot SD; bank account: small. What can I do to speed up the JVM?

Re:Negligleable performace hit my...

[MBCook]

I really don't know, I'm sorry to say. I remember when I had to switch from the MS JVM to the Sun one. Things just slowed down SO MUCH when that happened.

I think it's the startup that causes people to say "Java is slow", because once you get INTO the app if it is written half-decently Java can be very peppy. It's just the launch time that kills it. It's just like it doesn't matter how fast the computers at your office are, if they take 1 minute to boot people will call them slow.

Try a Mac the next time you're at a store that sells them. You'll be amazed how fast Java starts. THAT'S how Java should be.

Can anyone comment on how fast Java is to start on Linux? I haven't messed with Linux in over a year, and Linux + Java in longer than that.

Re:Negligleable performace hit my...

[zzatz]

"RAM: 128 MB"

Add RAM. Marketing considerations always drive default PC configurations towards faster CPUs at the expense of everything else, and RAM suffers the most. 128MB is fine if you only run one application, but you don't - anti-virus, anti-spyware, firewall, and multitudes of Microsoft 'improved user experience' crap are usually running. 2000 has less of the latter than XP, though.

Re:Negligleable performace hit my...

[NutscrapeSucks]

The computers I use with Windows and Java have 1.5.06 and it is still very slow.

There's a very noticible difference in app startup speed if you see the Java icon in your taskbar. At least for me. It's still not real fast, I agree.

Re:Negligleable performace hit my...

[ctr2sprt]

That is because there are over 100,000 methods in the java api!

I've got 66,037 on my Python install, which does not include C and other non-Python native functions. 12,989 class definitions, by the way. (Just some find/xargs/grep/wc magic for ballpark figures.)

I am sure perl or python would be even slower if it had that many api's to dynamically compile into bytecode.

Er, not if you don't actually use them. It's not like you fire up a Python or Perl program and it loads every library on your system just to display "Hello, world!" to the screen. It's also worth mentioning that Python modules, at least, get byte-compiled when they're installed. They only get recompiled if you change the source, making the compiled version obsolete.

Java is semi native and not %100 interpretted

I don't have anything to add here, I just wanted to look at this while I was writing my reply.

Re:Negligleable performace hit my...

[MBCook]

Cute troll. I didn't say Java "sucked". I said the JRE on Windows was slow to boot.

I like Java quite a bit. It's a nice language with a great environment and a wonderful library and fantastic documentation.

It's probably about my favorite at this point, based solely on the library and documentation.

Re:Negligleable performace hit my...

[Gulthek]

You don't know? He said he has 128 megs of RAM and you don't know what he can do to speed up java?

Yo, GP. Want to speed up java and everything else? Up to at least a gig of ram.

Re:Negligleable performace hit my...

[tepples]

Up to at least a gig of ram.

Will it fit in my Dell Dimension 4100, which was purchased 5.5 years ago? This page claims that a Dell Dimension 4100 has two slots and can't use RAM sticks larger than 256 MiB, resulting in a limit of 0.5 GiB.

If the answer is a new computer, are you buying?

Re:Negligleable performace hit my...

[Blakey Rat]

... except Java's a terrible choice if you want quality software. There's no way to get a Java app to behave like a native app in Windows, Linux *or* OS X because the Java frameworks only seem to have the bare minimum functionality supported on each platform. Show me a Java app on OS X that supports AppleEvents/AppleScript, the integrated spell-checker, the Services menu and *doesn't* look and run like ass, and I'll be really impressed. Right now, the best example of a cross-platform Java app seems to be Limewire, and it leaves a *lot* to be desired on OS X.

Re:Negligleable performace hit my...

[kaffiene]

This is complete and utter BS. JVM startup on Windows is just over one second - I just tested a hello world app 1.125 sec.

Re:Negligleable performace hit my...

[alphamugwump]

I'm not really sure how slow Java itself it. But I do know that programs written in Java tend to be insanely bloated and hog ram like nobody's business. Look at Eclipse, or OpenOffice. To mangle an old saying, every Java program eventually includes an update manager and its own widget set. Speed problems definitely aren't confined to startup time. This may be the fault of the people who wrote Eclipse, and not the fault of Java itself, but you have to wonder: If the Eclipse devs can't get Java to perform right, who can?

Java performance on Linux *is* faster, though, although that may be because Linux is better at handling swap. I have heard, although not seen, that Runescape runs much faster under Linux.

Re:Negligleable performace hit my...

[morcego]

Yo, GP. Want to speed up java and everything else? Up to at least a gig of ram.

That is the kind of logic that really destroys the "Java idea" for me.
So I have a program coded in C++ that will run perfectly on my 256MB system. But to use the exact same program coded in Java, I have to get a system with 1GB system.

Maybe on the they Java shops start shipping extra RAM cards with their software I'll think Java is a nice idea. Until them, I'll ALWAYS choose the compiled alternative.

And no, I don't care if the software itself costs 10 times more than the memory. It is still my money, and I don't enjoy seeing it wasted.

Re:Negligleable performace hit my...

[jamesh]

.NET stores the pre-jit-compiled binaries for later use, do Java JIT compilers not do the same thing?

In theory (and in an ideal world), JIT compiled code should actually be faster than pre-compiled code, because optimisations can be made on the basis of actual execution path rather than predicted execution path, and for the current CPU, not just the lowest common denominator. Also, the moment you upgrade your JIT compiler, all bytecode on the system can take advantage of it immediately.

On the other side, the JIT compiler would be a nice place to hide malicious code, especially if the malicious code detection software was itself JIT compiled...

Re:Negligleable performace hit my...

[protohiro1]

I'm using Zend studio right now on windows and launched fast and runs great. This is the app that convinced me that java/swing is a legit way to write desktop apps. Unless its a game or a graphics app interpreted code works. And java/swing is portable, so it doesn't matter what os you run on.

Re:Negligleable performace hit my...

[lokedhs]

Eclipse use SWT, so it doesn't count. OpenOffice is written in C, so it doesn't count either.

Some better examples of fast Java apps would be: IntelliJ IDEA or Aqua Data Studio.

Re:Negligleable performace hit my...

[GunFodder]

Your argument is fine as long as there is a compiled alternative. But developing VM apps is almost always faster and easier than compiled apps. So it may come to the point where the compiled alternative is faster and uses less memory, but is also buggy and doesn't have all the functionality you desire. Or there may not be a compiled app available at all.

I agree that most people will continue to use compiled apps when they have a choice, but more and more developers are going to choose VM environments due to the ease of development. Improving VM designs and hardware specs will help mitigate the performance hit of the VM.

Re:Negligleable performace hit my...

[morcego]

I really don't buy the "less buggy" argument either. I have heard it over and over again. Bad programmers will produce bad code, no matter the language, be it either asm or java. Also, it is easier to get bad programmers for "easy" languages.

I do understand the economical aspects. Specially when a PHB has to show a CEO that he can produce stuff faster.

What people seem to keep misunderstanding is that the "coding" part of the job is just a small part of the time required to produce good software. The planning and bugtracking takes much more time, or at least does if you want to have a good end product. And even if coding if easier and faster with Java/.NET etc, debugging is much more difficult, since you can trace the execution just so far.

So yes, if you want to produce "budget" software, Java/.NET is the best choice. If you want to produce "good" software, then you should go for C/C++. Not that it is not possible to produce good Java software or budget C++ software.

Re:Negligleable performace hit my...

[MemoryDragon]

One issue is that the mac vm gives 86 MB heap size default. Java allocates only the heap it is assigned too but also uses it as much as possible so that no mem is wasted, sort of like the app behavior on macos9. often if you have startup time problems a conservative mem setting (standard windows java assigns 32MB to my knowlege) is at fault letting the gc having kick in constantly during startup. A different windows startup param can help here, try following java -Xmxm -jar and see if it works. For instance java -Xmx64m -jar netbeans.jar would start a netbeans jar with a 64MB mem boundary.

the reason for this behavior is, that it makes a lot of sense in a server context and also some sense in a client context. First the mem usage can be better, no wasted ram, secondly a haiwire going process cannot gobble up the machines ram, like it happens on Windows too often. But this feature is not advertised enough, so many people either run java with too much ram (due to extensive predefines of ides or servers) or too few ram, due to relatively low predefines of the standard vm and jdk in a default install. And believe me, the correct mem settings can make a huge difference, also in startup times.

Another issue might be virus scanners going haiwire on the loaded jars, which are in itself nothing more than zip files.

Dont get me wrong, java has a longer startup time, and I see it as the biggest problem points, ram is not the issue anymore, speed is more than ok nowadays, sun has done a great job there and the machines have gotten faster, but for pure client apps the startup time is critical. The good thing is that java programs tend to be rock stable, and can be up for months if done well (eclipse is more the exception than the rule, by having to be restarted once a day, partially to be blamed by swt), so things might help if you adjust your usage of the programs by leaving them open. But for client side apps, I still think this is not a fully acceptable situation. For server side apps it is ok, once it is started you leave the server running, a predictable mem usage behavior and being rock solid is more important in this area.

I wonder what the issue with the shared vm is, it used to come out with JDK6 and it has been postponed again, a shared vm would resolve all of these instances sort of by preloading the vm.

Re:Negligleable performace hit my...

[ElfKnight]

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.

Takes about 2-3 seconds on all the PCs I use. Perhaps you need to defrag your disks ;-).

Re:Negligleable performace hit my...

[sbrown123]

On every computer I use with Windows it takes up to 20-30 seconds to launch Java.

Wow. Are you saying to load the virtual machine (which is Java) or to run the program/applet? With applets there is the whole issue of having to download the code to be executed which may take awhile depending on the size of the program. Recent versions of Java cache content nowadays to prevent to the need for constantly downloading (although it does verify what is there is recent). Now, if you are saying the virtual machine is taking that long to start I would be truly mystified. The only time I have ever seen Java take that long of a delay to load the VM was when running on a 486 16-bit version of language on Windows 3.1. I don't even think that computer went much past 20 seconds at worst though. Oh, and before anyone asks IBM had a Java version that ran on 16-bits called "ADK for Win 3.1".

Java is fantastic on Mac OS X. I don't know how fast it is on Linux.

Yeah, I have seen mixed results on different computers. Apple wrote its own Java VM optimized for their systems.

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.

On Windows prior to Vista, .NET is slower than Java *when no other .NET apps are running*. If there is another .NET app running, .NET loads much quicker. This is because the .NET virtual machine can be shared across apps. Java loads a new instance of the virtual machine for every single app (stupid Java). On Vista, the .NET "realm" will probably always be running (for WinFX) so you can count that .NET will always load faster than Java on that platform. I have no idea if Mono has this capability.

Then again, maybe Mac OS X preloads Java.

Apple should clobber Sun over the head for their inability to figure out how to do this. I've talked to enough Sun developers to know theres a certain level of arrogant ignorance that is actually killing the language. They ignore the development community (unless to copy their OSS efforts) and would not improve the language until forced to by .NET. I keep hoping they will release their iron grip on the language and make it free.

Until then, I'm off to go look at NekoVM as a replacement for all things Java (Neko is pretty smooth and I give props to that anonymous slashdotter who mentioned it to me).

Re:Negligleable performace hit my...

[ealar dlanvuli]

1997 called, it wants it's java back. You might try a JVM written in the last 5 years.

Re:Negligleable performace hit my...

[GunFodder]

I agree that there are good programmers and bad programmers, and that the amount of time spent on coding is just a small part of a well managed project. That said, the constraints of real software projects dictate that there is never enough time to code everything perfectly. This is why every non-trivial software system in the world has bugs. I don't see how this affects the productivity gains from using a VM language. Built-in memory management and extensive libraries mean that there is less code to write and debug.

This is the first time I've ever heard anyone claim debugging is more difficult in a VM language. My experience is with Java, which certainly has better built-in debugging features than C or C++. My guess is that you are more familiar with the debugging process for compiled languages.

Re:Negligleable performace hit my...

[morcego]

Actually, I can't write a single "Hello World" program in Java. I have people here that do that kind of programming.
Maybe we are just working on projects so different that our experiences are oposite.

Re:Negligleable performace hit my...

[Haeleth]

developing VM apps is almost always faster and easier than compiled apps

No, developing high-level apps is faster and easier than developing low-level apps.

It is certainly not faster and easier to develop an application by writing Java bytecode directly, even though that is writing for a VM. And it certainly is faster and easier to develop in a high-level language like D or ML or Haskell than it is to develop in C, even though you are not writing for a VM.

Please, please, please, for the love of God, educate yourself a little and drop this simplistic artifical dichotomy that declares that every single language is either "compiled" and therefore horrible like C, or "interpreted" and therefore wonderful like Ruby. Because it's simply not true, not helpful, and makes you look ignorant. Thank you.

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.

Re:Not quite the end yet

[bioglaze]

You mistyped the URL. Here's a working one: http://www.digitalmars.com/d

Re:Not quite the end yet

[Otter]

You mistyped the URL.

Heh, I'm so accustomed to "You mistyped..." as the preface to Snotty (and usually misspelled) Nerd Sarcasm, it took a moment to realize that you were being genuinely helpful!

Application!

[Daxster]

You're going to get a lot of the same sort of responses now - lots of people arguing about a requirement that these non-compiled programming languages aren't suited for. Every language has a different purpose when its creator(s) decides what direction to take.

The answer is to use a mixture.

[the eric conspiracy]

The old saw is to not optimize until you have to. Write in an interpreted language, but be ready to dive into native code when the need for speed arises.

Re:The answer is to use a mixture.

[ceoyoyo]

Exactly. Choose an interpreted language that makes it as easy as possible to do that.

I use Python on OS X. It's quite easy to wrap some C or C++. Objective-C is wrapped for you (which, conveniently, includes all the OS X system frameworks).

There's no reason why you shouldn't write all your GUI stuff in an interpreted language. Using the native GUI system still seems to be a good idea though. Still, there are always going to be algorithms you want to run as fast as possible, meaning you're going to want to write them in something lower level.

Re:The answer is to use a mixture.

[davecb]

Very much so!

many moons ago I was on a fast-text-search project, which used a pre-jit interpreted language (one of Per Brinch Hanson's), and had almost no assembler or native code whatsoever.

It was fast because it used fast hardware, a custom AMD bit-slice processor. We mixed medium-slow code for the boring bits and a read of a custom device for the time-critical part.

--dave

Re:The answer is to use a mixture.

[Goaway]

The old saw is to not optimize until you have to. ...Is total bullshit. Or rather, severely misunderstood. If you're not taking speed into account whenever you write code, you're going to writing shitty code.

What it really means is that you should not disruptively optimize until you have to. Don't hand-unroll loops or re-write in assembly until you have to, because it turns the code into a maintenance nightmare. It doesn't mean that you shouldn't write efficient code whereever you can.

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

[blank89]

It doesn't take a genius to see that the same OpenGl code that works just fine in c or c++ is slower than molasses at the north pole in the winter when ported over to java.

Re:two things

[bunions]

That's funny, because JOGL isn't anywhere near "slow as molasses". Not if it's written by someone who's paying attention, anyway.

It's not close to native code, of course, but then there's a lot of applications that don't need to be, which was my whole point. For instance, scientific visualization apps typically love to trade increased hardware requirements for decreased development time, because they have such a limited audience, comprised primarily of the programmers themselves. Speaking as a programmer, I can put up with GUI sluggishness in programs I write for myself if it means I never have to track down a memory leak.

Re:two things

[blank89]

There are plenty of applications where a bit of lag won't do any harm, but there are still enough programs that need the higher performance that native code is still a vital part of programming. For instance, 3d benchmarking utilities and games would have a heck of a time in java. Even being optimized in lower level languages and with the latest hardware, the latest games and benchmarks run out of resources (clock cycles, memory, etc...).

Re:two things

[bunions]

yes. There are several types of applications, some of which are appropriate for interpreted languages, some not as much. thanks for pointing that out.

Re:two things

[blank89]

You're quite welcome.

Re:two things

[tepples]

There are several types of applications, some of which are appropriate for interpreted languages, some not as much.

Unfortunately, the staunchest advocates of these interpreted languages seem to completely ignore environments that are inappropriate for interpreted languages, such as anything involving 8-bit microcontrollers or hard real-time environments (e.g. electromechanical control systems) or soft real-time environments (e.g. games) or environments where the only available implementation is not useful (e.g. startup time of a Sun Java virtual machine on Windows).

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

[rand_chars]

My question is why the VM factors into the developer time at all?

A VM is a convenient distribution means, but I don't see why a language such as Java or C# needs a VM, or why it's a significant advantage? As a matter of fact, I'd say that the existance of GCJ proves that Java does not need a VM in order to work well (although GCJ currently sucks, it can be treated as a valid proof of concept)

Re:two things

[EvanED]

Speaking as a programmer, I can put up with GUI sluggishness in programs I write for myself if it means I never have to track down a memory leak.

But speaking as a user, I'd rather have a program crash occasionally, or have to restart it because it's ballooning in size, then have it be sluggish.

Just my opinion.

Re:two things

[bunions]

yes. There are several types of applications and environments, some of which are appropriate for interpreted languages, some not as much. thanks for pointing that out.

Re:two things

[bunions]

This is a good point. There's nothing particular about the VM that saves developer time unless you're talking about cross-platform development. I suppose what I'm talking about when I say interpreted languages save developer time is that interpreted languages are memory managed. Also they tend to be easier to debug.

Re:two things

[larytet]

...or we need to produce 1 mil devices which are not general purposes computers and production costs (Bill Of Material) are important

Example: ADSL modem

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:two things

[Eivind Eklund]

Interpreted code is fine for many aspects of games. Of course, you can't use it in hard real time embedded systems (though I used Ruby for doing scripting to support my programming on those boxes).

I think we'll see the end of native code for "large" systems one day, given how well optimizing JITs are getting. I seem to remember that some time back HP even optimized PA-RISC by running a PA-RISC emulator with JIT on top of PA-RISC...

Eivind.

Re:two things

[quadelirus]

Just to add to this. Goto: http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

Re:two things

[iamtheredpill]

Nice, I read many comments and found yours one of the most cogent.

Re:two things

[Maltheus]

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.

I don't believe that at all. There was a time where I was seeing most enterprise applications being developed in C/C++. Now, it's almost exclusively Java. And our support people love us for it. The lack of memory leaks and mysterious crashes and the decreased time-to-develop have all but made compiled languages obsolete on the back-ends. There is no going back and I suspect this is true in most companies.

Also, don't forget what makes Java shinier than the other interpreted languages, a massive standardized class library. A class library that is easy to use because it's so well documented (more than say C++ STL library by leaps and bounds). That probably has more to do with its success than any other factor, including portability.

Re:two things

[Anonymous Coward]

Wow - great reply and excellent way to sum things up. I suspect you and I both have probably been in this general area of work (IT and related) for quite a bit longer than the avg. reader of this forum...

Several years ago, my motto became "the more things change, the more they stay the same" when speaking of "new" computing trends. It never fails to amaze me how history seems to repeat itself in this business - the difference being that in IT and related, the trends of 'bygone days' repeat in internet time compared to other endeavors (as in, the cycles seem to happen every decade or so).

One thing you can really count on with regards to general trends in IT, is that we've almost certainly been through similiar before (on a macro level), and the only thing that has really changed is the specifics.

As an aside, roughly 15 years ago I can recall an MS engineer predicting that interpreted VB Pcode would soon match or exceed compiled code in many areas, especially because of how the interpreter had runtime information and could take advantage of things like multi-threading and CPU pipelines running in parallel, etc. Sound vaguely familiar?? Now of course, it's JIT, multi-core, etc., etc... None of this stuff is really new - JIT's, multi-core and the like have all been around for years now, really, they just happen to be the mainstream trend (right now).

Re:two things

[Pseudonym]

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.

You're right that the comparison is bogus, but it highlights a very important issue: even in high performance computing, interpreted/JIT/whatever languages still have a place.

The reason is that the overwhelming majority of reusable nontrivial programs (the "reusable" part is the important part here) are structured as a bunch of highly optimised low-level routines strung together by a domain-specific language, and in many cases the DSL is interpreted, or may as well be.

Think about it for a moment, and pull some random numbers out of the air. Suppose that 99% of your compute time is spent in low-level numeric code, such as lapack or atlas. Suppose that using an interpret language imposes a 5 times overhead. Then writing the 1% (by time) of the application in an interpreted language adds only 5% to the run time. However, you win the ability to make huge algorithmic changes (which, when they do apply, tend to pay off really big) very cheaply, while still keeping the high performance of the low-level routines, which can pay off more than the 5% performance drop that you lose.

(Note: Someone may object at this point that Amdahl's Law applies here, in the sense that making the high-level "serial" part of your program slower can severely limit any benefit of parallelisation. Yes, this is true. On the other hand, potential parallelism is (in principle) more easily discovered in a higher-level language. As always, YMMV.)

In many respects this is no different in principle from the same argument used in other areas of computing. Many web applications are written in interpreted languages (PHP, Perl, Python, Java), but web applications are just very sophisticated glue, linking together, say, a web server with a relational database server. Nobody is arguing that the RDBMS should be written in Java, merely that high-level decisions are better expressed in a high-level language. The difference is that web applications run at the speed of the network, which is usually the slowest component in a distributed system. High-performance numeric code tends to run at the speed of the CPU or, more likely, the speed of L2 cache/RAM.

In summary, while I'm not disagreeing with anything you said, I would like to point out that just about any domain can benefit from high-level languages, if they're applied intelligently. That's why they pay us the big bucks, right?

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

Re:What?!?!?

[Kethinov]

They're appropriate for many tasks. Web development is a good example, along with productivity apps that don't depend on speed. An alarm clock app, or post it notes, or other such small things. But apps making use of binary media or requiring extensive math such as a physics engine on a game or an emulator should use native code.

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.

Re:Why isn't anything compiled natively anymore?

[try_anything]

why is it that everyone else things it's still okay to compile to byte code or scripts. It's not; end of story.

Lemme set you straight: once you have code, you clearly aren't working with anything "native" anymore. An FPGA with a nice custom hardware design doesn't need any "code" slowing things down. Just put data on one set of pins and get answers out the other. What's with you software rubes who think the same jack-of-all-trades generic processor should be used to solve every problem in the.... ummm... uh... I think those ASIC guys are coming over here to kick my butt and take my lunch money again. I'm gonna, um, run.

Re:Why isn't anything compiled natively anymore?

[Cederic]

Why on earth should I compile natively when it's going to give me marginal performance improvement (if any) and drastically reduce my deployment options?

I develop on windows. I test on linux. I deploy into production on solaris. I have one build script, and it gives identical output whichever platform I run it on. Oh, and we're looking to deploy into production on linux now too - so we can horizontally scale.

Hardware is cheap. Developers are not. Good developers are neither cheap nor easy to find. So a portable language that average developers can use and maintain several year old systems in makes a lot of sense to me.

Who cares how many x86 blades you need to handle your load. My business customers care far more about time to market, stability, flexibility and total cost of ownership.

Re:Why isn't anything compiled natively anymore?

[NuclearRampage]

http://research.microsoft.com/os/singularity/ They shed some light on a kernel in c#, although it is not 100% c#.

Re:Why isn't anything compiled natively anymore?

[usrusr]

Linux users are aware of compiling java code natively

the only scenarios i can think of where gcj really makes any sense is when you have some java code (preferrably some that does not make very extensive use of the class library) that you want to link to from a statically compiled language or when you are writing little command line tools in java where jvm startup time and jitc warmup are the two major performance bottlenecks and not runtime speed.

Re:What?!?!?

[Kethinov]

Fun fact: Even in non-native apps, the playing itself is usually done by native libraries. (GStreamer, Xine, libmad, etc.)

The non-native code just drives the UI.

Yet these apps still incur a severe performnace hit. Clicking the "next song" button in Quod Libet (a Python app) for example takes up to one or two seconds to load the next song for me. XMMS is instant.

Not so fast

[blank89]

There will always be native code because it is faster. When code needs to perform better, rather than be more flexible, people will always go back to Asm and other such low level languages.

Re:Not so fast

[iguana]

Amen.

I see a mix in the future. Use interpreted languages where possible, drop into C where necessary.

I have to push around 500M raw (RGB) images. I do the preliminary work in Python then move the really slow stuff into a Python module using C. Python's distutils makes it ridiculously simple to compile module on Windows, Linux, and MacOSX.

Result? Doing something simple to that 500M image takes 20-30 seconds in Python and less than a second in C.

It's like anything else in life. Use the tool appropriate for the job. If you find yourself constantly using a butterknife as a screwdriver, maybe it's time to investigate other tools.

And yet?

[LordoftheLemmings]

And yet even though c was 200x slower most people now program in C or a "higher" language, why? Portability and ease of use. Isn't that what interpreted languages offer us more of?

Re:And yet?

[tomhudson]

... and lots of embedded assembler.

Use C as a wrapper, embed your custom assembler for each platform inside each function, and you've got portability AND performance.

that's how its done. And that's not going to change. Besides, at the rist of bringing this back on-topic (they mentioned the requirements of Vista) how "portable" is Windows nowadays? Oh, right, its the least portable mainstream OS there is.

"Managed code" sucks. And the runtimes for those "managed code" languages are written in ... wait for it ... native code. Can't run that "managed code" without a runtime.

Re:And yet?

[martinultima]

The only problem with that is, if you wanted to port to a new system, you'd either need to (a) write a new assembly-language routine for the new platform's CPU architecture, or (b) have a platform-independent C/C++ fallback which you could use on non-native platforms, kind of like a lot of libraries like imlib2 and SDL do for processor-intensive code – sorry if I'm butchering the terminology ;-) While assembly language runs code fast, C/C++ makes writing code fast, at least if you know C/C++. It's really the same thing as with X and fancy video drivers – while there's nice direct-renderer drivers for the more popular video cards, there still has to be a basic one that goes through various X calls for the cards which they don't have direct rendering on. Kind of a loose analogy, but I think it makes sense, anyway.

Disclaimer: I know enough C to write a basic "hello world program" and that's about it... I'm a Linux distribution maintainer, so I'm a lot better at building software than writiing it.

Re:And yet?

[ZephyrXero]

And yet there are projects in the works like PyPy, where a Python interpretor is being written in Python itself.

Re:And yet?

[tomhudson]

Oh, I agree, but lets face it, how much hardware portability do you need nowadays? Would you rather a game with embedded assembler that plays fast on one platform, or sucky on all platforms :-) BTW, the linux kernel does this - c with embedded assembler routines, different routines for different platforms http://en.wikipedia.org/wiki/Assembly_language

It's also common, especially in relatively low-level languages such as C, to be able to embed assembly language into the source code with special syntax. Programs using such facilities, such as the Linux kernel, often construct abstractions where different assembly language is used on each platform the program supports, but it is called by portable code through a uniform interface.

Browse the source code for Delphi - again, embedded assembler.

Now imagine a database that can run x times faster because its written in a non-portable way. Will it find a market? Sure, there's always someone who needs MORE speed, and is willing to pay for it. Even if the speedup is only 2x, it would be a market shake-er-up-per.

Your SNES - assembler.

The embedded systems running your car - written in assembler.

Re:And yet?

[ClosedSource]

Portability is more of a religious issue than a practical one for most applications.If Linux ever became the #1 OS, I suspect that portability will fade from importance on Slashdot. It's really an outsider's issue.

Re:And yet?

[tomhudson]

... and you can write a c compiler in c, and an assembler in assembler. If you look at the pages, you'll see that while it might be written in python, it still ends up having to generate code in another language - either native code such as c or an interpreted language such as javascript, that needs a runtime written in native code:
http://codespeak.net/pypy/dist/pypy/doc/architectu re.html

# the code generator which translates the resulting flow graph into another language, currently C, LLVM, Javascript (experimental).

Last I heard, c wasn't on the list of managed / non-native languages, the llvm back-end emits c code, and javascript requires an interpreter.

Ultimately, there's native code at the base of every program running on your computer. The cpu can't run anything else.

Re:And yet?

[me3head]

Why do people insist on calling _assembly_ language "assembler"? I dont call compiled languages "compiler"

Re:And yet?

[petermgreen]

for desktop and server applications in the current climate portability to AMD64 is going to become imporant but not to other architectures.

But being able to run the same OS on your desktop and on your embedded equipment certainly carries its advantages. You can run the vast majority of linux software on your embedded box (performance permitting) with a simple recompile.

Re:And yet?

[martinultima]

And that's actually what I was thinking about when I posted that – I've been working on porting my Linux distribution to AMD64 for a few months now, and let me tell you, those embedded assembler routines can be absolute hell, especially when there's no alternative C-based function, no way to disable the assembler, and no easy way to sidestep the problem (e.g., leaving the program out altogether). Trust me, solo AMD64 porting is not a task for the faint of heart...

Re:And yet?

[petermgreen]

true but for all the vital stuff the likes of debian have done it already, so you can just grab thier patches.

Re:And yet?

[ZephyrXero]

I'm well aware of the fact that a computer can only read machine code, but the whole point of the main article is whether or not it's worthwhile for programs to be written in Interpreted/JIT/Managed/whatever type languages... What something is written in, and what it is compiled/interpreted down to are two completely different things ;)

Re:And yet?

[tomhudson]

Fair enough ... just that writing in a compiled language like c or c++ cn be just as easy as, or easier than, writing in a managed language. You just need the right tools.

Re:And yet?

[martinultima]

Damn, don't tell me you've figured out my FTP habits! :-) That's actually what I've been doing, although even Debian's got a few things missing here and there that cause total hell for me, and since my system's Slackware-based, the sources are easy enough to compile, but finding them can be difficult since Debian's package management system splits everything up into a million little pieces...

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

[Medieval_Gnome]

This is completely anectdotal, so please take this with a large grain of salt.

I'm doing some research at my college where part of what I need to do is generate reasonably large (1GB) lookup tables. The program to do this started out in C++ and migrated to Java later on so it would be easier to get my non-linux using companions up and running with the program.

To my complete and utter shock, the java version was slightly faster than the c++ version, even though I had far more function calls in my java version. The runtimes were around 60 minutes vs. 67 minutes.

Now the c++ compiler was gcc, which you've said doesn't have the greatest code generation. But I still would not have expected java to outperform it.

Re:Someone's been reading too many benchmarks

[Panaflex]

And there's a reson for that. Java is trading memory management for speed. It utilizes large regions of memory and the only penalty is when you run out and the GC kicks in.

You can do the same thing using the Boehm GC.. I've done it with C/C++ develpment and I've never looked back. Unless I've got some major speed necesseties it makes no sense to spend all your development time managing pointers and class teardowns.

I don't think there are many applications out there that really "need" to manage their own memory . Especially with the memory bandwidth we've got today - it's practically free to memcpy on an Opteron.

Great for developers - who often have plenty of RAM. Stinks for low end users, who most often have the minimum amount to run 1 application.

Re:Someone's been reading too many benchmarks

[1729]

Now the c++ compiler was gcc, which you've said doesn't have the greatest code generation. But I still would not have expected java to outperform it.

What options did you use with gcc? By default, gcc does very little optimization. Try -O2 or -O3.

Re:Someone's been reading too many benchmarks

[szundi]

The real thing with the Java JIT compiler based runtimes is the optimization it does while it's running the code.
Interpreted languages are 10 times slower than natives.
-- BUT!!! --
If java runs a code portion more and more times, it makes every time some slight optimizations on it. The more you run a code portion, the more optimized it will be. So, in some seconds or minutes your code will be highly optimized. These places in the code called hotspots.

That's just something that everyone knows for sure. But the real thing is that this JIT compiler can have the time to make some REALLY good optimizations. Think of it:
  - you have 2500 .java files:
    - it compiles in eclipse in ~ 1 minute.
    - some slow startup
  - you have 2500 .cpp files (you should have more because java is a bit "higher" level)
    - it compiles in ages with for example -O2 optimization
    - have faster startup
But you can see, java is unoptimized C++ code is optimized. ...
Ehe. In the start :)
You run the java code with the JIT runtime, it optimizes the hotspots even to -O7 in some matter of minutes, if it's able to (implemented, option switched on etc.). So, at the end, your JAVA CODE RUNS FASTER!* (*=after some running)
Yes, you can -O7 your cpp builds, but it will last hours or days to compile a relatively small program, so you won't do it because you are lazy :) Yeees, you are :P

Re:Someone's been reading too many benchmarks

[vtcodger]

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

Or something ...

My P166 with Windows 95 boots and runs applications faster than my wifes' 2.4 GHz XP machine. At least until we get into stuff that starts swapping because the P166 has only 64mb of memory. I get frustrated on the newer "faster" machines (we have several around here) because they are so unresponsive compared to the antique. I can't get over the feeling that we're doing something wrong here but I can't quite pin down what.

My gut feeling is that the issue is not native code vs interpreted. Maybe its something we might call the crud to useful code (C2UC) ratio. That is to say that interpreted code on a low C2UC machine will be more satisfactory than native code on a high C2UC box.

I expect from the hardware requirements that Vista will probably open new horizons in high C2UC and low user satisfaction.

Re:Someone's been reading too many benchmarks

[ObsessiveMathsFreak]

If java runs a code portion more and more times, it makes every time some slight optimizations on it. The more you run a code portion, the more optimized it will be. So, in some seconds or minutes your code will be highly optimized. These places in the code called hotspots.

I keep hearing this one, but I've yet to see a real world example of this almosy mythical property of JVMs. In any case, I seriously doubt most Java programs, or more appropriately, troublespots within programs, will be running long enough either for optimisations to take place, or for the optimisation overheads to be justified.

Re:Someone's been reading too many benchmarks

[Xugumad]

Did you have a lot of frequently called code in the Java version? Some of the Java VMs (I think Sun's does it) optimise code on the fly, which is deeply funky when it works :)

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.

Re:Someone's been reading too many benchmarks

[szundi]

All true. Maybe i should have stressed more that it's about the usual lazyness i've mentioned. Most programmers don't bother to do long-run high optimizations if it lasts long. Java has built-in optimizer, and i run lots of java codes, and it performs much better than other interpreted languaged, like php for example.

You are right about the language disadvantages, but java has more opportunities because of this single lack of feature - it can much more easily code-transformed than other languages, for example c++. C++ may be "much more customizable" code, but it cannot be handled with the same ease as java. I don't like programmink c++, but I love programming java. There are tremendous amount of java fans out there, kind of fortune? :) No, it's because the tools developed to work with it. In the past 5 years, really good FREE tools emerged to help java developers, and C++ is far more from that, that's my feeling.

The real point is, that java is not so much slower than any other language. I can say that. Maybe other programs can be faster, but not much faster than 5-10 years ago.

Re:Someone's been reading too many benchmarks

[Medieval_Gnome]

I did try with -O3 and it only took a few minutes off the runtime, which really surprised me. The code had an inner loop that was being run a billion times, so I'd think that even the slightest optimization would have a larger payoff.

Re:Someone's been reading too many benchmarks

[Medieval_Gnome]

You could say it was frequently called. I had a loop that ran a billion times to compute the table, and it would seem the JIT took advantage of that in a very good way. And I totally agree with the complete funkiness of the speed.

Re:Someone's been reading too many benchmarks

[julesh]

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 key advantage of using a JIT compiler to perform optimisation is that you can perform optimisations that only work under conditions that are not provably true, and then undo the optimisation if it later turns out to be false. In your example, the JVM could do that, as long as it ensures that if such a subclass is loaded the optimised method is invalidated and recompiled before next use. See the description of the Java HotSpot JIT here:

A new class may contain new methods that need to be inlined in the appropriate places. So the Java HotSpot performance engine must be able to dynamically deoptimize (and then reoptimize if necessary) previously optimized hot spots, even during the execution of the code for the hot spot. Without this capability, general inlining cannot be safely performed on Java technology-based programs.

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

Attributes were added to the language in version 1.5. You can now mark your classes and methods with arbitrary attributes, which individual compilers and runtime environments are free to interpret however they wish.

Re:Someone's been reading too many benchmarks

[IamTheRealMike]

True, however the JITC must keep bookkeeping data to be able to undo the effects of optimisations. In this case the memory pressure and bookkeeping overhead added by tracking call site optimisation locations would probably outweigh the benefits.

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.

Re:As A Developer

[Chosen Reject]

I for one love pointers. That is, I want to decide whether I do call by value/call by reference. I dislike Java's Call by value-result. If Java gave me the ability to play with memory and pointers, I'd still prefer c/c++ though.

Re:As A Developer

[Merle Darling]

So use C#. The syntax isn't as cumbersome as Java's and you can still do all the nasty pointer manipulation you want.

Re:As A Developer

[miyako]

I have used C#. Not extensively, but I've played around with it a bit. I do like it, and might invest some time in playing around with it a bit more in the future. Largely, I haven't done much with it since I don't use Windows, though it looks like mono is comming along quite nicely. I've been seeing more things written using mono. Of course, C# is a pretty new language, and still suffers from the problem of not having the large existing number of libraries as languages like C++.

Re:As A Developer

[fozzy1015]

I understand where you're coming from. Both your comment on how Java is best for small programs and that many people stick to C/C++ because it's what they know.

I really do think one of the best insights a programmer can get is to take some C code and run it through a disassembler. Takes a little low-level background knowledge but I think one of the best insights a programmer can achieve is to understand exactly what the processor does from a line of code in C. Like the basic concept of calling a function. The memory address after the call is pushed on the stack and the instruction register of the processor is loaded with the memory address of the function entry point. Or when a function returns a value. How many people know the processor puts the return value in the accumulater register(on 80x86, it's EAX)? That sort of knowledge helps figure out how type-casting works and I think gives the programmer a much better knowledge about how the language actually works.

Re:As A Developer

[Vexorian]

I agree 100%.

Also, I personally doubt native code will end its existance

As long as native is faster than interpreted languages there will be a good reason to use it instead of interpreted languages. The fans of interpreted languages might prefer native code to die, but it will not do so

With the help of good libraries C++ can easily achieve the Cross Platform status which is by far the most important feature of interpreted languages

You might argue that you need a garbage collector to type your code, but that's not really true and even so if you plan to make a big project with c++ you can always make your own memory manager

As far as coding effectiveness goes, if faster development is more important than faster execution interpreted languages are the answer"

Re:As A Developer

[Aceticon]

Having a similar background as you (so both C++ and Java development) i believe that the reason why Java pushes developers harder towards a specific paradigm than C++ does is because the ideal situation for software development - a team of experienced software developers all with at least some software design experience, lead by an senior designer/technical architect and with realistic deadlines - is very rare in the real world.

When junior programmers, developers without the design experience to see how the code fits into the wider application/system design or irrealistic deadlines the are thrown into the picture then:

• The likellyhood of programming/design errors increases faster with C++ than it does with Java
• Coding mistakes/bad-choices tend to have wider-ranging effects (as in affecting other people's code) in C++ than in Java

Managed and Unmanaged Code...

[ndykman]

Overall, I think the answer is yes. As far as .Net goes, there are a lot of advantages to having libraries and applications in a format that can be just-in-time compiled or pre-complied to native code on installation. Certainly, for MS it is a big advantage, as they don't have to target a lowest-common denominator of CPU features. Another advantage is that .Net does have pretty decent interoperability with native libraries. So, if you need the native performance, you can use a native library to try and gain some performance back without going totally native.

As for Java, I think it has a couple of issue that gives it a bad impression. Certainly, it's integration with native code could be improved (JNI is pretty hairy at times). Also, it seems that the current JREs don't have a lot of native tweaks to increase startup time. Certainly, I think Java could use a utility like ngen for .Net to precompile libraries to native code. Used correctly, it can improve cold start times.

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:Cross Platform not related to language

[Fordiman]

Very good point. And the real question is: in what way is something like Java superior to C++ when you take away the ease-of-access via the web?

Re:Cross Platform not related to language

[jcr]

in what way is something like Java superior to C++ when you take away the ease-of-access via the web?

Well, I'm no fan of Java, but the fact that it was designed, rather than accreted makes it superior to C++, IMHO. C++ is a horribly complex language.

-jcr

Re:Cross Platform not related to language

[jcr]

Have you noticed how much of the Java APIs are depreciated?

You're talking about the library, I'm talking about the language.

-jcr

Re:Cross Platform not related to language

[GrievousMistake]

I'm thinking that's why Microsoft has started pushing the .NET thing (horrible name), the move to 64 bits made them realize the need for cross platform compability, as in 'Windows on another architecture'.
I can't for the life of me imagine why open source projects like Beagle are using .NET, though. You have the source, if it's any good you can just compile it on any system that has the right libraries. Even Microsoft isn't moving their own projects to it in a hurry.

Re:What?!?!?

[Ambush Commander]

Well, server-side applications and client-side applications are, quite arguably, different sorts of programs.

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.

Re:Java and Mac OS X

[BigCheese]

I love Puzzle Pirates too. It runs wonderfully on my Linux box with the Sun JVM. From what little I've seen Bang Howdy (also from Three Rings) is even more impressive.

Puzzle Pirates made me rethink what you can and can't do in Java.

Re:Java and Mac OS X

[evought]

True, but platform specific bugs happen on every platform. The VMs are never perfect at insulating you. Sometimes it is an underlying OS bug but often the Java programmer took liberties with the language in assuming something the specification just does not guarantee. I have seen that often with threading code. There is a lot of threading behavior unspecified and this was worse in the past. The programmer thinks that because their code works on their test box that it is correct. Often it just worked by accident.

We had problems with Sun's JVM on Windows in a large server project when I was contracted to IBM. The JVM would not release closed socket handles and the pool would eventually run out, necessitating a reboot. At the rate the server was taking requests, "eventually" was very thirty minutes or so. Linux and Sun had no problem. As soon as IBMs own JVM became stable, we switched, but their JVM had subtle glitches too, though they were not as serious and it ran much faster.

Threading is really hard to do cross platform, and one of the main problems/benefits of Java is that every program is threaded.

Re:Java and Mac OS X

[WatertonMan]

My understanding is that on the Intel version of OSX it is running Sun's Java runtime. The PPC version had a port by Apple to PPC that reportedly did have bugs. Have you tried this program on Intel? It might also, of course, be a bug in one of the libraries as well.

What will we be loosing?

[scdeimos]

I am not expecting to be loosing arrows from my bow any time soon, but I am hoping that the /. editors can stand to be losing some O's from the summary. :)

Re:What will we be loosing?

[shoolz]

I too detest abysmal spelling mistakes like that. If geeks coded the way some writers write, we'd end up with... well... Windows.

Re:What will we be loosing?

[LoztInSpace]

You'd end up with compile errors, unless of course Windows is written in an interpreted language.

Re:What will we be loosing?

[shoolz]

Wow... talk about seeing and missing the point at the same time.

Re:What?!?!?

[NemosomeN]

Maybe you sucked at writing C. I can't imagine that huge of a difference in performance unless you really just did something wrong. That could include choosing a bad thing to benchmark (Maybe something that triggered a compiler bug?).

Huh?

[Karma Farmer]

Do programmers feel that they are loosing - an arguably needed low-level - control when they do interpreted languages?

Could someone JIT this into english for me? What does "low level control" have to do with "interpreted languages"? And how is either related to native code and virtual machines?

And wtf is "loose"?

Re:Huh?

[remembertomorrow]

And wtf is "loose"?

A common misspelling of "lose" among non-native English speakers. (myself not included, well, most of the time)

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:Huh?

[Karma Farmer]

Garbage collection and virtual machines are two different things. Plenty of native code compilers include garbage collectors, and plenty of non-native runtimes don't.

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.

Re:Not today, not tomorrow.

[countach]

JIT code is not slower than native code. In fact, JIT code ends up being native code. I think it was HP that wrote a C compiler that produced code that was faster than any other compiler. How? It didn't produce native code, it produced non-native code with a built-in JIT, and it blew the doors off all the native compilers. Why? because it could optimise things at run time according to how the program actually ran.

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

Re:GRAMMAR NAZI

[djdanlib]

Actually, Mr. Nazi, you "loosen" your belt. But thank you for your brief list.

Re:GRAMMAR NAZI

[krunk4ever]

According to Dictionary.com:
http://dictionary.reference.com/search?q=loosing

v. loosed, loosing, looses
v. tr.

      1. To let loose; release: loosed the dogs.
      2. To make loose; undo: loosed his belt.
      3. To cast loose; detach: hikers loosing their packs at camp.
      4. To let fly; discharge: loosed an arrow.
      5. To release pressure or obligation from; absolve: loosed her from the responsibility.
      6. To make less strict; relax: a leader's strong authority that was loosed by easy times.

so Mr. Nazi would be correct in being able to say: loosing your belt.

Re:GRAMMAR NAZI

[illuminatedwax]

hahaha antiquated usage triumphs again!!

Amarok?

[Ender Ryan]

~ $ file /usr/bin/amarok /usr/bin/amarok: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, dynamically linked (uses shared libs), stripped

~ $ file /usr/bin/amarokapp /usr/bin/amarokapp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, dynamically linked (uses shared libs), stripped

amarok-1.4.0/amarok $ ls src/
*snip* a bunch of C++ source and header files.

Come again?

Re:Amarok?

[Kethinov]

Yeah, I realized that thing about Amarok after I posted my comment, but the criticism is still valid. It may not be written in an interpreted language, but it's still ridiculously slow. And it crashes a lot.

Re:What?!?!?

[bunions]

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

I don't see the part where he says "they aren't very good for ANY client-side tasks". And more and more traditionally client-side applications are moving server-side, what with this new-fangled interweb and your ajaxes and such and such.

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

[mangu]

Given the current software and algorithms available, more computing power alone wouldn't solve any of the problems you describe.

They used to say exactly that when the best chess program available was Sargon running on a Z-80. Today it's a commonly accepted fact that pure lookahead beats the best intuition a human brain can bring to chess. The method may not be the same, but the result is.

Re:CPUs still have *A LOT* to evolve

[bcrowell]

Hneh...Sargon on a Z-80 kicked my ass at chess so many times, it's not even funny. I think I beat it once.

Re:CPUs still have *A LOT* to evolve

[DamnStupidElf]

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

You will also have a machine that can simulate a million years of dog evolution each year. Modern humans have been around for less than 200,000 years. What do you think a million years of selective breeding and effectively limitless modification of brain structure would do to a dog? If anything, evolution is just waiting for computer hardware to get fast enough to do some *real* improvement.

Re:CPUs still have *A LOT* to evolve

[maelstrom]

Take a look at Go and then ask yourself why there are no good Go AI programs. Chess is easy to "solve" with computers, Go isn't, yet anyway.

Re:CPUs still have *A LOT* to evolve

[hung_himself]

Well, the original Sargon algorithm running on a supercomputer would still be lousy. Chess algorithms have changed - in part to take advantage of the increased number of cycles and in part due to the fact that the designers of the best programs are better chess players. If I recall correctly, the Deep Blue programmers were close to Grandmaster level players. Somewhat smart computer lookahead - but not monkeys at typewriters - can beat very smart human look-ahead...

Re:CPUs still have *A LOT* to evolve

[digitalove]

I would beg to differ. CPUs have been showing a reverse trend... leaving aggressive hardware based optimizations to cram in more cores and increase the performance/watt. This generally helps increase throughput but slows single threaded performance. Thankfully, desktop processors are still not going the same direction where single threaded application performance still matters.

CPUs are not about to evolve more. You might say systems will evolve more... the interconnects, more cores, more SIMD, NUMA etc. Your examaples actually show problems in algorithms used... not the hardware on which it runs.

Re:CPUs still have *A LOT* to evolve

[blackcoot]

to be fair, the additional hardware capabilities open up a lot of methods which might otherwise be unfeasible for OCR and AI in general. case in point, i worked on a project doing real time detection, tracking, and recognition of highway signs. we had a dual p4 xeon which, at the time, was pretty much the beefiest box we could afford for this project. we would have much preferred to use a mean shift filter to do the edge detection and segmentation in the image because it gave really excellent results. unfortunately, it just wasn't fast enough --- using the mean shift stuff typically slowed the system to 1Hz cycle rate. if we had about twice the computational power, we might have been able to make it work.

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.

Re:CPUs still have *A LOT* to evolve

[Adam Hazzlebank]

Sorry this is probably redundant but I wanted add the specifics.

Why isn't there any game where you ride a surfboard realistically?

Because games aren't about realistic simulations they are about fun. The majority of gamers wouldn't like a realistic surfboard simulation.

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?

Because weather systems are chaotic systems. Simply throwing more compute power at this problem isn't going to solve it.

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?

Show me good solutions to these problems that take a long time, and would become practical by speeding them up. In my understanding Computer Vision papers (unless dealing with real time problems) mostly benchmark by how accurate the recognition was rather than how fast, so it shouldn't be a problem. Truth is we're simply not good enough at AI yet.

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.

This may be true. Nothing you've said supports it.

Re:CPUs still have *A LOT* to evolve

[4of12]

to be wrong in 50% of the cases when predicting weather a week ahead?

Faster hardware will only make a slight dent in this problem.

Since you mention continuum physics, you're probably aware of the nonlinearities inherent to such simulations. Given Lorenz exponents that cause infinitesimal differences in initial conditions to diverge exponentially over time, we'll never achieve certainty in weather forecasting. The best we can hope for is to improve our odds by simultaneously increasing computing power to enable us to run finer grids, increase the number of monitoring stations, increase the accuracy and precision of those monitoring stations to improve the 50% probability to say 85% probability of a successful forecast.

Re:CPUs still have *A LOT* to evolve

[An Onerous Coward]

Okay, I should have thrown out a few caveats about algorithmic complexity. Pure lookahead is indeed ideal, given sufficient time to explore *all* options. But pure lookahead to a depth of n? We don't know how deep a pure lookahead algorithm would have to go to beat, say, Kasparov. Might be a new way to rate chess players.

No human is going to wait around (or even live) long enough for his computer opponent to completely map out the entire chess game space, and given the branching involved, speeding up by a factor of a thousand only gives you a few more looks ahead. It's safe to assume that hardware will never be fast enough to fully map out chess space.

My point is only that, once hardware reaches a certain speed, its speed ceases to be the primary constraint, and we're left with the best performance a given algorithm can give us. You seemed to be under the impression that the solution to any AI problem was to throw more hardware at it.

Re:CPUs still have *A LOT* to evolve

[An Onerous Coward]

No. What you describe is an entirely different piece of software. Instead of running dog_brain.exe, you're running whole_world_to_find_ideal_dog_brain_via_genetic_al gorithm.exe. I'm talking about taking the same algorithm, and simply running it on faster hardware. If your text parsing system relies on the Viterbi Algorithm to classify words, then faster hardware means only that you can tackle bigger projects with the same level of accuracy. It doesn't magically turn your program into a perfect parser.

Okay, a more obvious example. Take the TI-85, the calculator I used in high school. Speed it up by a factor of a million. It doesn't get any more accurate, because it's still using the same number of bits to calculate. It doesn't magically gain the ability to solve problems that it couldn't before (unless the problem are time or memory-bound). The advantage to hardware improvements come from the ability to use the right algorithm, instead of hacks to bring in an answer in an acceptable amount of time.

Re:CPUs still have *A LOT* to evolve

[An Onerous Coward]

Exactly. The advantage of better hardware is the ability to either do bigger jobs, or do them in a more effective way (using better algorithms, for example). The problems described by the original poster are, for the most part, resistant to brute force (at least on the hardware we can reasonably expect in my lifetime). In many of the cases he proposes, it's not even certain what algorithm we'd throw at it if somebody dropped a Pentium 10 300-PetaHertz machine in our laps.

In your case, the key words are "real time". You knew exactly what algorithms would do the job, and you just needed a relatively trivial increase in speed to make it happen.

Re:CPUs still have *A LOT* to evolve

[usrusr]

that still means different algorithms. gp poster was mainly complaining that ggp poster was completely ignoring the algorithmic dimension of the problems mentioned.

give the dog enough speed, memory and smart algos and it might end up enjoying the whole crotch sniffing thing because it makes humans blush and act funny.

Re:What?!?!?

[Ambush Commander]

I'll give the parent post the benefit of the doubt. The article text is worded in a way that strongly suggests client-side.

ahh

[Billly Gates]

I took java last spring for a MIS course and I was expecting the usual slow load times with things like netbeans. The class was taught with java 1.5 and I noticed it was fast. All the java applets just loaded including the java programs netbeans on my system.

Oddly I wondered why Azuerous and frostwire seemed to not be that slow anymore as well. I figured I just assumed java didn't suck as I thought it did.

Now I know why.

For the slashdotters reading this, I highly recommend upgrading to java 1.5 on your machine. You will certainly notice a speedup as I did.

Re:What?!?!?

[tomhudson]

... are you really going to claim that ANY c spat out by a compiler can be faster than hand-optimized assembler? Especially when it comes to graphics code.

Think. As one example, the compiler makes assumptions about registers that I'm free to ignore. Ditto with pushes and pops, etc. There are shortcuts you can take in assembler that you can't in c. It doesn't get any faster than assembler. and assembler is probably the most beautiful language to work in, because its what YOU make of it.

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.

Re:Well, yes and no

[suv4x4]

Well, yes and no ... Don't you hate that answer?

I know some guys that hate it: the clueless article writers who only want to proclaim "the end" of something every 3-4 days or so, and thus get more page hits.

Re:Well, yes and no

[jsebrech]

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.

That's the thing. A while back I wrote a web-based CAD application. This app loads autocad drawings from a database, and then shows them in the browser, split up into hundreds (or sometimes thousands) of distinctly manipulatable objects. The user can switch "themes", causing all objects to redraw differently based on the theme's specifications. I wrote the whole thing in PHP and ActionScript (flash), and it's only marginally slower in putting drawings on the screen than the native-code windows app that provides the same functionality (which admittedly is very inefficient). It's even faster in navigating around the drawings once they're shown (as fast as any native app without hardware acceleration that does the same). Interacting with any individual object, once on the screen, is instantaneous.

The trick was making optimal use of native-code libraries on both the PHP and the flash side. The PHP side uses the native regular expression matching functions to convert the autocad drawing streams to SVG (XML). And then the actionscript side uses the native XML parser to read in these SVG files. The structure of the files is done in such a way that very little processing has to happen. Coordinate conversion is not done in my code, it is done by creating flash movieclips with coordinate transformations. Navigating around the drawing is almost entirely native code (flash).

The customer is satisfied, because time-to-market was fast, and performance is good enough (I haven't heard any complaints about performance, at all). My boss is satisfied, because time-to-market was fast, and the bug count low. I'm satisfied because the code is very maintainable, and easy to understand. Native code would have been the wrong tool for the job.

Re:Well, yes and no

[BigCheese]

Yes, that's exactly it. Write the performance intensive bits once as a library and use it from a scripting language. That's what gives PHP, Python, Perl and such all their power.

All the plumbing is native and the actual business logic is scripted. That's why they are fun to use too. You don't spend time writing string parsers and decoders. You write the app.

Re:Well, yes and no

[Maltheus]

My current job involves real time financial data delivery. Writing that in Python or Java would (probably) not work out too well.

When I was a Smalltalk (interpreted) developer, there were a lot of high-paying jobs in the NYC financial district for it. I knew a guy making $200/hour doing it because there was such a demand for Smalltalk developers. In fact, it seemed like Smalltalk only really took off on Wall Street. I had always thought it was because an application that may (or may not) run a few milliseconds slower still ran faster than one that had crashed due to some mysterious seg fault. That and they wanted their applications delivered in a timely manner I'm sure.

Re:Well, yes and no

[BigCheese]

Sorry, I should have been clearer. I work on the data delivery infastructure. We have end user apps in Java/VB/Whatever but the code that gets the data there is all C/C++.

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.

Re:Depends on the task

[IO ERROR]

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.

And this is why GUIs are slow and bloated. Give me a lean, mean, fast GUI, please!

Re:Depends on the task

[throbi]

Agree. Know your requirements first, decide on the language after. But this has to be done by the software designer, not by the programmer. Most programmers tend to stick to a single language/platform and are trying to solve a task whitin those limits. At this time I'm working on a pretty huge system. The real-time part is all ANSI C, communication interfaces are C++ and C# and the GUI is Java.

Re:Depends on the task

[Junks Jerzey]

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.

People said things like this when an 8MHz 68000 was the main CPU. They said it again when CPUs were 10x faster. People still say it with superscalar processors running at billions of cycles per second.

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

[morcego]

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.

Oh FORTH. The wonder language for automation. I remember programing a robot using forth, on the Z-80 days.

I might be wrong here, but a good number of telescopes still run on FORTH systems these days.

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

[jcr]

a good number of telescopes still run on FORTH systems these days.

Yes, and you'll also find FORTH in many other embedded control applications, not to mention the dialect that constitutes Open Firmware, which was in all of the PPC Macs, and is still used to boot most of Sun's hardware.

The company I'm working for is involved in some hardware development right now, and we might very well go with FORTH instead of buying something like QNX for its embedded processor.

-jcr

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

[kiddygrinder]

You are correct, this is the only place where Python makes things harder. I love the Python, i hate the python web dev. It's annoying to develop and (as far as my limited experience goes, but popularity is all about baseless opinions) less stable and less efficient at runtime.

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

[Rinzai]

LISP may have been elegant (if by elegant you mean "improbably difficult to read to the point of being obfuscated"), and perhaps the language is simple, but the programs themselves were not. From what I've been able to see over the years, LISP has been favored only by people that found using HP RP-notation calculators to be a fun and rewarding experience.

BASIC was designed as a teaching language, and looks like it. Attempts to extend it to the real world haven't been totally pointless, but come on--it's a teaching language.

FORTH shares some of the same problems LISP has, although it's more readable. 'Nuff said.

Java, more than anything, has been the cause of more anti-Microsoft conspiracy rants than any other language. Sun kept trying to sell that "Java operating system" crap until even they got sick of it. The idea that somehow a web browser and an interpreted language is equivalent to an operating system is something that will forever remain beyond my ken. Java was designed to run toasters. It was only after Sun failed to sell the vision of Talky Toaster (a shout-out to all the Red Dwarf fans!) that the language (aka the platform--ugh) was repositioned as a way to deliver applications within a web browser.

One more thing: as much as it might pain the /. readership to see it, it is nevertheless true that a slavish kowtowing to standards inhibits advancement. Innovation is stifled, not promoted, by standards committees. Phillipe Kahn's (more to the point, I suppose, Anders Hejlsberg's) version of Pascal was far better than the pap ISO was peddling from their pushcart.

I find it ironic that virtually all the Java wonks are big on standards committees and standards compliance--but not one of them remembers to mention that Sun won't put Java up to ISO or ANSI or ECMA for standardization. Must be some kind of self-denial.

Meanwhile, back at the OP's original question, I'd have to go with C# as the contender. I don't see any reason that C and C++ can't be replaced by C# as we move along. It does a great deal right--better than Java, IMHO. (Python? Logical blocking by indentation? Don't get me started.)

Oh, my karma is SO going to suffer because of this posting, but go ahead. /. karma and $1.19 will get me a Diet Mountain Dew at Seven-Eleven--and I already have the $1.19.

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

[Bob Uhl]

LISP may have been elegant (if by elegant you mean "improbably difficult to read to the point of being obfuscated"), and perhaps the language is simple, but the programs themselves were not. From what I've been able to see over the years, LISP has been favored only by people that found using HP RP-notation calculators to be a fun and rewarding experience.

Intelligent people? Lord knows I wouldn't want to use a tool they like!

Regarding LISP syntax, what's so different between func(a, b, c) and (func a b c)? Yes, Lisp programs can be difficult to read at first--that changes pretty quickly. It was hard to ride a bike at first too, right? And yet once you've learnt, it's never a problem again!

As for HP's reverse Polish notation, that is so nice for calculations, especially engineering calculations. Once you've become accustomed to it, you'll never go back, ever.

The idea that somehow a web browser and an interpreted language is equivalent to an operating system is something that will forever remain beyond my ken.

Why? A operating system provides an abstraction layer so that applications need not deal with the hardware directly. A web browser and an language running atop it (interpreted or not) provide an abstraction layer as well. In fact, given the very minimal role a real operating system plays, I'd argue that even Java--poor excuse for a language it is--fills that very same role.

One more thing: as much as it might pain the /. readership to see it, it is nevertheless true that a slavish kowtowing to standards inhibits advancement. Innovation is stifled, not promoted, by standards committees.

You're quite right about this. E.g. Lisp, which has stagnated since the Common Lisp standard--a standard which gets some things brilliantly right and others horribly wrong (generally the latter is for compatibility: standards again!).

Python? Logical blocking by indentation? Don't get me started.

What's wrong with that? Surely you indent your code to indicate its logical structure already, right? So what's the problem?

Now, I would prefer S-expressions (because then one is easily able to do some really cool syntactic manipulations, including real macros), but whitespace structure beats keyword structure, whether those keywords are 'begin/end' or '{}'.

The only place it falls down is web templating, but that's a discussion for another day.

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

[ealar dlanvuli]

The skillset to make a good web log is not the same skillset to master Lisp. Keep this in mind, many (most) programmers are really not that concerned about actually evaluating their language. They are concerned with getting their particular task done quickly.

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.

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

[rolfwind]

Hi Killjoe,

Here is an essay you should read to answer: "I mean if zope is so great...." why don't more people use it?

http://www.paulgraham.com/iflisp.html

It's about lisp, but it may apply to zope as well. And lisp is experiencing a revival since 2000, when Paul Graham started advocating it. Coming from the C family of languages, hanging myself on c++/java back in the 90's - I've come to love lisp and recognize how much the languages like python/java were attempting to move from c to lisp/otherlanguages in terms of features.

Anyway, I just wanted to say you shouldn't always look at what those around you are using if you already have a tool (language) that works well. You should use what makes sense, and if zope works, there's no reason you can't stay with it, if you're deciding to move just for popularity reasons.

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

[rolfwind]

Most advanced math today comes from people thinking hard in ivory towers years ago (academia).

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

[rolfwind]

Since C/Fortran, languages such as Java/Python have been moving steadily toward the lisp model:

http://www.paulgraham.com/diff.html

And lisp code can be made as fas/almost as fast as C code. I don't know if you were trolling with that old myth, but advances in compiling lisp have let it catch up with C. The only problem is that it's much easier to write slower code in lisp than in C if you don't know what you are doing (in either language).

But I'm sure you knew that.

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

[rolfwind]

LISP may have been elegant (if by elegant you mean "improbably difficult to read to the point of being obfuscated"), and perhaps the language is simple, but the programs themselves were not. From what I've been able to see over the years, LISP has been favored only by people that found using HP RP-notation calculators to be a fun and rewarding experience.

French may be elegant, if by elegant you mean improbably difficult to read to the point of being obfuscated (sorry, I don't know French.)

Lisp is easy to read, if you know the language. Like any other computer language. I actually find the paranthesis/syntax make it easier to read because I know where to expect the function and data and how it's supposed to be laid out. My first language is C and I still find it harder to parse now.

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

[colinrichardday]

From what I've been able to see over the years, LISP has been favored only by people that found using HP RP-notation calculators to be a fun and rewarding experience.

You're kidding here, right? HP calculators are fun to program, at least for mathematical stuff. Nice syntax, just throw stuff on the stack.

Colin Day

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

[killjoe]

Well my point is that you judge the tool by the products you build with it. A beautiful tool is just art if it's not capable of being used to build great things.

Zope is beautiful, from what little I have seen lisp is beautiful. Alas at this point I am convinced that they are just art.

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

[ciggieposeur]

Zope is beautiful, from what little I have seen lisp is beautiful. Alas at this point I am convinced that they are just art.

I won't speak for Zope, but my experience with Lisp is that it is most of the way through a painful transition phase. Prior to the standardization of CommonLisp, the OSS and commercial implementations had diverged quite a bit, each providing their own way for network, SQL, etc. Nowadays, there are lots of libraries out there for these things that are getting ported between all the implementations, AND critical features of other languages are finding their way back into Lisp via these libraries.

Right now if you wanted to you could write a Lisp program that used TCP/IP (+ FTP/SMTP/HTTP/etc.), threads, SQL, regexps, windowing, XML, and crypto, AND deploy this as a webapp in either a standalone Lisp server or behind an Apache server. However, the libraries are still separate pieces that you have to download and incorporate, and the documentation is not yet at the point that with a single book you can be guided through all this (unlike Java , .Net, and Python where almost any 400-page tome would cover it all in some respect). But it's getting there.

Competition? Progress?

[maccam94]

This isn't necessarily good for the processor market, because it makes everyone stick to the same standards, even if they're ineffiecient. Oh cool, Company X has designed a processor with a cool new feature that will make programs wayyyyy faster! Oh wait, there's that darn high level language, too bad it'll never be used. Of course, it may be beneficial, because people's progress would be channeled into one direction, however this is only useful for so long, before true innovation almost comes to a standstill.

Just my $0.02.

Re:Competition? Progress?

[Kohath]

Oh cool, Company X has designed a processor with a cool new feature that will make programs wayyyyy faster! Oh wait, there's that darn high level language, too bad it'll never be used.

The opposite is the real situation.

The interpreters (JIT compliers, or whatever) are "wayyyyy" more sophisticated than 99.9% of programs. If any piece of software is going to use a cool new processor feature, it's one of these interpreters.

In fact, since the interpreter knows about the cool new feature and the original programmer didn't (because the chip came out after programmer wrote the code), the interpreter is, in fact, the key to getting this feature exploited by the maximum amount of software.

Re:What?!?!?

[tomhudson]

The problem with the VM startup time is that a lot of code nowadays is "glue code". A small app starts up, shells out to another one to do a task, takes the returned data, shells out to another one .... all those new VMs get expensive.

the workaround is worse - 1 VM that starts up and never quits, just hosting each new process. In other words, 1 bad process can now bring all the processes down, so you have to add even MORE code to check that's not happening. Sychronize is already hugely expensive in Java ... this will add a whole new layer of "things to check between code points". The speed gains won't materialize, as the checking that has to be done increases faster than N+1.

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:Embedded Platforms

[Waffle Iron]

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.

Now that doesn't make much sense to me. Someone somewhere has to do the hard work to certify the high-level language, but that's largely a one-time effort. It seems to me that it would then be much easier to certify each new project that gets written in the safer high-level language than to prove that a bunch of random new C an assembler code is bug-free for every distinct project. It probably wouldn't require a heavyweight VM to achieve this either; a safety-oriented compiled language along the lines of D would probably allow for more streamlined development on low-powered hardware.

Re:Embedded Platforms

[AJWM]

Avionics? And you're not coding anything in Ada?

Hmm... I call BS.

Re:Embedded Platforms

[amorsen]

What if a gamma ray causes a single bit event changing a function pointer mid-flight? ECC RAM only gets you so far.

It could just as easily turn a valid index into an invalid index, so avoiding pointers is not enough. Besides, most cpu architectures don't have indexed instructions, so you end up with pointers anyway.

Re:Embedded Platforms

[afroborg]

Avionics != Military

There are a LOT of civilian aircraft

Re:Embedded Platforms

[AJWM]

There are a LOT of civilian aircraft

Yes there are. And Ada != Military either. Sure, the DOD paid for the design of Ada and mandates it in many embedded systems, but plenty of other outfits (including non-US) use it where its characteristics (maintainability, reliability, verifiability) are desireable -- such as in avionics.

True, DO-178B doesn't mandate use of Ada or validation tools like SPARK, and there is some commercial off-the-shelf software that meets DO-178B that's not written in Ada (although that tends to be more at the OS level than at the application level), I just find it surprising that anyone could work in that field without ever touching Ada.

Heck, not that long ago (hmm, seven years, maybe it was that long ago) I had do deal with a team of programmers working on a highway traffic management system whose C++ was rusty to non-existent because they'd just come off a (non-Military) Ada project.

Let lose the dogs of war....

[otis wildflower]

... there's no time to loose!

(or is that "there's No-Time Toulouse!")

Layers of Indirection...

[LordZardoz]

The one edge that naitve code will always have over interpreted code is that naitive code can just be loaded and fed to the CPU. An added concern is that most comptuers are doing more than one thing at a time. If all the CPU had to do was interpret one program and run it, that would be one thing. But if the CPU is trying to run 5 or 12 apps, and it has to interpret more than one of them, then there will be a bit of a logjam.

END COMMUNICATION

Re:What?!?!?

[Kethinov]

Amarok is native, but still hideously slow (and crashes a lot). Bashee is a C#/Mono app. Quod Libet, another good example, is a Python app. Point is, a lot of modern media apps are written with features but not performance in mind, and many of them are done in interpreted languages. The kings of all music apps, iTunes and Winamp (or XMMS for Linux) do not suffer from the said performance problems.

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.

Embedded?

[tepples]

Write in an interpreted language, but be ready to dive into native code when the need for speed arises.

OK, I'm developing for an 8-bit NOAC (6502 based) microcontroller clocked at 1.8 MHz. Does the need for speed arise here?

Re:What?!?!?

[chris_eineke]

Eh, sorry. Assembler is as beautiful as truck diesel engine. Raw horsepower, but rather useless in a Ferrari. If you want to see a beautiful programming language, how about one that allows one to express code as data?

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:It depends

[paulzeye]

...who cares? Is that guy's time worth more, or is the programmer's time worth more?

I think you are messing up this question. There is not one programmer for each guy out there writing macros. Once the software is written the number of people who can use it is unlimited. For that matter it can be used an unlimited number of times. The right question would factor in the number of users and expected lifespan of the software. If you are talking about Microsoft Word users, that is a lot of users. You are on the right track, but I think this is an important detail.

Re:It depends

[Vexorian]

Let's say we have a very complex operation that involves calling "instantaneous" calculations a couple of trillions of times.

Now compare 2 trillions of instantaneous with 20 trillions of instantaneous.

Also Programmer lazyness is not a good excuse

Re:It depends

[DamnStupidElf]

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

Even if it is a constant factor (which isn't always true, consider tree lookups (log n) for variable names, etc.), the constant factors multiply. One loop that takes 1.1 times as long as compiled code isn't bad. A three deep nested loop that calls five functions deep to convert each element it processes takes 1.1^8=2.14 times as long. A 10% overhead is generous for a lot of interpreted languages, and a maximum depth of 5 function calls within loops probably covers toy problems only. Remember that many functions that applications call are library functions implemented in the interpreted language, calling other interpreted functions around wrappers to native code at some depth

The real question is: who cares? Is that guy's time worth more, or is the programmer's time worth more?

If it would take a programmer 1 week to make the macro processor twice as fast, it only takes 200 users wasting 1% of their time 1 week to make it worth it for the programmer. That's assuming that programmers and users have equally valuable time. Even if programmers are worth 10 times as much as users (perhaps more realistic in salaray), it only takes 2000 users at the same percentage to make it worth the programmer's time. Of course, the *optimal* solution is to make the users learn how to program in native code, making everyone hundreds of times more efficient at minimal cost...

Re:It depends

[EvanED]

IIRC anything less than about 250 ms *seems* instantatneous.

I've always heard the magic number is 1/10 s, not 1/4. And I'm much more inclined to go with the 1/10 of a second from my uses of computers. (*Thinks of some piss-poor Swing apps*)

Re:It depends

[wkitchen]

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? The real question is: who cares? Is that guy's time worth more, or is the programmer's time worth more?

It's always a balance between the two, of course. It obviously makes sense to use the quick to develop but slow to run tools and techniques when the application will be used so few times that shorter run time can never offset the greater development time (and subsequent maintenance) of a "hand built" version. I think everyone here understands that, and I certainly don't disagree with it.

But still, I think that gets used too often as an excuse to take the quick-n-easy way when it really isn't justified, or when it's justified in the short term but leads to an accumulation of bloat and cruft the long term. The thing is, in a philosophical "big picture" way, that guy watching the hourglass while waiting for the macro to finish is the one who's time is worth more. Why? Because saving that guy's time is what justifies the existence of all of this computing technology in the first place.

When I look at modern OS's, GUI's, and high-level development tools compared to much simpler technology from a couple of decades ago, I do marvel at the advancement. And I do marvel at how applications that would have been impossibly complex back then can now be brought into existence with great speed and ease by using high level tools and by putting together and customizing libraries/modules/etc. that have already been developed. Applications that then would have been completely impractical because the development cost would have exceeded the benefit, are now commonplace, and collectively very beneficial.

And yet, I still can't look at all of this without a sense that something has gone horribly wrong. Abstractions built on abstractions built on abstractions. So many layers of abstraction that the correlation between a program and what the underlying machine actually does to execute it is an unfathomable mystery even to the one creating the program. So many layers of abstraction that simple programs that 25 years ago occupied only a few KB and ran on bare hardware with no OS now need MB's of runtimes or VM's, which in turn operate within a software environment (think OS, GUI, and drivers) consisting of hundreds of megabytes on disk and potentially 10's of mb's resident in RAM. There's something really sick about that.

Re:It depends

[Rakshasa Taisab]

Only those CS students that didn't pay attention during class would think constant factors didn't matter. If we assume N is sufficiently large for the algorithms we analyze, the coefficient does not matter only when the order of the expressions are _different_.

As we are running the same algorithm with different coefficients for the (shared) highest order term, it is not correct to say such things do not matter.

Re:What?!?!?

[Eideewt]

You got your car analogy backwards. Assembler is like a Ferrari: it's fast, but hard to get work done with. Other languages are like the diesel truck: they're slower, but their power lets you get stuff done.

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.

Psht...always both

[TyrainDreams]

Chances are there will always be both...the only one that can die is interpretters... Heres some reason why: -You cant write an operating system in an interpretted language... -There are some things you can only do in a native language, and interpretted language have the easy portability thing going on for them... -Interpretters have been around for a long time and they arnt going to go away any time soon You cant think native code is going to be dead just because someone makes a popular interpretter...there are just some things an interpretter cant do... Besides, ASM is so awesome who would ever want it to go away...:P

Re:Psht...always both

[cryptoluddite]

These people would beg to get the credit they deserve: http://jxos.org/.

Micosoft Research can't credit this as their inspiration because of the four-letter word (ie Java).

Those AI problems are not CPU-bound

[patio11]

Most AI problems are not a matter of "well, if we just had bigger/more efficient iron this would be easy". For example, I don't care whether you have a beowulf cluster of Crays, you still aren't going to be able to run magic against a corpus of English words and be able to search by concepts. You need to be able to actually implement the magic -- thats the whole trick in AI. In fact, the cynical might say that AI is a field composed of all the problems for which the solution is still magic -- every time we find a problem class which is actually algorithmically solvable (or close enough) it tends to drop out of "AI" (see: credit card fraud checking algorithms, "Search isn't AI, its just PageRank!", simulated annealing and similar techniques in some problem spaces, etc etc).

Anyhow, you give me the magic for, e.g, parsing natural language and I guarantee you that even if you take a 20% performance hit for running the magic in Java instead of assembly it won't matter as I can always buy more iron and if your magic actually does what you say it does I'll have money to spare.

Re:Those AI problems are not CPU-bound

[mangu]

A sufficiently advanced CPU is indistinguishable from intelligence. Google for "periplaneta computatrix" or "deep blue", or check Randall Beer's site if you have any doubt.

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.

Re:My head's going to explode!!!!!!

[techno-vampire]

People who use "loose" when they mean "lose" are real luusers, aren't they?

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

[bakes]

By what metric?

Flavour, obviously. And nutritional content. Oh, and presentation.

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

Re:Analogies suck, but...

[rufty_tufty]

You mean like the chef programming language?
http://en.wikipedia.org/wiki/Chef_programming_lang uage

Re:Analogies suck, but...

[Abcd1234]

You're absolutely right. Of course, given that the GP said "But C is like a fully equipped kitchen ... the results are incomparably better", I'm not sure what your point is...

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:If we all quit using native languages....

[Haeleth]

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?

Bootstrapping!

As we all know, JIT technology is magic: with a JIT, you can deliberately write your code as inefficiently as possible and it will still run faster than the most finely-tuned hand-crafted assembly language imaginable, which is why (for example) the entire Linux kernel was recently reimplemented in Ruby, and tests of this on a 12 MHz 286 show it regularly outperforming experimental military quantum computers in several cryptographic benchmarks.

So, all we have to do is run a JIT recursively, and it will optimise itself, growing exponentially faster!

I reckon this technology will be with us in about 10 years. Just in time to power the navigation systems of your flying car.

History repeating itself - UCSD Pascal

[rbrandis]

Does anyone remember USCD UCSD P-SYSTEM?

The time is now

[mario contestabile]

The sun/microsoft handling of Java and Java standards did nothing to help its adoption.

Yet, it seems Java is one of the most used languages.
This web site, http://www.tiobe.com/index.htm?tiobe_index (seems to be in netherlands and uses search engines to calculate the ratings) lists:

1- Java 21%
2- C 18%
3- C++ 10%

I use C++, and although that's x-platform, its usage is Windows specific (COM, ATL, etc). That's because I don't need a Mac/Linux version of my software. IFF I did, I'd have to either

- manage my C++ abstractions more carefull to avoid os dependencies
- use Java
- Dare I say it, .net/mono

If I had to make some crystal ball 4 year look ahead, I'd say the MS os dominance will increase the use of JIT languages, especially with the runtimes being included in the os (Vista).

C++/CLI, there.

Re:The time is now

[MassEnergySpaceTime]

Interesting chart. I wonder why Java experienced such a sharp drop at around Feb 2004. That also seems to be the same time that Pyton and Delphi took a increase.

Re:My head's going to explode!!!!!!

[ConceptJunkie]

You know, you try to be patient. After all, a lot of people are not native English speakers, but this "loose" thing has become extremely common, and it's only been in the last two years or so. I've been seeing "alot" and "rediculous" all my life, but the "loose" thing is some kind of evil meme-virus which is spreading because, and this is the only reason I can imagine, the people who spread it don't read anything that's not written by some other semi-literate luser on the Internet.

I'm hardly the most well-read person on the planet, but the general level of spelling and grammar around places like /. and digg is ridiculous. The scary thing is that I would imagine a high proportion of these kinds of folks, being computer nerds and all, are reasonably well-educated, yet they still write like Mrs. Tuberglotter's 6th grade remedial reading class.

Re:What?!?!?

[tomhudson]

1. Write it in c
2. Embed optimizations in c function calls
3. If really anal, replace all the function calls with macros to call each routine directly.

After all, once you've completed step 2, you more than 95% there anyway ...

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:On the subject of lUSians

[Wingit]

I think they might have meant USians as apposed the the THEMians.

Just my thoughts as i wing it through this world. Don't give them too much credit.

beating dead horse

[binford2k]

loosing != losing

Re:What?!?!?

[dgatwood]

Native code isn't dead. It's just that all the native compiled languages have failed to keep up with much-needed language features for web development purposes and have shown a serious lack of resiliency in the face of security attacks.

C is a lot easier to debug, is dramatically faster, and gives the developer a lot more control over memory allocations, which can result in orders of magnitude performance improvement when you start running into paging stress from poor garbage collection in Perl or PHP. Sadly, all those benefits are only helpful if you don't have to spend days debugging some buffer overflow bug. or trying to figure out why some random function in a library that will remain nameless returns NULL out of the blue (with no error codes).

I'd go so far as to say that if it weren't practically impossible to write good CGI code in C, we'd see PHP and Perl use on web servers drop off substantially. Right now, string processing in C is fragile. It's far too easy to make mistakes and end up with security holes due to buffer overflows. Also, C completely lacks any clean mechanisms for doing variably-sized arrays, in-memory hash tables (as opposed to hash(3) for database files), etc. in the language. You can extend C++ to support these things, but AFAICT, there isn't really a language standard in place for them.

I would love to see a nice, clean standard set of variable-length string and associative array libraries with these features:

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

If I could find such a thing, I'd probably still write all my CGI programs in C instead of only writing the most performance-critical pieces in C. As it stands, it's enough of a pain to make C CGI code work correctly that it isn't worth the trouble for me, and so I suffer the performance hit (generally of PHP).

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

SDRAM without arrow smashing?

[tepples]

Add RAM.

Is PC133 SDRAM still available for purchase at a reasonable price? Or should I buy a whole new computer instead in order to take advantage of various flavors of DDR SDRAM?

anti-virus, anti-spyware, firewall, and multitudes of Microsoft 'improved user experience' crap are usually running.

I don't run real-time anti-virus or anti-spyware. I start the periodic check and then go eat dinner, and I use safe hex methods (including Mozilla technology and a NETGEAR firewall router) to not get infected in the first place.

Re:SDRAM without arrow smashing?

[bladesjester]

http://www.newegg.com/Product/Product.asp?Item=N82 E16820159006

I would have also looked on geeks.com, but it's down for scheduled maintinance at the moment.

Re:SDRAM without arrow smashing?

[ak3ldama]

512MB of RAM should get you by. I have run java on Windows 2000 boxes (and others) with that much and it's ok. But definitely upgrade to 1.5

System programming

[rlp]

These days I program mostly in Java / C# with occasional quick-n-dirties in PHP. However, for system programming you'd want something low-level like C (or even assembly). For an OS, compilers, assemblers, drivers, or anything real-time you'd want a non-interpreted language. Same goes for the interpeter (like a JVM) or a JIT.

And before you say hardware support for interpreted language - do a quick search on Japan's fifth generation project.

Video/FX/image processing: nope

[SilentTristero]

HD video (1920x1080, rgb, 30fps) is 186 megabytes per second. Processing that with an interpreted or even JIT language is going to be many orders of magnitude slower than hand-coded C, or GPGPU, or whatever the flavor of the month is. Yes python and ruby are super productive. But my time writing the code is only spent once; the poor schmucks out there using it will be using it every day for years.

People doing HD postproduction really care about every cycle per pixel because the factors are so large: if you can turn a overnight render into a lunch-hour one, or lunch hour into a coffee break, or coffee break into near real time, that matters a lot. That time to the video guy is what the edit-compile-debug loop cycle time is to the programmer.

--ST

Re:Video/FX/image processing: nope

[cryptoluddite]

Video codecs are rarely written in C though, mostly the core parts of them are written in assembly. That's one reason why you don't see many ports to Power for instance. Generally excellent performance is not whether the language is JIT compiled or ahead-of-time compiled, it's whether the language is safe or not (ie can you turn safety features off). For instance turn off type checking, errors, exceptions, etc on lisp code and you wouldn't believe how fast it is.

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.

No but I think we may have an intermediary

[Sycraft-fu]

I think things may start going the way MS is pushing with C#: Managed apps with unmanaged parts. I mean after all, is a UI really going to get much faster in native code than the .NET runtime? Even if it is, would you notice? Ok so code the UI part all in a managed environment. Then, code the time critical stuff in a language that compiles natively and hook the two together (VS does a great job with this). You get the speed where you need it, but the advantage of easy coding for most of the project.

I could see that becomming popular.

Re:No but I think we may have an intermediary

[gbjbaanb]

God, that is the ideal. I used to do that on Windows years ago - VB wrote the client GUI, C++ on the server (and of course, SQL on the DB...) . Fantastic results from that programming model, and you got to use different developer's skills where they made the most difference.

I strongly recommend this development model, not only is is good from a people perspective, and efficient in a best-tool-for-the-job perspective, it also has the massive business perspective of reduces risk in updating apps to the next generation (imagine if you had one of my VB->C++ apps, want a thin client version? easy, replace the VB and you're set to go, no issues with a whole new server that needs coding)

Re:What?!?!?

[NemosomeN]

No, just the factor of 200 can't possibly be attributed to only one factor.

Re:What?!?!?

[tomhudson]

I've got to admit I find the current methods of handling web server code to be a screw-up.

Either have a runtime VM and create a new context for the classes, load your classes into the VM, and dump it all on each page call, or have a module and initialize it for each page, load and initialialize your script, run it, and dump it on each call.

Still, it can't be any worse than my old c cgi routines ... server runs the cgi, cgi reads from stdin, performs the work, writes to stdout, server passes stdout to the client machine ...

I didn't bother benchmarking, but it just seemed faster (the routines to access mysql in c aren't that hard to figure out, and you can test the whole thing from the command line, just like any other cgi). Maybe that'll be a project for a weekend.

Re:What?!?!?

[hackstraw]

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

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

I'm not sure how funny vs serious you're trying to be, but slashdot uses mod_perl which only needs to compile the scripts once, and then runs them very fast after that. Kinda like fastcgi, but I haven't heard of fastcgi in quite a while.

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

[mypalmike]

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.

Assembler isn't slower than machine code. The two are isomorphic.

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.

Native Code Optimizations/Features

[David the Great]

You cannot hope to have interpreted code running on different architectures with the hope that it runs indentically on each architecture. The point is that native code (and programmers writing such code) take advantage of architecture specific features.

For example, look at the floating point unit on the x86 architecture. It supports 4 kinds of rounding modes (round to nearest even, round to positive infinity, round to negative infinity, round to zero).
If someone were writing a scientific application, the possibility that he needs to change the rounding mode of the CPU could arise for various reasons. Such a task is simple in languages such as C.

Java however does not support any rounding mode other than round to nearest even. The reason for this is that some architectures do not support multiple rounding modes (that may be false, since the rounding modes are part of the floating point standard, and any architecture that supports floating point *should* support them), and therefore supporting architecture specific code would make it not portable, defeating the purpose altogether.

Re:Native Code Optimizations/Features

[cryptoluddite]

Java has StrictMath and corresponding strictfp class/method modifier for using the ieee standard floating point rather than the cpu's flavor. It doesn't let you change the rounding mode explicitly, but then again neither does C.

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:PHP vs ASP vs C++ vs JavaScript

[zerosix]

If it's taking you 4X longer to write C++ code you don't know how to program with C++. Maybe not you specifically but my point is that your costs are dependant on your coders knowledge. Don't hire a Java programmer to write C code and vise-versa. While I know how to program in Java it's not my strong point and I would rather program in C++.

And don't tell me, "But GUI's take a lot of time." There are many development enviroments out there that aid in the Rapid development of interfaces.

To say that C++ takes longer to write pure is ignorance.

Re:PHP vs ASP vs C++ vs JavaScript

[linuxrocks123]

> I can't think of many applications that wouldn't benefit from being 4 to 12 times faster.

Then you don't have a very good imagination. User interface code is often instantaneous on modern processors. There's no reason to make that code more instantaneous.

Re:What?!?!?

[atrus]

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

And no, the STL does not suck.

Why VMs at all?

[rand_chars]

In my opinion, the real advantage to bytecode is nothing more than ease of distribution. With bytecode and virtual machines, you don't need to worry that one of your boxen is a Mips processor, another one is running a Sparc, and the gaggle of other boxen are x86es. It also allows for much easier sandboxing. However, Bytecode loses a fair amount of speed, slows down loading time, gives no extra amounts of safety, and is, in general, compiled while it's running anyways (Just In Time compilation). Additionally, for most applications (not applets), sandboxing is disabled. The runtime checks may just as well be inserted into assembly code directly, rather than checked by a virtual machine. Even binary code can be created during runtime and executed from compiled code (well, unless you enabled W^X in the OS, in which case a VM is a way of cheating and working around that security). As a matter of fact, this "generated code" method is used from within Gnu C for closures (nested functions that can reference the enclosing scope). In my opinion, any program tied to a single machine for most of it's life (eg: something that would run on Windows .NET) should probably be compliled, since there is absolutely no advantage to a virtual machine. For things like Java applets, I can see a purpose.

Re:Why VMs at all?

[Tony Hoyle]

Interpreted code is only a tool. You have to avoid machine specific dependencies - I've seen huge Java projects that required Windows boxes (and IE6) to run for example (and of course Java changes with each release so JDK 1.3 code often won't run on JDK 1.4 for example).

OTOH I have a C++ app that compiles unchanged to 9 different architectures. It's all down to the design and how you handle the OS specific stuff. With good design you can avoid the cross platform issues.

IMO it's not about cross platform (although there's always the issue of availability - .NET is basically Windows only and even Java is not available for most of the platforms that I port too) it's about speed of development vs. speed of execution.

If you want to save the energy

[obizgnodnahs]

now native code must execute a small fraction of instruction numbers for the same task. Less instructions means less energy. As hardware vendors strive to lower the chip power, the pressure to cut energy bill may one day fall to the shoulder of software guys.

90 / 10

[tm2b]

Remember the 90/10 rule - your application will probably spend 90% of its time in 10% of the code.

Once interpretters are fast enough for UIs to be first class, it makes sense to take a hybrid approach. Implement functionality in the interpretted lanugage and then override that critical 10% of the code (or whereever your critical execution path is) with native versions.

Re:90 / 10

[Junks Jerzey]

Remember the 90/10 rule - your application will probably spend 90% of its time in 10% of the code.

This is true for many types of applications, but not all. In high-performance apps it's not at all unusual to have a flat profile.

Vista Memory Requirements

[TwilightSentry]

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

Well, of course Vista uses more power than any one interprited language! After all, it's written in C# running in an interpriter written in Visual Basic 6 running in a copy of Windows ME on an 8088 emulator written in Smalltalk using the old Alto runtime in an Alto emulator on a PDP-11 emulator running a port of Exec-8. The PDP-11 emulator is written in an analgram of Java and QBASIC on UAE. And, of couse, the base system on which UAE runs is Xenix with the Microsoft Bob enhancement pack.

Re:Vista Memory Requirements

[Nefarious Wheel]

... it's written in C# running in an interpriter written in Visual Basic 6 running in a copy of Windows ME on an 8088 emulator written in Smalltalk using the old Alto runtime in an Alto emulator on a PDP-11 emulator running a port of Exec-8. The PDP-11 emulator is written in an analgram of Java and QBASIC on UAE. And, of couse, the base system on which UAE runs is Xenix with the Microsoft Bob enhancement pack.

Hang on, I think you skipped the VMS/BLISS/DCL steps.

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.

Re:My head's going to explode!!!!!!

[Nefarious Wheel]

Hey, I learned a lot in Mrs. Tuberglotter's 6th grade remedial reading class! I liked it so much I took it three times.

Proportionality, if that is a word.

[frickendevil]

Although Interpreted languages are running faster then ever, this is proportional to the speed of native languages, which are inherently faster by nature.

By the end however, if EVERYTHING turns into interpreted people will no longer whinge that they need to find the version for their OS, they have to go off and download the interpreter the developer decided to use, make sure its up to date, and make sure they get the one for their os (because an interpreted interpreter would be slow). You could say that once you have all the interpreters you dont need to worry, but do you??? You need to keep them updated, you now get bugs in the programs you use AND in the interpreter it uses, etc.

Yes i know interpreted languges are useful, but they will never fully replace native coding.

Re:System programming (Well, maybe not!)

[hermango]

Back in the days of MS-DOS and 5Mhz 8088 CPU's with 640M of memory Advanced Voice, the company I worked for, ran an 8 port voice mail on an XT and it worked just fine. Matter of fact, when the ultra-fast 8Mhz and 12Mhz 80286's came out we ran a 24 port voice mail that worked great. The interesting thing is that every one else was trying to run C-coded voice mails, and struggling like hell to get them to work, our stuff just chugged along like the Energizer Bunny. And what was it programmed in? PC-Bus, aka Datapoint's Databus, an intrepreted database language. The actual source code is compiled into bytecode, which is intrepreted by a runtime interpreter. Note that 1CTI, the company that now uses that code, still runs it and it's evolved additions, except they're now compiled/run using the Sunbelt PL/B compiler/interpreter. Note that there are two versions, one for Windows and one for Linux. The basic code is the same, the difference being one uses Windows calls for some specialized stuff and the other uses Linux calls. Other than that, the code is the same. FYI, the code is an event-driven single-thread state machine.

Code Close to Hardware, Number Crunching

[Soong]

The first will always have to be native. It just has to be.

The second will be for a while yet. Any performance demanding app will still care about the blah-percent overhead. Last I checked, my JVM only gets half the megaflops of native code. I want to skip that 50% overhead.

I'm guessing that getting a lot of that overhead back will come from moving from just-in-time compilation to install compilation that can take longer and do more optimizations.

Re:What?!?!?

[exp(pi*sqrt(163))]

15 years ago, 3D graphics on a computer was unheard of

Dude! What are you talking about?

Marketing, perception, and scalability

[Morty]

Lots of people are debating the technical merits of interpreted vs. compiled performance. But the technical reality isn't what drives success. Perception and marketing often matter more.

There is a common belief in the market that native code runs somewhat faster than interpreted code. This means that a product that is native is perceived to run faster than a product that is interpreted, on the same hardware. Is this true? Maybe, maybe not. But so long as people believe this to be true, c-level people making strategic decisions will pick platforms based on their ability to market the product. While there are plenty of times when a product is sold to run on an overpowered systems, there are always customers who want to scale a product to the point where performance is an issue, or who want to be able to scale the product; such customers will shop on performance, and native vs. interpreted can be an issue.

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?

Emulation is a good reason for native code

[iMouse]

Being a long-standing member of the computer/console emulation community, I have seen many applications written in native code and some in other languages such as Java. If applications such as these are rewritten in non-native forms, we are looking at the emulation community taking a HUGE hit no matter how fast processors get. The whole point of emulation is the fine balance between compatibility and performance. Programmers who are looking to emulate processor intensive devices are going to use machine code, most likely assembler, to make their creation worthwhile to the average user. Not everyone will have a top-of-the-line processor every year one is released. Some programmers in the emulation world have opted for exact cycle emulation which is already a huge exchange of performance for compatibility. Coding this type of application in non-native form would make demands on the processor increase, causing an energy-saving processor to use more electricity to run an application. While this may not seem to be a concern of an individual, it would actually cost a business with multiple computing units more money in energy usage over the course of a year or so. Some businesses do use emulation technologies in a lot of areas; not all are emulated on hardware expansion devices either.

it depends

[ayounge]

It simply depends on what you are doing. If your talking about whipping up a quick app on your pc that isnt very CPU intensive, then why not use an interpreted language of some sort? save yourself the headache.

but at the same time, if your writing code that handles a massive database or a butload of connections every minute, then every bit of performance matters and your probably going to want to get down and dirty w/ C code.

it also depends on what interpreted language we are talking about. From what i have seen, Java under the right conditions can perform just about as fast as any C++ code, but if your talking about python (as much as i love python) you can kiss any real performance goodbye.

: in the end, never will be a blanket programming language for every application. When designing your application, take a look at what your domain is and from there find out which language best fits your needs. It really is as simple as that.

Re:What?!?!?

[Fordiman]

Yeah. I used google spreadsheets. Very complete. And very slow. I'll stick to KSpread, thank you.

Re:What?!?!?

[Fordiman]

I'm going to have to agree with you there.

I can, for example, do some amazing things with little more than Javascript and a little hunklet of CSS - but I wouldn't try to write encryption with it (I tried it a while ago, actually; creating a 128 bit key took a few MINUTES).

And to be honest, Javascript is not good for complex interfaces; Check out http://www.fordi.org/comics and see what I mean. That little expandy bar NEEDS at least 1.5GHz of power to be usable.

Which runtime?

[GrouchoMarx]

There's another performance issue you're forgetting: Multiple runtimes.

Sure, well-written Java with the right non-Swing toolkit can be quite nice. Python can do wonderful things. PHP runs mission-critical aviation systems that get zillions of hits. .NET makes Windows development not suck. Even Javascript will be useful as a desktop language come KDE 4. And all will run on reasonably modern hardware rather well.

Now try running all of them at once.

Now you have the Java runtime, and the .NET runtime, and a Python runtime, and Mozilla's XUL runtime all sitting in memory at once, each running one or two programs. That "reasonably modern" computer if yours is now not quite so spiffy, is it?

Of course, MS's answer is "well just do it all in .NET". Sun's is "just do it all in Java". The open source world is largely ignoring the question entirely. :-)

That said, I do believe that "managed language" programs are the future. There are entire classes of bug and security hole that simply cannot exist in a language where you aren't futzing with memory directly (C/C++). I don't believe it's even possible to write a buffer overflow in Python or PHP (not sure about the others). The runtime, yes, but that's written once. You pay a cost for that, but in the long run it is a worthwhile cost.

Qt is about the only non-managed system I'd want to even think about coding for on the desktop or server. Handhelds and embedded systems, though, are an entirely different animal.

It's not native or interpreted; it's the ratio

[rockrat]

As other posters have noted, many large applications can now be written in a combination of native and interpreted code. Web apps are a classic example, but in our neurophysiology lab, we're just completing a new data acquisition system that does real-time data acquisition from several types of A/D converters at up to 20kHz, writing all data to an SQLite database. The system is written on OS X and the combination of Objective-C and Python with PyObjC has let us pick at will between native and interpreted code. The real-time loop at the core of the system is written in C, the more stable parts of the system are written in Objective-C (along with the Cocoa framework, the most productive language/framework combo I've ever used for desktop apps) and the more quickly changing aspects of the system are written in Python and wrapped as OS X bundles by py2app. Our users are physiology researchers and they can now write code in python to customize the operation, including stimulus generation and experimental protocol; they don't need to ever touch native code. Development was a breeze and the users' productivity in changing the setup between experiments has increased as well.

Adding to the mix, most of our users do their data analysis in Matlab (another interpreted language). We've written a set of Matlab MEX files (loadable libraries that allow native code to be called from within the Matlab environment) with a similar scheme (a mix of Objective-C and PyObjC) to allow users to retrieve data from the SQLite database.

So the original poster's question could more accurately be summed up as, what ratio of native versus interpreted code is best for your application? The next question is not whether native or interpreted code is coming or going, but what each is going to do to make integratino of the two easier.

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:It's a name, not an adjective.

[Altrag]

I tend to prefer U-S-er myself ;)
*waits to burn*

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

[moranar]

You might want to read the Wikipedia definition for Continent and then meditate on why that appropriation of the term "American" doesn't exactly endear you to Latin-americans. We've grown thinking that America is one continent. Since a definition of Continent is "a large continuous landmass", I see no reason to consider all of the American continent as a continent on its own.

If you add to this the various nationalistic-colonialistic disputes ant troubles between the USA and Latin-american countries in the past two centuries, you'll see how you people aren't exactly loved there. Trying to deny us the word "America" based on string parsing isn't improving things.

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

[marcello_dl]

So we got an America located into a larger place called North America that finds itself north of a place called South America? Sorry, it seems to me a made-up excuse to justify being the true and only "americans" in the continent.
Not that I accuse you, it might be what they teach you in school.

But don't invoke computer people :D Computer people, see one place called North America, one South America, and one called U.S. of America, and conclude that America is the big continent. South being part of the name instead of a specifier makes sense just as a lame excuse, IMHO.

Mr Amerigo Vespucci, the guy from whom the America name comes from (America, not Americas which i guess was a clever way to resolve the name clash between US and the continent), understood it was a new continent. And he was exploring South America. So there's not much of an historical reason for US to exclusively claim the America term, too.

The reason why people of the world hear "America" and think "USA" has probably something to do a little with US Army and a lot with Hollywood.

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

[rjshields]

Except that "South America" != "America"

By the same stroke, "USA" != "America". USA is just a country in North America. America refers to the whole of North and South America as I understand it.

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

[dmayle]

My Quebecois friends insist on the term États-Unisiens. (United-Statesians)

The problem is that your Quebecois friend would be wrong, and his arrogant decision to rename Americans would be confusing, as United-Statesiens might be from Mexico or the US of A. (Mexico is Estados Unidos Mexicanos which means the United States of Mexico in Spanish. [Source: Wikipedia) The fact of the matter is that the United States of America is the only country on either of the two American continents with "America" in it's name, and it is the only part of the name which is not shared with another country on the continet. Hence, Americans from the United States of America, and Mexicans from the United States of Mexico.

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

[hey!]

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.

Ummm, but that's not the way natural language works.

In natural language, a word can take multiple meanings. A "jack" can be a tool you use changing a tire, or a the lowest value face card in a standard playing card deck. Human beings don't get confused because unlike computers we're exquisitely good at picking out meaning from context. At least those of us who don't gravitate to working with computers for a living.

It's only natural in that case that residents of the USA think of themselves as "Americans". And it's only natural that Canadians, for example, resent this. Not because they want to be called "Americans", but because the complete lack of ambiguity from the US perspective in referring to themselves as "Americans" suggests that for practical purposes Canada doesn't exist in their mindset, whereas the USA looms large in the Canadian mindset.

You could write a tolerable soap opera using characters based on the the countries in the NAFTA. The USA would be the loud, brash, high flying salesman brother who likes to flash his Rolex while he slaps you on the back but is losing control of his secret drinking problem; and he's a mean drunk. Canada would be the younger, co-dependent one who keeps trying to do the right thing but is secretly seething with rage because no matter what he does his bigger brother hogs all the attention. "Hey, look at the robot arm I made!" he says, and he can't even get his older brother to notice, or if USA does, USA will will either dismiss it as no big deal or be unsufferably patronizing about it. Mexico is the brother who perhaps had the most potential of all, but keeps squandering it on booze and whores.

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

[gronofer]

This still leaves "American" as ambiguous, since it can apply equally to the United States of America or to America (the continents).

I suppose the longer version "United States American" could be used if there's scope for confusion.

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

[xtracto]

Sorry pal but for us the Mexicanos, the people from USA are called "Estadounidenses" which is quite the same thing as what the Quebecois guys called them.

The problem is that the USA is the only country that does not have a common name. The political name of Mexico is "Mexican United States", and the common name is Mexico, same with Canada, England, and all (that I know) countries in the world.

Whereas USA is the "common name" for United States of America, named after Americo Bespusio(Amerigo Vespucci), the cartographer to which America (the contintent that then became 2 contintents [althought that is not what they tell us in Mexican schools, where they take America as a complete continent]) owes its name. The United States part is just a descriptive adjective. Unfortunately, there are more than one United States in America now (even in North America), so the lack of name is what gives problems to the Estadounidenses.

But that is only a problem in the English language, as in Spanish, French and German (Vereinigten Staatler). Of course there are several other pejorative names that come to mind lingo Gringo, yanqui and polaco.

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

[pete_norm]

My Quebecois friends insist on the term États-Unisiens.

Being from Québec, i can confirm that he's probably alone in the province to use that word. États-Uniens is used by the "intellectual" leftist that think it's cool to bash on the USA. But that's at most 5% of the population. The other 94.9999% of the province don't really give a damn about it and say "Americains", like it's always been.

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

[SQLGuru]

"You US citizens really think you're the center of the universe. Your stupid comment proves that." Proof that *I* am the center of the universe: The center is defined as the point that is equidistant from opposing edges for all edges (or, from Dictionary.com: A point or place that is equally distant from the sides or outer boundaries of something; the middle: the center of a stage) It is widely understood that the universe is infinite. To my left, the universe extends infintely. To my right, the universe extends infinitely. Above me, below me. In any direction I look, there is infinite universe. Since I am equidistant from all points of the universe, I must be at it's center. QED Layne

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

[jo44]

I find it funny that you consider North and South America to be a single continent, but that you consider Europe and Asia to be two, considering how much more "attached" Europe is to Asia.

I realize there is some difference of opinion on what the continents of the world are, and that some consider Eurasia to be one continent. Though I don't imagine that is a popular view.

Being Canadian, I dislike the appropriation of America as well. Although I refer to the citizen of the U.S. as Americans (for lack of a better term), I *never* refer to the country as America. Frankly, I don't know anyone (here) who does. I usually refer to the country as the U.S. or "the States".

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

[yankpop]

As a Canadian I am most certainly not an 'American', although I am a 'North American'. I've never had a conversation with another Canadian who would use the single word 'American' to describe themselves. In Canadian English it's an important distinction. 'North' modifies the 'American' part such that it can now include all of us from Mexico on up.

In common usage, the single word 'American' is almost never used. When we refer to citizens of the US, we generally refer to them as 'damn Americans', 'bloody Americans', or 'fucking Americans', depending on the context. Except when the Americans involved are spending money on Canadian products, in which case we would use 'Sir' or 'Ma'am'. I believe the Mexicans follow a similar scheme in spanish.

yp.

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

[Luscious868]

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

Yes but you're clearly not an American hating idiot who is willing to resort to any tactic, no matter how stupid, to try and stick it to the "Great Satan". There are plenty of legitamte reasons to be angry with the United States of America and it's citizens and getting your panties in a buch because we, along with much of the rest of the world, refer to ourselves as Americans isn't one of them.

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

[ObiWanKenblowme]

So you're going to argue that America is one continent because North America and South America are part of a continuous landmass, but Europe and Asia are somehow different?

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

[franksands]

There are two different things here.

• First, there is the definition of what the name "South America" means. The definition is clear: South America has this name because it is in the south of the three Americas, named after Amerigo Vespucci, so "South" in South America is in fact a qualifier, even if "South America" is considered a noun.
• Second, since there isn't until now a good way to refer to someone that lives in the USA, it is used "american", since it is in one of the Americas. Furthermore, with the continued use of these term, it became common to associate "american" with "people who lives in the United States of America", but that doesn't mean the ones that live in the USA are the only ones that are entitled to call themselves americans. I for one, live in Brazil, and I am an American as much as any one that lives in any country of the Latin America, Central America, Mexico, Canada, or any other american country not mentioned here.

Therefore, if you truely want to see this predicament to end, someone must create a term to designate specifcally the people from the USA, like "unitians" or "USians" or whatever is more approprate. Sincerely, An American.

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

[GregAllen]

Sorry pal but for us the Mexicanos, the people from USA are called "Estadounidenses"

Make no mistake, "Americano" gets just as much use in Mexico.

You also forgot guero and bolillo.

Lo se porque he pasado mucho tiempo en Mexico, y soy "gringo Greg de Texas".

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

[fossa]

My Peruvian friends assert that there are only five continents: Americano, Africano, Oceania (Australia and surrounding islands), Europeo, and Asiatico. So, depending on who you ask, "America" may refer unambiguously to the United States of America, or to the single continent of America. It's also been pointed out that the five rings on the Olympic flag represent those same five continents.

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

[moranar]

My bad: "I see no reason to consider" should read "I see no reason not to consider" in the above. But I guess it's understandable from the context.

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

[popeguilty]

There are two American continents: North and South. The Central American region is split between the two but is mostly part of North America.

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

[CrimsonAvenger]

Since a definition of Continent is "a large continuous landmass", I see no reason to consider all of the American continent as a continent on its own.

By that definition, Africa, Asia, and Europe collectively comprise one continent. I trust noone has a problem referring to anyone in the major landmass as an Asian? Using theh biggest division as the name of the whole seems a reasonable compromise, I think - or would you prefer Eurasian? Or Eurafrasian?

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

[xtracto]

Lo se porque he pasado mucho tiempo en Mexico, y soy "gringo Greg de Texas".

Is it Tecsas or Tejas? =o)

And I am from Mexico (and lived there from 23 years, and plan to go back =op), I think that, if you are in Texas that is the reason why you hear "Americano", usually (at least in: La Paz, BCS;Campeche,Camp.;Mexico,DF; Monterrey,NL and Tampico,Tmp, the places where I have lived) they are called gringos or Estadounidense (if the person is present or somewhat you need to be respectful).

Of course, I believe Gringo is not used as a pejorative. BTW you know where the Gringo comes from no? (green go from vietnam war IIRC). It would be interesting to know how you call Mexicans (I know Beaners and "Ilegal Aliens" although I am not *completely* sure of the second one).

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

[Xtravar]

Nice. I'll have to remember that one.

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

[Xtravar]

I like your analogy.

I've been called a 'stupid American' by stupid Canadians before... I'd actually argue that that usage of the term originated outside of the USA. "I want to be an American!", "We're going to America!", "Let's buy blue jeans like the Americans!"

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

[moranar]

Hey, I'm talking about extensive use, and pointing out how a lot of people think. You're welcome to try and change every Latin american's mind. I'll be here waiting.

If we get to the sociopolitical definitions (necessary to define Europe, Africa and Asia as continents, where btw the main one is Eurasia to some, as you do point out), Latin-america and Anglo-america would be good separations. Or North-, Central- and South- (the latter separated by the Darien forest, the former by ... the Rio Grande?). Or just South- and North-.

None of these take away the fact that, right or wrong, it's the way a lot of people think.
When the continent was named, after Americo Vespucci, I don't think they meant "just the part under Canada and north of Mexico".

Lastly, the problem isn't so much that of the whole continent being called America or "Pineapplia". It's the USA calling themselves "America" as if the rest of the continent didn't exist. After all, if you're "America", what's "South America"? a colony? the bottom provinces?

I hope you see my point. I understand that you can use my points to say "but it's the same thing if you see it my way, after all, a lot of people here in the USA call this "America". It doesn't help a bit, though, to change the colonialistic and imperialistic traits we now associate with the USA.

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

[maxwell demon]

What about Antarctica?

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

[maxwell demon]

German (Vereinigten Staatler)

I'm German, and I've never heared that word. I know people from the USA as "US-Amerikaner", which can be literally translated to "US-Americans". The USA themselves are indeed often called "Vereinigte Staaten" in Germany (but "USA" is just as common, of course with all letters pronounced the German way), but I've never heared the adjective form (and indeed it sounds very wrong, because in that case the "Vereinigte" (united) wouldn't grammatically refer to the states, but to the people from the states ("Staatler" - a word which by itself sounds very strange to me, although it's not exactly wrong)).

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

[jedidiah]

Canadians are North Americans, not Americans. Lumping themselves in with the Brazillians makes even less sense then making it appear that they're in some 51st or later state. Or are Canadians prone to being Latino wannabes or somesuch?

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

[swv3752]

Americas (Plural) refer to North America and South America. America (singular) refers to the United States of America. Besides most Canadians will deny being an American when traveling abroad (though many Americans will claim to be Canadian for much the same reason so...).

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

[CrimsonAvenger]

It doesn't help a bit, though, to change the colonialistic and imperialistic traits we now associate with the USA.

And calling us US'ians does fix all that, right? Somehow, I doubt it.

Especially given that US'ian applies equally well to replace Mexican (United States of Mexico, remember?)

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

[zokum]

This discussion is quite funny, in Norway we have the word "verdensdel", literally it translates to "world part". Thus over here the world is seperated into various part, Europa, Asia, Oseania, Søramerika, Nordamerika, Afrika and Antarktis. Whether it's a seperate landmass doesn't matter. Continent is used about landmasses. As for the US, that country really doesn't have a proper name, it's just a bunch of states on the American continent that isn't even contiguous on the same landmass. If the US had had a proper name, not just a Unites States of Landmass-style name, things would have been a lot easier i reckon :-)

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

[petermgreen]

of course europe and asia is as artificial a split as north america vs south america possiblly more so...

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

[moranar]

Hey, life ain't fair, sorry to break it to you. I don't claim people are reasonable. I just mention what I see.

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

[usrusr]

Umm, no. The continents are "The Americas". As in, the three of them.

And consequently, each of them is an America. Which in turn, makes the peop... (i guess there's no need to type any further)

ps: seems like this "american" thing has become some kind of a pet flame of mine, although personally i am only bothered if any of those people who consider feeling hurt when they are called "USian" are reacting equally negative on "US American", which is my preferred way of putting it, at least whenever context does not provide enough clarity itself.

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

[hector1965]

even better why not coin an name specifc for the people of the united state of america but without ambiguity, something like...gringos

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

[fossa]

My friends tell me Antarctica gets ignored because it has no people. I don't understand the reasons behind any continental divisions, but the familiar seven continents, other than the Europe-Asia distinction, seem to follow major tectonic plates. I assume other divisions are more population or cultural based, although Europe's conquest of North America seems to have mostly squashed the previous indigenous population while things are more intermixed in South America. Though the CIA World Factbook states "Not until 1840 was it established that Antarctica was indeed a continent and not just a group of islands." That may explain its omission by some cultures' count. I think I've exposed my ignorance too much already, so I won't say any more.

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

[Mryll]

So what's a Mexican-American then? ;)

GPL compatible?

[tepples]

Intel distributes its C++ compiler for free under two conditions: compilation must be for non-commercial use

In other words, you're likely to be forbidden to distribute compiled binaries at all. A lot of programs that hobbyists would compile are under GNU GPL or another license that forbids adding restrictions against commercial fields of endeavor.

See http://www.intel.com/cd/software/products/asmo-na/ eng/compilers/clin/219856.htm

Linux only. So I can either spend $400 on the Windows compiler or spend $400 on purchasing Linux-compatible hardware to replace my Linux-incompatible hardware. And I still can't compile the Linux kernel and distribute the resulting binary because the non-commercial license is incompatible with the GPL. Hmm...

Re:GPL compatible?

[everphilski]

In other words, you're likely to be forbidden to distribute compiled binaries at all. A lot of programs that hobbyists would compile are under GNU GPL or another license that forbids adding restrictions against commercial fields of endeavor.

Non-commercial. You can re-distribute a binary as long as you aren't seeking renumeration for your work. And if you are scared, then just distribute as source with a makefile and have the user ./configure, make, make install with GNU gcc ... your code is clean and not compiler specific, right?

Re:GPL compatible?

[tepples]

Non-commercial. You can re-distribute a binary as long as you aren't seeking renumeration for your work.

The GPL does not allow anybody to add such restrictions to a binary.

just distribute as source with a makefile and have the user ./configure, make, make install with GNU gcc ... your code is clean and not compiler specific, right?

Which defeats the purpose of distributing optimized binaries if each user must separately license the compiler.

Re:GPL compatible?

[everphilski]

The GPL does not allow anybody to add such restrictions to a binary.

That's exactly my point. Your choice of a license is what is causing problems here, not a freely available compiler.

Intel is giving you a damn good compiler to play with for free, and you complain because it won't play with your license? Get off your @#$%ing pedistal.

All depends on the bottleneck

[noidentity]

If your program is I/O-bound, interpreted is probably fine. If your program is CPU-bound, then the question is whether it's in system libraries (video decompression, number crunching) or in your code (specialized algorithm). Only in the latter case will the performance be affected by an interpreted language. As modern operating systems provide more and more specialized services, the need for compiled user code is diminishing.

Anyone still coding in assembly?

[eDavidLu]

I'm old enough to remember when all "serious" programs were written in assembly, and compiled code were looked down upon as "too slow" or "only for wimply programmers."

Re:What?!?!?

[Calyth]

I would gladly invite you to demonstrate how a compiler is smarter than a human.
A compiler is a piece of software that's meant to translate from a human-readable language to machine language (be it raw machine language or assembly), in a reasonable amount of time, giving reasonable amount of performance.
There are lots of tricks to optimize the code and what not, but it is still an algorithm that often cannot surpass the ingenuity of a human.

A compiler will not necessarily maximize performance; it's merely meant to give you the best performance without forcing the programmer to write the majority of it in assembly. And a compiler isn't something you can write trivially, and despite gcc's faults, it's pretty damn good.
When you set certain flags targeting a certain CPU, it doesn't necessarily mean that it would make the compiler to be smart enough to use all the SIMD extensions available to do what is needed.

And I've got to laugh at all the notions that interpreted languages are approaching native code. BitTorrent uses Python, and running 5 torrents somehow initiates 5 instances of the Python interpreter, each eating up some 35MB of RAM. It forced the CPU usage to go high enough that my CPU cannot sit at a mostly idle 1.29GHz. Java is not that much better. Azureus dealing with 5 torrents eats up 90MB of RAM in total, but luckily it didn't eat up enough CPU to force power management to raise the clock speed.

I would gladly use a C/C+++ GUI torrent client anyday.

Just one question...

[AJWM]

What language do you code the interpreter in?

Compiled, JIT, and interpreted can coexist

[jesuswaffle0]

Let's consider a modern implementation of Common Lisp. It has an interpreter and a native code compiler. (To be fair, many have only compilers, and a few only have (bytecode) interpreters, but in all cases interpreter-like and compiler-like interfaces are exposed). The native code compiler can be run ahead of time, or when the program loads. Common Lisp supports all three models of compilation. Usually, you use whichever is most appropriate for the task at hand. When you're debugging, you interpret the code, because it gives better diagnostics. When you deploy, you compile the code, to get good performance. Theoretically, if you could run, e.g., a "Lisp applet" in your browser, you might use JIT compilation. Incidentially, this compilation-model-agnostic nature doesn't have to be exclusive to Lisp implementations. All three models can be applied to any programming language, and a programming language implementation could theoretically support all of them. The advantage to doing so would be that you would get the advantages of all of them: easier debugging with interpreted code, greater speed with compiled code, and greater portability with JIT-compiled code.

Nope

[Greyfox]

If computers are fast enough now, why strive to make them faster? Obviously they're not fast enough. Otherwise everyone would be happy with their 3GHZ pentiums.

Thing is, the closer to the iron you program, the faster your system's going to be. Going from Java to C makes a noticable speed difference on every system I've ever tried it on. That speed difference will mean an advantage in an increasingly competitive market, and because of that companies will still try to do things in C (Or even assembly language.)

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:What?!?!?

[AJWM]

Sure. It comes down to "how much of your interpreter can live in the cache?"

If your interpreter is getting cache misses on its code for every interpreted instruction, you can kiss performance goodbye.

Re:What?!?!?

[masklinn]

iTunes and Winamp

iTunes is dog-slow on every computer I tried it (compared to say Foobar or Winamp 2.95) and Winamp... well... Winamp3, do I need to say more?

Native code doesn't mean it's fast, it just means it's potentially faster than interpreted.

Loosing independance from bad spelling?

[InakaBoyJoe]

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

And in other news, a mysterious link is discovered between bad spelling ("loosing", "independance") and advocating interpreted languages.

Acutally could there be something here? After all, writing native code does demand a greater attention to detail than the quick-and-dirty way...

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.

Re:What?!?!?

[masklinn]

I would gladly use a C/C+++ GUI torrent client anyday.

C as in Torrent?

Re:What?!?!?

[masklinn]

Managed languages have their place as well, but not when performance counts ... and not when your goal is simplicity and provability of code to guarantee its execution in a timely manner

Deary me, and there I thought that Ada had been used for real-time and embedded systems and that it was somehow "managed", having fancy stuff like buffer-overflow, off-by-one errors or array access errors protections (at compile and run times) built-in, and automatic dynamic memory management... deary deary me.

Re:What?!?!?

[bladesjester]

I kind of wondered at the debugging comment too.

I've found that java tends to be a lot easier to debug than c. By the same token, C was easier to debug than ASM in the class I had to use that for and one hell of a lot easier to track down bugs in than Flex and Bison when I took the language creation class my senior year (good grief that was a nightmare).

I number crunch with Perl...

[RockClimbingFool]

Seriously. I work at Boeing and crunch numbers for a living on the shuttle program. We have many compiled Fortran codes for our 128 node linux cluster. I personaly have an HP c8000 workstation on my desktop. We also have a few IBM AIX machines at our disposal.

For quickly turning multi megabyte data sets A into multi megabyte data sets B, you just can't beat writing one script and running it on all the different architectures at my disposal with no compiling. Just run the damn script. I have libraries of various Perl modules for doing different things and I can run them from anywhere.

I know Perl isn't as fast as our compiled Fortran codes, but for the ease of use to do post processing, you just can't beat the flexiblity.

Re:What?!?!?

[LaminatorX]

Mel would certainly not care for interpereted languages.

Re:What?!?!?

[19thNervousBreakdown]

Most likely GStreamer. Quod Libet uses it, XMMS doesn't. This is something that has supposedly been fixed in a recent version of GStreamer. I know I get the same thing in Rhythmbox, which is written in C, and this issue is specifically listed in the release notes.

Use the right tool for the right job

[BigLinuxGuy]

This question was boring 20 years ago. The short answer is to use a compiled binary where appropriate and use an interpreted language where appropriate. The difficult part is knowing when to use one vs. the other and in some cases it is not a black-or-white choice.

Of course, monolinguists will insist on writing everything in their language of choice because they don't want to learn any other language or the other language is "too hard" (or worse, isn't supported in their IDE of choice). The sad statement is that if this attitude persists, there will be nobody to write the VMs or JITs for the "non-native" languages.....

Of course, your mileage may vary.....

No ANSI-standard Java

[Quiberon]

There's no ANSI-standard JAVA, or ISO Java; so you're not really sure what language you are writing in, whether it will mean the same thing in a year's time. Or whether there are defects in the interpreter (of course there are). Also, it's less environmentally friendly; in these 'carbon-conscious' days you would do well to remember that it will take more electricity to run an interpreted program ...

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

[Bombula]

I am completely ignorant about programming - the closest thing I've ever done to it is Excel formulas and a couple of tags for things like italics in slashdot posts!

My question is, is there really no 'best' or 'most logical' way to deliver instructions to a computer? In other words, is it actually impossible to deduce a single, optimal programming language from the finite (and relatively small, if I understand it) number of different basic functions a computer is capable of performing?

I mean, obviously computers are the most complex of all machines. But they still only actually do a small handful of different basic tasks. I guess I'm just surprised, in principle, that there isn't a logically ideal language for giving a computer instructions on what to do and when to do it. I vaguely understand the difference between assembly languages and higher-level languages, but again I'm surprised there isn't a logically optimal higher-level language that translates into assembly wth maximum efficiency and accuracy, which then translates into actual instructions with similarly maximum efficiency and accuracy.

I know, I'm retarded about this stuff.

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

[pla]

First - Although I sound negative here, I mostly agree with you. Just wanted to point out some matters of opinion that I think need exploring...


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.

Some things take work to do correctly. Every point you've made about C, I would also make - in its defense. Every "improvement" in C++, I would point to as a step in the wrong direction... OO sounds great in theory - "Imagine a CPU with object-level parallelism!", they all said - But those CPUs never came. Why? Because "object level parallelism" means nothing more than massive multithreading of proceedural code, separated by nothing more special than a pointer. GC sounds great in theory - Except that the exact same programming flaws that used to lead to glaringly obvious null pointer exceptions now lead to impossible-to-find memory leaks whereby an app's working set grows without bounds until it eventually crashes.

You can give a monkey better tools, but they still need to understand that those funny "spirally ribbed" nails don't go in via a hammer.


In practice, programmers in those languages seldom have to think about memory allocation issues.

And, unfortunately - It shows!

For two years now, I've found myself doing C#, now under .NET 2.0. And damn me if even toy apps don't eventually grow to eat dozens of megs, with anything serious all but impossible in under a hundred megs. "But your PC has what, two gigs of RAM these days?" Yeah, two gigs I'd rather use than wipe MS's ass with.


but we on the software side should have the understanding and grace to be embarassed by it.

Consider me suitably embarrassed.

Every time someone asks me what I do for a living, and I debate whether or not the answer will lead to the obvious followups "why does my three month old computer run so slow" or "why does Windows crash on me every time I..." - I feel properly ashamed at what our universities turn out as CS grads. Every time I have to work around a crippling "safety" device in .NET, I curse the morons that make such absurdities a necessary part of a programming language ("Warning! Do not remove foam packing from the hammer! Severe injury or death may result!").

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

[rfc1394]

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

Hear, Hear! The convulsions you have to go through to get things done in some programming languages makes my skin crawl.

Programming backed itself into a corner with C and C++. They're useful languages, but they're not safe.

Preaching to the converted here. One of the stupidest features (spelled b-u-g-s) in C was the making identifiers case sensitive. So now, you have more ways to make mistakes because not only can you mess up by spelling an identifier wrong, you can also mess up by using the wrong case for the identifier too! A (programming) language that gives us more ways to screw up has got to be one of the great moments in human development.</sarcasm>

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.

Ada might have been a good language except it has a big problem because in that it was too complicated to use properly. Sort of like the complexity of APL but without the capability. Too many features that should more properly be implemented in the environment through system calls (like co-routines and subtasking) were made part of the language. Increasing complexity makes it harder to write code and definitely harder to write compilers.

A number of people criticize Pascal because of the supposed 'limits' in the language. What they miss is many of the so-called limits were designed to teach people how to write better programs by forcing better habits. And despite the 'smearing' of the language by referring to it as an 'educational' language, what it does do is exactly the sort of thing that professional programmers need to be protected against just as much: making errors in handling data.

Features of Pascal such as strict type checking (you can't assign two non-equivalent values to each other (with some limited exceptions) unless you explicitly declare them using conversion), array size validation (you can't access an array outside the valid ranges, both low subscript and high subscript), predefinition of identifers (you have to declare an identifer and its data type before you're allowed to use it), deprecation of the 'goto' statement in favor of better constructs, are all features that make people write better programs that are less likely to have serious errors. The worst attacker problem in C / C++ applications, the buffer overflow problem, where someone contaminates a program by injecting new code beyond the range of an array, and thus causes an application to run arbitrary code of their own choice, is impossible in Pascal because if you access an array outside the legitimate range size, the value checking system throws an exception.

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.

People seem to have obsessed over Java and the safety features of the language and how wonderful it is. Java is just C with a number of the unsafe features either deprecated or removed. Java is an attempt to give C some of the safety features of Pascal while still leaving off many of its other safety features.

What's so embarassing about all this is that it's quite fixable. The solutions were known twenty years ago.

Pascal was able to correctly implement pointers (which you need if you are going to manipulate data structures where you don't know how many i

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

[lurvdrum]

It's always a compromise. There's always a tradeoff between ease of writing the program and the portability and speed with which it executes. I spent many years coding directly in Assembler for IBM mainframes and the execution speed was so fast it almost finished before it started. Code written in a third or fourth generation language on the same platform always seemed sluggish by comparison, but no-one would have suggested writing our core applications in Assembler; that was reserved for the critical paths only. To have any chance of supporting applications the benefits of writing them in a high-level language (portability and clarity) outweigh the speed advantage. Horses for courses.

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

[rfc1394]

I mean, obviously computers are the most complex of all machines.

No, living organisms are. Computers are the most complex man-made machines. :)

But they still only actually do a small handful of different basic tasks. I guess I'm just surprised, in principle, that there isn't a logically ideal language for giving a computer instructions on what to do and when to do it.

The 'programming language' for implementing living organisms, DNA, if I remember correctly, only has about 4 'instructions' for describing how to build a cell. By stringing those instructions into long chains of molecules, you get various cells that do certain things. Cells combine to form organs and the organs combine in a system to form a person, an insect, a dog or just about any living thing. (Viruses work differently and are usually considered nonliving for technical reasons.) In computer code, the individual instructions are the equivalent of DNA, and subroutines, functions and objects are the equivalent of cells. Programs are the equivalent of organs and collections of programs used to perform a function represent the equivalent of living things. The complexity of both is about equivalent in terms of what they can do even though DNA is much simpler in theory, in practice it does some amazingly complex things.

I vaguely understand the difference between assembly languages and higher-level languages, but again I'm surprised there isn't a logically optimal higher-level language that translates into assembly wth maximum efficiency and accuracy, which then translates into actual instructions with similarly maximum efficiency and accuracy.

Each CPU architecture does different things and has different uses even if they are designed as 'general purpose' processors. The Power PC CPU for the Macintosh is a different beast than the X86 CPU for Wintel PCs as is the IBM 370 Z-series mainframe processors, while they're all made out of sand (silicon is simply processed sand), they might as well be as alike as oak trees and aphids are alike in the sense they're both living organisms. Which means the methods of working with different processors (as the DNA for both types of living things) require entirely different methods altogether even if computer code / DNA all start at the same place.

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

[Thoran]

That's easy to say now that C was badly designed almost 35 years ago. Given what we knew at this time about grammars, type systems, or language theory in general, I would say C was just a brilliant innovation. I'm not particularly shocked by the design choice about pointer and arrays. That looks vaguely reasonable if you are in a portable assembler.
The only things I consider as a real mistake is automatic conversion. That is just not in the spirit of such low level language. The conversion from an "int" to a "double" is not trivial at the machine level. This should have been made explicit, IMHO. That's the major reason that makes coding numerical algorithm in C very dangerous.

What is absolutely non-sense, from a purely technical point of view, is to have extended that language during the 80's to reach the hideous
C++. Unfortunately, things don't evolve based on technical reasons. And coders always prefer to learn a new feature of a plain old legacy stuff they know well, instead of learning a completely different language.

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

[00lmz]

As much as I like Pascal, there are several flaws in your argument.

Array size validation doesn't exactly come for free, it must be checked at runtime for every access in which the compiler cannot prove that the index is within the array bounds. For dynamically sized arrays passed as procedure parameters they may even have to be checked for every access. New() and Dispose() is not garbage collection – they're no different from C's malloc() and free() i.e. you still leak memory if you call New() and don't call Dispose().

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

[Sterling Christensen]

Have you looked at D?
http://www.digitalmars.com/d/index.html

Compiles native as fast as C, but has all the safety and convenience features of Java/Python - garbage collected, bounds-checked, etc.

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

[Threni]

> My question is, is there really no 'best' or 'most logical' way to deliver instructions to a
> computer?

Yes, assembly language.

> I vaguely understand the difference between assembly languages and higher-level languages, but
> again I'm surprised there isn't a logically optimal higher-level language that translates into
> assembly wth maximum efficiency and accuracy, which then translates into actual instructions with
> similarly maximum efficiency and accuracy.

Such a tranlator would have to be very sensitive to the speeds of the various CPU instuctions, the size of the CPU cache(s), the speed of the various other parts of the computer (bus speed, amount of ram, attached hardware), and, perhaps most importantly the job at hand. You'd need to make changes each time a new CPU came out, or when the language changed. You'd need all this for each CPU (whether general purpose PC chip, GPU, embedded CPU etc).

It might actually be an impossible problem to solve.

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

[scruffy]

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

And we are still teaching them to our students.

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

[SenseiLeNoir]

Although i Love Pascal (i have been a Pascal programmer for years, starting with Turbo Pascal and moving to delphi). I am also equally a Java programmer..

Pascal is safer than C and can achieve equivelent performance. However, delphi, and its ancesters did allow you to override most checks. This is not possible in Java. Also Delphi (except the .net version) is NOT garbage collected for all objects, only strings. You do get the impression of garbage collection from the way Delphi works, but its only because the VCL uses a good heiracial model for its objects, to ensure objects are removed eventually, but if you do not use the VCL model, you will get memory leaks.

Finally Java uses soem run time optimisation that very few if any native code can implement. For example bounds checking is NOT always done if there is no need for it. For example where a counter exists and the counter only goes up, no lower bounds checking is done. If the JIT compiler can determine that the loop value will always be in the bounds of the array, NO bounds checking will be done at all.

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

[UnknownSoldier]

As much as I love C/C++, I have to agree with you on certain points, and disagree on others.

I agree that arrays == pointers is a PITA.
i.e.
void foo( int n );
void foo( int *p );

foo( 0 ); // user want to call the int version -- doesn't happen.
foo( NULL ); // guess what this calls?
(Part of the problem is that the language has no real 'null' type.)

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

The problem is that C/C++ always forces them to be the same, and Java never lets you.
The solution would be to divorce the two, and add an 'array cast'
i.e.
array int s; // type-safe array.
int a[]; // native, fast, "unsafe" array
int * p = array( &a ); // C++ doesn't let you cast pointer to array

The binding order needs to be fixed in C/C++ so it is always left to right, instead of the mostly-left-to-right-but-sometimes-right-to-left.
i.e.
int * ap[ 10 ]; // array of pointers // int (*p) [ 10 ]; // pointer to arrays
int [10] *p; // point to array -- consistent, and easy to read/parse by both humans and compilers.

I disagree that static sizes are the end-all-cure-all you're assuming, because the tradeoff is performance.
Let's say we have some built in string type for the language. What is the biggest size it can be?
A dumb, but fast compiler would use int64. A smart compiler would use various types, int16, int32, int64, etc, and upgrade the to the correct base struct.
i.e.
native_struct string_fast_nonflexible
{
      int32 _nSize;
      char *_pData;
}

native_struct string_flexible_64K
{
      int16 _nSize;
      char *_pData
}

native_struct string_flexible_4G
{
      int32 _nSize;
      char *_pData
}

You optimize for the common case, so that it has zero (or next to it) overhead, else you'll never get the C/C++ efficiency diehards to adopt it. You do, and everyone else will follow.

The problems is that some user will ALWAYS allocate the maximum possible size, and overflow it. How do you handle this case efficiently?

The other big problem with C/C++ is that Unicode chars are an absolute mess.
i.e.
There is no good way of doing...
char08 s08 = "ASCII"
char16 s16 = "16-bit Unicode"16
char24 s24 = "24-bit Unicode"24
char32 s32 = "32-bit Unicode"32

I disagree that Garbage Collections is a solution. There are embedded cpus/consoles where it _not_ allowed.
Why do you think "embedded C++" is an issue?? Modern CPU's should do the _right_ thing, but not all computing environments can afford the overhead of safety.

Anyone working on consoles, knows that the first thing you do in optimizing is write a custom heap allocator. You know your data [usage] better then the compiler!

> You just can't fix those problems in C++ without breaking backwards compatibility.
Agreed. This is why I started working on C^2. i.e. Fix the "include" hack by doing proper modules, fix arrays and pointers, add proper macros that are typesafe, etc. Unfortunately my language work is still in the design phase.

Cheers

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.

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

[Animats]

I know about D, I corresponded with Walter Bright about it, and I used his early compilers. But it's just not getting any traction. Today, to introduce a new language, not only do you have to give it away, you have to spend money promoting giving it away. Sun spent $20 million to launch Java as a free product.

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

[jd]

Occam is like that, where all sizes are known in advance. There's an excellent native Occam compiler (KROC) which will work on a number of CPUs these days. (That's important to note, as Occam was originally written with the Transputer in mind. Which was a damn good processor for the time.)

Answering the speed of Java question seems easy enough - just compile the code with GCJ to get the native version, run the same code under a JIT engine, and then run it a third time as pure bytecode. My guess is that the code will run faster when natively compiled, and that the difference will increase as the complexity of code increases.

The other thing to bear in mind is that CPUs are designed around procedural code, NOT functional design and certainly not object-oriented principles. Code written in a non-native paradigm is essentially cross-compiled to the native paradigm and there must surely be some loss of efficiency there. I suspect that if you were to build a CPU where the design and instruction set was modelled after Smalltalk, then compiled C would probably run slower than interpreted Smalltalk, as the interpreter would be a very thin layer over the CPU whereas the compiler would need to add an enormous wedge of compatibility code, adding overhead.

Is this possible? Well, as I mentioned earlier, the Transputer and the Occam language were built in tandem as a combined product. There was therefore a lot of benefit in writing in Occam, even though you could have used C and a cross-compiler. Occam was going to be faster, even though it could be a bear to program in at times. Clearly, high-level CPUs are indeed possible, although they are not trivial to design and seem to have proved very hard to maintain.

High-level CPUs were largely abandoned, as people moved to a hybrid RISC/CISC architecture. I think that CPU design is now sufficiently complex that higher levels of operation might be worth reconsidering. There, the difference between compiled and interpreted would collapse, as the instructions in the code would match the instructions on the CPU. At that point, compiled code would be pulled by the CPU and interpreted code pushed to the CPU, but what was executed and how would be identical.

This is NOT the case on existing CPUs, so this scenario is irrelevent. Code is far more complex than the assembly, which means optimizing compilers will always be faster than interpreters on such an architecture, and potentially so much faster that you might as well not bother with the difference.

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

[CoughDropAddict]

The problem is that, because of some bad design decisions in C (the equivalence of arrays and pointers being the big one)

Arrays and pointers are not equivalent in C. And I think C is nearly perfect at being what it is: a portable assembler.

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.

They're not design defects: you don't get these things in C because you don't get them from assembly either.

C is pretty much the only language that has no lies. Everything you do maps very directly to something that computers actually know how to do, like add, subtract, jump, load, store. Computers have ALUs, but alas, they don't have GCUs.

Perl and Python are reference-counted, and in practice, programmers in those languages seldom have to think about memory allocation issues.

Unfortunately reference-counting leaks in circularly linked structures.

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

[Animats]

Occam is like that, where all sizes are known in advance.

There's a language you don't hear much about any more.

The other thing to bear in mind is that CPUs are designed around procedural code, NOT functional design and certainly not object-oriented principles. Code written in a non-native paradigm is essentially cross-compiled to the native paradigm and there must surely be some loss of efficiency there. I suspect that if you were to build a CPU where the design and instruction set was modelled after Smalltalk, then compiled C would probably run slower than interpreted Smalltalk, as the interpreter would be a very thin layer over the CPU whereas the compiler would need to add an enormous wedge of compatibility code, adding overhead.

Then again, maybe not. LISP machines turned out to be slower than LISP on conventional CPUs. Hardware Java engines turned out to be a dead end. The programmer-friendly instructions of the VAX line slowed down the CPU, and the Intel 432 was painfully slow. It's not at all clear that building higher language abstractions into the hardware helps. You lose some of the ability to exploit concurrency that a modern register-oriented superscalar CPU gives you. It's surprising which instruction set architectures can be made to go fast. x86 actually turns out to be pretty good, ugly though it is. RISC features like large numbers of programmer-visible registers and fixed-width instructions turned out not to help. The overhead of saving and restoring registers slowed down calls and interrupts, and the fixed-width instructions caused code bloat and wasted cache space.

There are some interesting things to do in the architectural area, like making the CPU's MMU and interconnects like InfiniBand play well together, so you can have safe inter-CPU communication without operating system intervention for every message pass. That's probably the next area for major performance improvements.

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

[Animats]

Unfortunately reference-counting leaks in circularly linked structures.

That's the textbook answer, but in practice it's not a major problem, especially if you have both "strong links" and "weak links", like Perl. Perl and Python can leak circularly linked structures, but in practice, they seldom do. The reason is that leaks due to circular linking are generally due to design errors, and will occur in normal program operation, so they're caught early in debugging. Unreleased blocks and dangling pointers, on the other hand, tend to occur in abnormal situations, so they're not caught early in debugging and persist into production programs.

In a language with destructors, a reference-count approach has the advantage that destructor ordering works out correctly. Trying to call destructors from the garbage collector leads to a horrible mess, as can be seen in Managed C++.

Re:What?!?!?

[TinyManCan]

C is a lot easier to debug, is dramatically faster, and gives the developer a lot more control over memory allocations, which can result in orders of magnitude performance improvement when you start running into paging stress from poor garbage collection in Perl or PHP. Sadly, all those benefits are only helpful if you don't have to spend days debugging some buffer overflow bug. or trying to figure out why some random function in a library that will remain nameless returns NULL out of the blue (with no error codes).

What is cheaper now, a 2gb RAM stick or 100 hours of good low-level programmer time?

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:Bingo

[OpenGLFan]

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.

Well, it's been done in C++, and in a way that gives at least some hope that interpreted languages are capable of it. Nifty template metaprogramming tricks allow the compiler to inline function calls and reduce operations to one iteration. I TA'd a graduate programming language course at UT (EE380L), and this was one of the assignments; unfortunately, my course page has been butchered by my graduation, but after you understand the concepts it's actually quite a useful (if ugly and unreadable) trick. Because of all the inlining, it's actually occasionally faster than C versions. (Modulo Icache effects of inlining, etc.)

This type of heavy inlining of (generally virtual) functions in interpreted languages isn't possible for all languages and situations, but I wouldn't say it's impossible. Maybe somebody wants to make it a research project?

Re:Bingo

[illuminatedwax]

You can spend the time writing it in C, or you could just combine those six operations into a single one and have MATLAB or perl whatever do it in the right order like you say. Or am I missing something?

Re:Bingo

[Dr. Zowie]

What you are missing is that the interpreted, vectorized languages all vectorize to avoid having to live within the interpreter all the time: if you say (in PDL) "$a=7*$b+2" and $b contains a million values, essentially all the processor's time is spent inside a fast loop written in C, iterating over those values. For light-to-medium tasks, you win big because you get the flexibility of an interpreted language and vector notation, and you don't have to wait for the interpreter to run (as you would with loops written in the JIT language).

But that strategy works best only when the variables actually fit in cache or when the CPU runs at the same speed as the memory bus.

Re:Bingo

[iluvcapra]

some of the stuff I do (magnetohydrodynamic simulation)

Please submit a story when you have a real Caterpillar drive working ;).

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.

Native code versus native GUI

[wysiwia]

While for developers code may count it doesn't for users. If native code dies is only a questions if developers are able to build easily native code as if none-native code. As long as there are useful tools around. An these days this can be safely answered with yes.

On the other side users care at lot for native GUIs. As long as users are able to distinct e.g. a Java application from a binary (native code) application within 5 min. of using, vendors selling SW have to care for native code which produces far better native GUIs than none-native code.

Yet the SW industry does not work as in other branches. Since development costs is the driving force other considerations have to be taken into account. So for inhouse development, where users complains don't matter that much, none-native Java is favored and forced. On the other side in the free world and the commercial vendors there's no alternative to native GUIs therefore native code.

Yet the future of native versus not native isn't decided so far. With the hyped AJAX there's a none-native technique on the rise while with wxWidgets/wyoGuide (http://wyoguide.sf.net/) there's a now superb cross-platform native technique available. So it might be that in the end there's a draw between native and none-native going along very well.

O. Wyss

Parallelism vs interpretive

[RareButSeriousSideEf]

For most general purpose programming, sure interpretive languages will get better. The CLR's role will need to expand to encompass that of a compiler and an installer. IL's need to be capable of resource awareness, in addition to maintaining platform independence. Development environments would still build IL assemblies, but the first task of the average runtime library would be to polish up the IL in the native context of the target system (OS, processor, bus, etc.), then persist that output.

Parallelism might take some heavy retraining for those not used to it, but even this can be eased along by constructs like method attributes and compiler hints.

Except in extreme instances, the really hard work of multi-core enabling executable code will be put in by the IL, compiler and CLR designers, not by the average keyboard jockey. I'd also imagine that as these things continue to evolve, the problem of managing an expanding array of entry points into hardware resources will be handled by some of those additional hardware resources themselves.

Re:What?!?!?

[Kethinov]

iTunes slow? Use Amarok, Quod Libet, or Banshee for a while then tell me iTunes is slower. iTunes is faster in bloody WINE than those apps.

Re:What?!?!?

[tomhudson]

Interesting point ... so I tried to rewrite the stuff to see how ada compares, but my gcc complains that it (gcc) is missing part of the required ada functionality - time to download and update. I will check it out.

btw, you can get the same features for c++ (buffer overflow, outside-of-range access, automatically allocate, deallocate memory, etc) - either by building the appropriate objects yourself, or by using a library that has those features. Or, if you figure you don't need it, don;t use it. Just as you can turn it off in ada.

Try doing that with Java, python, etc ... You can't. The runtime environment is part of the language's definition. In that sense, ada isn't a managed language ... while the checks, etc., are part of the spec, from what I can see they're not essential and you can run more or less "unmanaged".

Re:What?!?!?

[masklinn]

Sorry, I'm under Windows so I probably don't have Amaroq (maybe Quod or Banshee?). Anyway I was comparing iTunes to Foobar (which would be XMMS) and Winamp. Foobar is orders of magnitude more responsive than iTunes, Winamp5 with modern skins is also much faster, and I'm of course not even talking about Winamp2.

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?

Re:Getting lazy?

[Surt]

Because it just isn't true.

The actual capabilities of software have grown enormously over the years. Word does much more now than it used to. Remember when you had to 'run' a spell check on your documents? Remember when a grammar check didn't exist. Then when you could buy it as an add on. Then when you could run a grammar check. And notice now that it just makes dynamic suggestions as you type? Remember when it couldn't just auto replace common typos?

Remember when Excel could only give you eight thousand rows? One hundred thousand?

Why aren't you using netscape 4.7 (or something from the 3.0 series) instead of firefox 1.5? It used less memory and cpu.

Remember when you didn't need a mouse to use your computer? Because you didn't have a GUI?

Our computer software has been taking many, many small (and some large) steps forward over a long period of time. Maybe the advances, individually, just aren't obvious enough, but most software uses more resources today than years ago because it does much, much more.

Re:Getting lazy?

[ealar dlanvuli]

Maybe people are more focused on providing features than dealing with C++?

God help us...

[misleb]

No more Java geeks who think that people actually want to use Java applications. Speaking as a Mac/Linux user, I can say that having portability is simply not worth the bloat and hideousness of a Java application. I'll hold out for native apps in GTK/Qt or Cocoa, thanks. And I know that Windows users are not exactly hurting for native applications. So what the hell is the point? The only people who seem to actually like using Java applications are Java developers. The problem is that you lose so much OS integration by building a one-size-fits-all application.

-matthew

Re:God help us...

[Billly Gates]

There are some successfull java apps.

Azeurus and limewire/frostwire are just 2 I know of.

Yes its not as integrated into windows which sucks for business apps but the java api is next to none for creating graphics desktop and phone apps. For things like simple games and applets it kicks ass.

Java 1.5 has alot more precompiled byte code and dynamic class loading. Java 1.6 will include the java 3d api and use the systems native GPU fully for the effects.

Java only appears slow when it loads and the fact that its gui components are not multithreaded by default like most other languages when you implement gui functions. THis will be fixed with java 1.6 mustang for the lazy programmers who dont know how to do this.

No I am not one of those java fanatics but I used to hate it myself until I had a class in it last Spring. It was much more pleasant than c++ and I fell in love with javadocs.

Re:God help us...

[zootm]

To be fair, you can write GTK, Qt, and Cocoa apps in Java. "Bloat and hideousness" is largely a myth (people who stare at top all day might notice more memory use, but that's about where Java's "bloat" ends).

The problem you're mentioning is with Swing (the GUI toolkit) though, yes. And it is a problem. Swing can be unweildy and inconsistent with the platform, particularly on Linux. This is being worked on as a priority for the next Java version, but it's a real shame it's taken this long to happen. The fact that you need a prerelease version of Java to use a workable GTK theme is discouraging, but at least it's there now.

Java has proven itself to be fast and reliable on the server-side, but it's never (until, hopefully, soon) really had the GUI muscle to back it up. But with any luck, soon it shall, and we can get away from having to rely on native applications so much.

I know you will have had a bad experience with GUI Java apps. Most people have. But there's no core trait of Java causing it not to work well. It just doesn't work well in the current and previous versions. This is a solvable problem.

Re:God help us...

[misleb]

Azeurus and limewire/frostwire are just 2 I know of.

Azeurus is a perfect example of the hideousness I am talking about. At least on Mac. It isn't so bad on Linux due to the GTK plugin. But it is still a little "off." Do people use Limewire anymore?

Yes its not as integrated into windows which sucks for business apps but the java api is next to none for creating graphics desktop and phone apps.

"graphics desktop?" What is that? And why is Java so good for it?

Java 1.5 has alot more precompiled byte code and dynamic class loading. Java 1.6 will include the java 3d api and use the systems native GPU fully for the effects.

Java has made lots of promises over the years. We'll see how it works out. But as far as I can tell Java best just stay on the web server where it can actually get some work done and nobody has to look at it.

-matthew

Re:God help us...

[misleb]

To be fair, you can write GTK, Qt, and Cocoa apps in Java. "Bloat and hideousness" is largely a myth (people who stare at top all day might notice more memory use, but that's about where Java's "bloat" ends).

A myth?? Don't tell me it is a myth. I can start up Azereus on my Mac and experience it first hand. The only reason I keep that piece of crap around is because, for the most part, I dont' have to interact with it to use it.

Java has proven itself to be fast and reliable on the server-side, but it's never (until, hopefully, soon) really had the GUI muscle to back it up. But with any luck, soon it shall, and we can get away from having to rely on native applications so much.

But I LIKE native applications. Why dont' developers understand that? Users don't care how cool the language is or how portable it is. They just want it to run, and the faster and more integrated with the OS, the better.

-matthew

Re:God help us...

[zootm]

A myth?? Don't tell me it is a myth. I can start up Azereus on my Mac and experience it first hand. The only reason I keep that piece of crap around is because, for the most part, I dont' have to interact with it to use it.

For what it does, it's pretty fast in operation. But, that said, it's pretty slow, because what it does is so complicated. So yeah, it's an annoying one.

But I LIKE native applications. Why dont' developers understand that? Users don't care how cool the language is or how portable it is. They just want it to run, and the faster and more integrated with the OS, the better.

Integration is coming, hopefully. The current focus of Java core development is with desktop integration stuff, so hopefully that'll get better soon. The speed issue isn't really an issue — Java is generally as fast as native code. Its use in servers shows this very well, and I hope that desktop apps demonstrating this are along soon.

The biggest complaints with the performance of Java programs on the desktop fall into three categories, in my experience:

1. "It's not responding quickly enough" - typically the fault of the GUI framework, which in the case of Swing doesn't double-buffer and so on, so appears slow, and in the case of SWT (which is what Azureus uses) a lot of the native components for some systems just aren't very good.
2. Startup pause. This is because Java is a JITted language, and there's a compilation phase before the program runs. I realise this makes it a little hard to justify using it in the realm of smaller systems like widgets and so on, but for applications that are only started once, this is a fairly minor issue.
3. High memory use. Although Java's memory use is high, this memory is not generally all used at any one time. This complaint tends to be brought by people who don't understand how garbage-collected languages work, and have gotten a false impression of the "bloat" of a Java program by looking at its resident size.

Re:God help us...

[misleb]

For what it does, it's pretty fast in operation. But, that said, it's pretty slow, because what it does is so complicated. So yeah, it's an annoying one.

Maybe it is complicated on the backend assembling all those torrents, but from a user's persepective, it is pretty simple. Display a list of downloading/queued items with some status and statistics in a couple tabs. That's it. Somehow they've made something like that feel slow.

-matthew

Re:God help us...

[zootm]

I wonder if it'd be possible to create a cut-down version of Azureus (which behaves more like uTorrent) which runs faster?

Re:God help us...

[misleb]

Or I could just install one of the many native Bittorrent clients for OS X. Actually, I think I will. The only reason I installed Azureus at all was because that is what I knew from other platforms.

-matthew

Re:God help us...

[zootm]

I wasn't suggesting you do it, I was pondering about whether it'd work. I'm afraid I don't know of any native clients for OSX that are any good though, or I'd suggest them. G'luck finding one. :)

Re:God help us...

[zootm]

You can change the heapsize that Java uses, it's generally wise to have it at a value which is suitable for your system, and for the software being run. A particular problem with older versions was that the defaults were not particularly sensible, and few people actually changed them. One change in Java 5's virtual machine was an overhaul to attempt to autodetect "sensible" settings for when none are specified.

I wouldn't recommend running Java apps on a system with less than 256MB of RAM, though. One would hope such systems were fairly old now anyway, though.

Laughing at requirements why?

[Jugalator]

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

Official "Vista Capable" Requirements:
800 MHz CPU, 512 MB RAM, DirectX 9 graphics card w/ 32 MB RAM, 15 GB free space.

Official "Vista Premium Ready" Requirements:
1 GHz CPU, 1 GB RAM, DirectX 9 card with Pixel Shader 2.0 and WDDM support, 15 GB free space.

I think either the author or Microsoft is out of touch with reality a bit, but I've running Vista with 1 GB RAM better than expected, and that tend to matter much more than the CPU speed from my experiences.

Re:What?!?!?

[jawtheshark]

That little expandy bar NEEDS at least 1.5GHz of power to be usable.

P-III 600MHz mobile here and the thing works just fine. Sure, the images are a bit jaggy, but it's usable. Sure the CPU runs at 100% when I use the thing, but it's not the end of the world. I think that a 1GHz proc would cope without "jaggyness", but I have none around to test.

Re:What?!?!?

[upside]

Good point. My impression is none of the modern "interpreted" languages are compiled every time. Most are hybrids with bytecode and features like cached executables.

Squeezing CPU cycles

[dexen]

Ain't it funny, that if you want to use interpreted language, you definitely want to have the Virtual Machine or Interpreted written in native, to save as much on CPU as possible?

Ain't it the final bottomline of using interpreted code -- interpreter itself being native?

Doesn't it mean that the supporters of interpreted want, and rely on the native stuff teh most?

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:My one guess

[sporkmonger]

Warning, I know virtually nothing about Pyrex, but... It seems to me that C is usually still the better choice because it's fairly easy to use the same C code in Python, Ruby, Perl, PHP, etc, whereas it looks like Pyrex is squarely targetted at fast extensions for Python? If I discover that my feed parsing code is slow, and I decide to rewrite it in C, I figure everybody should be able to benefit from my rewrite rather than just a single language community.

Re:My one guess

[adisakp]

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.

Not *ALL* the "fast C" code has been written. There's lots of code out there that needs to run faster... some written and some yet to be written. You can use python to string together all the calls to already-written-C-libraries you want but when you have an inner loop of a tight algorithm that isn't in a library fo you, you're going to have to break down and code it in C (or JAVA running through a JIT-native compiler, etc).

Re:My one guess

[Money for Nothin']

Very well said. Thanks for saving me from making a long post of my own. :)

Re:My one guess

[xant]

Heh, I cede the point. I was being facetious with my comment about Pyrex, although as a Python programmer, I would of course choose Pyrex for my own applications.

If you want to write the C library, I'll be happy to write the Python bindings. ;-)

Re:My one guess

[sporkmonger]

I will, in fact, be writing the C library, but not for awhile. Got other projects to finish first...

Re:What?!?!?

[dgatwood]

Yeah, I know some folks do server-side Java, but I wasn't talking about Java. My debugging comment was comparing C to scripting languages like Perl and PHP. They've gotten better, but I still find myself missing gcc regularly....

I don't have much of an opinion on server-side Java either way.

It really does depend on your needs

[Explodo]

I'm currently working with a military simulation network. That means that speed is of the essence, and memory is tight. We already are using 3GB and more of RAM, and we could expand to use any that we are theoretically given. If there's memory overhead from the interpreted language, it's unacceptable. If there's a speed penalty from an interpreted language, it's unaccpetable. There are times when code is written that is nowhere in the realm of good coding because, yes, function calls do take time because not everything can be inlined. There are others working on the same project using interpreted languages, but they're not able to work at the resolution that we work at. To mirror some other comments, if you're writing GUIs, or database apps, or web apps, then interpreted languages may work just fine for you. I never intend to do those things as I think I'd be bored beyond belief. I write algorithms...and I use native code.

Re:What?!?!?

[dave1g]

I think a lot of that ram is the incoming data waiting to be written to the cpu and outgoing data held in memory to be sent out to others...

But what do I know.

Also might just be java swing being bloated, I think azureus has a command line version, ive never tried it though....

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

[MemoryDragon]

ahem.. you obviously have not done java extensively, for client side apps you are set with a vm, thats it, everything else has to be bundled in the jar. For server side apps, a jee container does it in conjunction with a vm, everything else should be bundled in the ear or war file... seems hard? Programming java is a different issue, if the vm and jee server do not fullfill you needs you have to go jar shopping, which is not too bad, good ides bundle most of the stuff you need and basically a webapp is a push of a button.

Downsides of interpreted/vm languages

[idries]

Regardless of the negligible performance hit compared to native code

There's a whole number of reasons why native languages are still in very heavy use in a number of environments and industries. The original post plays down the performance concerns but they are a real consideration for many products. Compare the user experience of a Java GUI application to a native C++ one of comparable functionality. Even if the C++ product uses MFC or somesuch it will still be faster, more responsive and leave more CPU and RAM around for the other apps. Embedded systems often don't have enough system resources to make an interpreter or vm workable at all. Some applications (i.e. games) are engineered specifically to use as much system resources as possible, in order to provide the best possible user experience. A vm might take 2ms per frame and 4MB of RAM (or quite a bit more in some cases) that's a pretty serious thing for a game, you might have to remove something (or several things) to free up enough resources for that, and it would add nothing to the user experience at all.

even though interpreted languages are easier to port cross-platform

In my experience this is not really the case at all. Decent C compilers are available for almost every single platform in existence, most interpreters and vm's are compiled on C compilers. In contrast many vm's are confined to specific platforms, or have only patchy support for platforms other than PC.

Platform support aside I would also assert (without any actual proof) that the consistency between platform implementations for a given C++ complier is far in excess of the consistency between platform implementations for most vm's.

Also, vm languages often need extra (native) runtime modules to access specific API's which are not available through the language itself. This means that if a required runtime module is unavailable for a given target platform, the application developer is basically barred from it until it becomes available (or they write their own native module to access the API).

Finally, vm and interpreted languages almost always require more setup of their target environment(s) than native languages. Most of these kinds of languages have no concept of a linker, so all module binding is done dynamically (i.e. at runtime). Obviously some OS's (i.e. windows) lean towards dynamic bindings for native code as well, but native languages are equally capable of both. When you're writing any kind of consumer targeted software, telling people that they need to download the latest jvm (or whatever) and wait another 20 minutes (if you're lucky) for that to download and install just so that they can start to install your software is a sure way to send them to your competitors... If it doesn't then get them started on setting their CLASSPATH.

often have a shorter development time

This is an arguable point at best. While such languages are often easier to both learn and to start new projects for (i.e. no build scripts etc.) I wouldn't say that there's a clear winner for overall development time. It often depends on what you're trying to write. Generally lots of string manipulation and calls to standard system modules (i.e. file system etc.) are simpler in interpreted languages (provided that you're not trying to keep your memory footprint down) but some other things are easier in native languages (i.e. encryption or math which requires specific and consistent accuracy).

Garbage collection is often cited as a feature of interpreted languages which decreases development time (because developers don't need to worry about memory allocations and deallocations) but garbage collection is also available in native languages, it's just not popular. Also, doing 'advanced' things in interpreted languages is often quite a bit more tricky than their native counterparts (i.e. function pointers - the C# equivalent is far more complex).

In general (l

Re:Downsides of interpreted/vm languages

[Wildclaw]

C# has operator overloading (Some operators like the equal sign are of limits), as well as Unions (Although you need to use C#2.0 and have the code marked as unsafe to be able overlay arrays. For mor information search for StructLayout.Explicit).

I am not that well versed in C++, so I am hesitating on the meaning of globals. If you are talking about global variables, static variables are reasonably equivalent. C# don't have default parameters by purpose. This is compared with VB.Net that does have them. Someone else also mentioned passing by reference. C# supports that with the ref keyword.

Generics in C# and Java are much less flexible than templates in c++. From my experience, the C# and Java developers are very causious when it comes to implementing anything that can construed as macros. I would say that the biggest lack in both C# and Java is multiple inheritence. Both VM engines decided to go with single inheritence, supplemented by interfaces. The C++ const keyword is another thing missing.

Also, the C#2.0 runtime is 23 mb, not 300 mb (unless you are downloading the complete development kit, which only the developer should do)

The biggest problem I have seen with VM languages are bloated and slow GUI. I have written enough Console/Non gui applications in C# to know that performance rarely is an issue. The biggest speed ups that can't be done in C# comes from using SSE and other machine specific code. The C# compilers on the market could provide more optimization though. The Microsoft C# compiler (or maybe it is the VM), is in my opinion quite bad at optimizing nested loops with arrays.

Re:What?!?!?

[dgatwood]

Which is cheaper: spending hours trying to get a 64-bit Perl to work correctly or spending a relatively small amount of effort writing code that does its own memory allocation and deallocation?

Seriously. I have a number of things I do on an almost daily basis in Perl in which I have to do that run dangerously close to VM limitations in a 32-bit process. There are a number of things I would like to do to the technology in question where I run into a wall. This is not web stuff, mind you, but... there are reasons I like to be able to code things in straight C without a lot of outside dependencies....

I also did some rather fun code in PHP once that took ten or fifteen minutes to execute in PHP. I did a straight port of the same code to C and it executed in a fraction of a second. (It didn't work in either language, mind you, but at least it failed very quickly in C.) That's a very extreme case, but such things do happen, particularly when it comes to the gross inefficiency of doing things with associative arrays that would be more effectively written using plain arrays, structs, etc.

Besides, for me doing my own web sites, 100 hours of good low-level programmer time on evenings and weekends are essentially free. (I'd probably just watch TV otherwise.) A few gigs of RAM is actual money.

Re:What?!?!?

[stivi]

You are right. And now try to shift your statement to higher level: replace C with Smalltalk/Java/PHP/... and Assembler with C/C++. Arguing about native languages vs. interpreted languages is like arguing about C vs. assembler.

Every language has its place. Problem usualy is not that a "language is bad", but the problem usualy is the lack of interfaces between languages. Nowdays, each higher level (higher than assembler) language has its own set of libraries, own concpets inside those libraries. Lack of glue leads developers to use one language only for whole project. Or perhaps it is not lack of glue, but lack of interest to use glue...

How it should be? Write fast routines in assembler, glue them with C and provide C libraries. Write application building blocks in C/C++, glue them with Java/Smalltalk/PHP to create applications...

What would be revolutionary for OSS

[ceeam]

$(SUBJ) is if software development would move from native code or P-Code or Java to something that does source compilation stage also in JIT (I am awed with what Psyco does, but I'm sure there are many other possible options). See - it's nice that OOo or Mozilla are open source but it's sure as hell that I don't have dedication to download source for it, dependencies and spend a day or two just trying to compile it. Now - if this software would be available in "runnable source" form then I think we will have 10x number of developers compared to now. As it stays - barrier to entry is too high.

I think at least Python in its _current_ form is suitable for writing an office suit or browser, not to mention "simpler" apps. And I don't see why other languages cannot achieve same level of efficiency.

Real world experience

[thorsen]

I've been making a living contract coding C++ and Qt for about four years now. I've also used Java, PHP, python, and a couple of other languages for various projects. I really like Java as a language, I think PHP is pretty nice and useful and I absolutely adore python. But the C++/Qt combo is what I enjoy most.

I'm very much into cross platform - usually all my projects have to run on Linux and Windows. My experience from this tells me it's not more difficult to do in C++/Qt than it is in Java, but you need to know what to avoid. The Java saying "write once, compile anywhere" is marketing bs. Java apps needs porting, just like anything else. It's even worse for .NET, where Mono only implements part of the environment.

I also work a lot in embedded devices, and in this area the Java and .NET are almost non-existing. Why? Performance. These systems are based on slow processors and always too little memory. But with a little extra care, I can use the same C++/Qt combo to solve the projects here.

Another case where performance mattered: I got a contract to port a .NET application to Qt (this was one of the rare Windows only contracts) because the performance of the .NET app was so horrible it was going to be rejected by users. And the Microsoft engineers who helped this company solve the issues kept saying "the next version will fix all your problems". Well, after three new versions that didn't fix anything, they decided to get rid of .NET and hired my company to rewrite it in Qt. And they are incredibly happy with the result. The application outperforms the old .NET app in every single way. Even on large workstations. For this company, managed code is something they might look at again in some distant future.

The one thing that can get more complicated with native code is deployment. The Java way of packing everything in a single jar file often works really well. With native code you have to care about library versions, binary compatibility, and different OS versions. This is a real problem, that managed code has much better answers to.

My experience is that it is not more difficult to write code in native C++/Qt than in Java. The outcome of it is more difficult to install and deploy, but after it is solved, you will get an application that has a better look'n'feel to it.

Bo Thorsen,
Thorsen Consulting.

Non-native has not even got here yet

[agnel.kurian]

Name 10 apps you use most frequently.

• Now, if about 80% of these apps are non-native you post something like 'The End of Native code?'
• If atleast 60% are non-native, post something like 'Native Code no longer popular?'
• 50% non-native: 'Interpreted platforms on par with Native Code!!' (with two exclamation marks)
• 40% : 'Interpreted Platforms Gaining Acceptance!'
• < 40%: Don't post anything at all. Relax. Try gardening.

/*
As for web apps, hardly anyone uses native code to render HTML but a lot of what goes on behind the scenes such as database drivers, interpreters, zip libraries etc are native (if they work at all). The browser too is native.
So there is really no 'end' for native code.
You see this? This is a C style comment. We're not going away any time soon my friend.
*/

Interpreted code can be FASTER

[poliopteragriseoapte]

As a developer, I notice that the applications I write in Python are often FASTER on large jobs than my C applications.

Why? Because Python makes it easy to use the right data structures for the job. It is trivial to use hash tables, trees, and all that in Python. Not only are such data structures easy to use (a = {} is all it takes to create a hash table), but crucially, they are easy to print, and easy to input on the command line, making debugging a breeze. Yes, C++ has STL, but you cannot match the easyness of creating and printing data structures on the fly in Python (I assume Ruby, etc, are similar).

Thus, in Python I tend to think carefully which is the best data structure and algorithm for the job. In C, I tend instead to be lazy, and use the data structures that are easy to use (what's that, arrays?). As a result, on small data sets, my C code is typically 4-5 times faster than my Python code, but on large datasets, I often get O(n log n) algorithms in Python where my lazyness in C yields O(n^2), and this shows.

As a result, I am now a convert to Python (and I want to try Ruby). The programs I write are faster when it matters, easier to write, no memory leaks, no segmentation faults, no memory management, no worries... there is NO way back.

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.

Re:On the subject of looses...

[zaajats]

Just think how many problems using almost-pronunciation-based spelling would solve.
The only downside is that a great number of slashdotters would suddenly have an unmanageable amount of free time.

Martin Amis, from one of his short stories:
"Over Horzeleej Band there zwam a gloud of gray: nad mizd, nad vag, bud the grey haze of ziddies, and of zdreeds"

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

[famebait]

I have implemented GUI apps in C++, C#, Java, Matlab, and VB. I am seriously looking at Java/Swing

I'f you've wokred wit GUIs in C#, I can tell you right now that you will be very frustrated with Java /Swing. The close similarity allover makes the differences in developer convenience positively glaring. Yes, a lot of it is just syntactic sugar to you language people, but boy do you get tired of writing it the long way when you know how much easier it could have been. The GUI APIs show a similar trend, Swing making you do all sorts of unneccesary stuff before you can get to the point.

The End of Oranges?

[goltrpoat]

There, fixed some typos for ya.

"An average apple tree nowadays holds enough fruit to fill several baskets, weaved in your local apple-centric basket-weavery, which are carried by human power, or simply loaded onto a truck. Particular to Golden Delicious afficionados, the announcement of new apple tree fertilizer means that future apple trees will laugh at the nominal apple load requirements of current baskets (e.g. hearth baskets, berry baskets, ribbed baskets, and gourds). Regardless of the negligible vitamin C per pound hit compared to oranges, major fruit farms, as well as a lot of freelance fruitpickers, prefer oranges for major baking projects even though apples are easier to bake a pie with, often have a shorter development time, and are just as powerful as citrus. What does the Slashdot community think of the current state of apples versus oranges? Is it time to jump in the boat of apples? Do pastry chefs feel that they are losing - an arguably needed - dose of vitamin C when they eat apples? What would we be losing besides lemon merengue?"

Re:On the subject of looses...

[ThJ]

Ai feer it wud saund mö laik ei mix bitwiin e swiidis ef and ekoslovääkiun...

America

[pato101]

America should have been called "Columbia" afterall. :-P Seriously, for me, a spanish guy, "America" may mean "North America" + "South America" or USA depending on the context. This sometimes may lead to confusion...

Re:On the subject of looses...

[ThJ]

And of course Slashdot just HAD to not support Unicode...

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

[Alomex]

Yes, a lot of it is just syntactic sugar to you language people,

Syntactic sugar is a phrase devised by programming language types to justify incompetent HCI design in their pet language. E.g. programmer: "but your choice of using ancient hungarian for keywords makes the language difficult to use in practice". PL-type response: "ah that is just syntactic sugar".

Syntactic sugar is like syrup for pancakes: judicious amounts make them infinetely more palatable, but it does not mean that the more syrup the better.

Re:What?!?!?

[pchan-]

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

You do know that you can use the C preprocessor on any text file, right? It's a standalone program on systems using GCC. You will have to avoid shell-style comments (#), but otherwise it works well. It is a bit weird running Make on your PHP files, though.

echo -e '#define MSG "hello"\necho MSG;\n' | cpp > processed.php

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;

Re:Why Java didn't deliver

[PhotoBoy]

I have to agree, on Windows alone I find the VMs work differently depending on which version of the OS is being used. Of course in the early days of Java, MS did their best to fuck Sun's chances by releasing their own VM that was hopelessly broken and worked very differently from Sun's versions.

I don't see the point in .Net being byte-code instead of compiled either, there is no need for cross platform support because MS don't want to support other platforms. Why they actually let Mono keep going I don't know, you'd have thought they'd shut it down as it's .Net without paying for it.

Theres no such thing as "British English"

[Viol8]

There are many dialects and accents of english spoken in britain and
in just england itself so you can't say there is such a thing as
"british english". However , given the language is called "english" I think
its fair to say that whatever dialects and accents are spoken in england
can safely be called "english" and any spoken in other countries called
  english.

After all, you don't say "french french" when you speak about the french
spoken in france , though you will say "canadian french".

Re:Theres no such thing as "British English"

[Viol8]

That should have read "in other countries called [country name] english"

Re:Theres no such thing as "British English"

[Hognoxious]

After all, you don't say "french french" when you speak about the french
spoken in france

I do, but that's probably a side effect of living in Belgium.

Re:Theres no such thing as "British English"

[seminumerical]

After all, you don't say "french french" when you speak about the french spoken in france

I do, but that's probably a side effect of living in Quebec.

Re:Theres no such thing as "British English"

[ros0709]

Would it be useful to you if it could also differentiate the meanings of the word "pissed" in US and British English?

Re:Theres no such thing as "British English"

[gmack]

I don't know about the rest of Quebec but after living in Montreal these past few years I'd call what gets spoken here "Frenglish" more than I would it "french".

Re:Theres no such thing as "British English"

[rufty_tufty]

While on holiday in spain a decade back we once met a man (from Dover Strangely enough) who could tell where we came from down to about a 2 mile radius thanks to our accents.
The strange thing is this didn't really surprise us because the accent changes enough across our town that we can do it, so the fact that someone else can is not a surprise.

This is also not uncommon in the uk for accents to be this local. I have never lived in a town where the locals could not do this trick (localise a local to within a mile or so based upon his accent).

So when it seems that all american's think the english have either a cockney accent or an RPS (or whatever it's called) accent, this is somewhat annoying.

Re:Theres no such thing as "British English"

[blackest_k]

I like this discussion, but it seems to me that English is a general term for a language group which covers countless variations in grammar spelling and pronunciation. Language is continually evolving.

Trying to define a particular English variant is difficult if not impossible, British English is a term to refer to a standard of English usage in Britain or perhaps "School English" that is taught in Britain however outside of the class room many variations occur. I would think USA Schools teach an American English form which is distinctly different from British English School form and different from local usage as well.

I would be surprised if all Welsh speakers used (outside of School) the same Welsh variant.

Legal English is yet another variant which attempts to hold language to a standard which is distinctly different to that spoken by the general population.

Programming languages closest relative in the outside world is probably Legal English. The usage of a semi-natural language, such as C C++ Java Pascal Lisp ect, is held to precise standards (within a particular compiler at least) and I think this is why there are so many people who foam at the mouth within forums such as slashdot when they see syntax errors within other peoples postings.

I can't help but wonder if there is a correlation between the favoured choice of programming language of an individual and the amount of ire felt by them whilst reading the syntactically error prone postings on slashdot. (I would guess assembly coders might be at one extreme and VB programmers at the other).

perhaps this also gets to the core of native vs jit arguements the problem with Jit is that it is dependent on the implimentation of the interperator.

Re:Theres no such thing as "British English"

[tolan-b]

No sorry, the English spoken in England is called 'English'. It is the language of the English.

Americans speak an American version of English, hence 'American English'. And so on.

Re:Theres no such thing as "British English"

[Tango42]

That only works in areas where people don't move around much. I don't know anyone that can do that in the south east (of England) where I live - there's just too much movement. You can tell someone is from the general area, but chances are they haven't lived in the same town their whole life, so it's impossible to be very precise. I guess it works better with older generations - I know people that have lived in the same house their whole life, but they are definately a minority.

Re:Theres no such thing as "British English"

[rufty_tufty]

Well I was taking a bit of liberty there...
I've lived in the south east for a while myself, and in 2 of those places the locals knew the local accents (Harlow & Kings Langley).
Currently in Cambridge where it's a little more of a mix, but there is still the difference in the accents between say Ely & Kings Hedges.

Re:Theres no such thing as "British English"

[MysteriousPreacher]

Pissed is the least of our worries. Think of the poor English guy who walks in to a bar and asks the barman if it's okay to smoke a fag.

Re:Theres no such thing as "British English"

[MysteriousPreacher]

Programming languages closest relative in the outside world is probably Legal English. The usage of a semi-natural language, such as C C++ Java Pascal Lisp ect, is held to precise standards (within a particular compiler at least) and I think this is why there are so many people who foam at the mouth within forums such as slashdot when they see syntax errors within other peoples postings.

I think you may have hit the nail on the head there. We need a survey of grammar Nazis to determine their language of choice.

Re:Theres no such thing as "British English"

[CamonZ]

being an assembly coder i can say that i don't care how you mispell any word.
p.s. i think the ire/language relation should be between asm and ruby

Re:Theres no such thing as "British English"

[tvon]

I think you mean "United Statesian English"

Re:Theres no such thing as "British English"

[tolan-b]

Oops! Yes quite right. or just 'Yankee English'!

(Yes that was intentionally ignorant)

Re:Theres no such thing as "British English"

[Richard Steiner]

I suspect some of the folks here in Atlanta would take exception to that term. :-)

(Given what General Sherman did to this state, I can't say I blame them)

Re:Theres no such thing as "British English"

[LunarCrisis]

It's called Joual:

http://uncyclopedia.org/wiki/Joual

Specifically:
"The province's primary language, Joual, is a curious mix of French and gibberish known to many as franglais. The origin of the word Joual is from the french word for horse which is cheval. Franglais is to european French as Irish accent is to English. Basically, quebeckers found a way to move their mouth less while producing approximately the same sounds, leaving more energy to add more syllables, which they typically invest in cursing."

The truth of this leads me to beleive that uncyclopedia isn't doing it's job =).

Re:Theres no such thing as "British English"

[tolan-b]

I did quite clearly say it was intentionally ignorant! :)

Re:Theres no such thing as "British English"

[hesiod]

> So when it seems that all american's think the english have either a cockney accent or an RPS

Not sure what RPS is supposed to mean, but if you truly believe all Americans think that you are horribly, horribly misinformed. It seems that so many of the things people hate about the American public are based on misconceptions (or outright lies, which I don't think is the case here). There are enough GOOD reasons to hate us that making shit up makes others seem petty.

Re:Theres no such thing as "British English"

[rufty_tufty]

Not quite RPS, but I was close:
http://en.wikipedia.org/wiki/Received_Pronunciatio n

I'm sure not all American's think that, just merely from watching american TV it seems like that at times.

But if I did that I'd assume 90 % of the americans are white but with every social group having no less and no more than one black man.

Re:Theres no such thing as "British English"

[lump]

"Pissed is the least of our worries. Think of the poor English guy who walks in to a bar and asks the barman if it's okay to smoke a fag."

Thank you for that MysteriousPreacher, I needed a good laugh. That was excellent.

For the record, most of us here in New Zealand speak "real" english (albeit with a funny accent). People say a language must evolve, but that implies some kind of improvement, and most of the changes in US english are more like watering it down, as far as I'm concerned. ie: favour favor, colour color, etc. What are we, preschoolers?

Re:Theres no such thing as "British English"

[Hognoxious]

has not been as much corrupted by English yet.

You appear to have misspelled "enriched".

Re:Theres no such thing as "British English"

[MysteriousPreacher]

Heh heh.

Looking forward to the day when formal legal letters will inlude sentences like "OMG, UR IN TEH TROUBLE, MY CLIENT WILL SUE YOU NOOB, LOLZZZ!!11!!1!!"

Evolution at work.

It seems to be about making the language easier but I don't think it was that difficult to begin with and removing the letter u from words like flavour messes up he pronounciation. All Americans I've heard say this word pronounce it with the french sounding ending 'flaveur'. I've heard no-one pronounce it with a real phonetical sound 'flave-or'.

Mind you, it's possible I've just met the wierd Americans.

Re:What?!?!?

[SillyNickName4me]

What is cheaper now, a 2gb RAM stick or 100 hours of good low-level programmer time?

100 hours of work payed for or shared among many users will be a lot cheaper then all those people buying more memory.

Re:What?!?!?

[SillyNickName4me]

I think a lot of that ram is the incoming data waiting to be written to the cpu and outgoing data held in memory to be sent out to others...

Written to the cpu?

But what do I know.

Indeed.

My challenges for flamers!

[DimGeo]

My point: use the right tool for the right job. C++/Native is good for large-scale computations involving floating-point calculations over large arrays of data. C#/Java are faster on data structures manipulation programs like formula translation algorithms, etc.

Here are my two challenges for everyone.

1) The challenge for those who claim C#/J#/Java is faster than C++
Rewrite my Win32 Tetris with software background animation in a JIT language and make it faster than the C++ implementation. (BTW, the initial version was written in Java/SWT, then Java/AWT till it finally got ported to C++/Win32).

2) The challenge for those who claim C++ is faster than C#/J#/Java
Rewrite my SQEMA (a modal logic algorithm) implementation in C++ and make it faster than the Java implementation.

Here are the sources of the above-mentioned applications:

http://myjavaserver.com/~dimitertg

Side note: Don't mind the intimidating license of SQEMA. I will change it to something nice when I get to 1.0 (that should be next week since it must be completed by then).

I have tried both challenges and failed miserably.

As for the prize for those who complete the challenge - well, nothing, except the pride you may take in what you have achieved.

Re:My challenges for flamers!

[DimGeo]

Actually, using memory pools might help a lot for the second challenge. And I haven't really tried hard yet, so there, you have a chance :) I will work on it myself - later when there is time.

Re:What?!?!?

[dolmen.fr]

GCC is optimized for portability, not for performance.
Some performance optimizations that are included in other compilers are not in GCC if they would break GCC code portability.

Keep that in mind when benchmarking GCC.

Re:What?!?!?

[dolmen.fr]

Also might just be java swing being bloated, I think azureus has a command line version...

Azureus doesn't uses Swing but SWT which uses more native code.

Native Code?

[pushpop]

I think there'll always be a need for native code, as there are some things you simply cannot do with interpreted/JIT languages. For instance, I'm working on a WIN32 application in C++ which performs a low level analysis of a hard disk drive and displays the results in a dialog box. Whatever about Swing, the low-level stuff is nigh on impossible in most interpeted languages. You also have to remember that most of these languages provide a high level of abstraction over the actually hardware your programming, so it's impossible to gain an understanding of what your program is doing in memory and in CPU registers when EVERYTHING is shrouded in namespaces and classes provided by the language vendor. One option is to use a native interface like the JNI, but I used that when developing my disk application for Unix and it was fairly horrible.

More about Java

[Roy van Rijn]

Please allow me to jump into all this Java discussion. In my opinion Java is becomming more and more cluthered and obese. Every new version they put in a lot of new functions but also want complete backwards compatibility. Another major problem is those JVM's that are drifting away from eachother, some applications need their own special JVM.

In the +/- 16 years of development you can't just keep adding stuff, it just becomes to big/large. The concept is (imho) very good, and they are moving in the right direction. The thing we need is a major company (like Sun) that takes the risk of dropping all backwards compatibility and make a whole new version with good straight forward rules and syntax.
When that happens, with a good VM and JIT, people will start using it..

doesnt make sense

[kadnan]

why do i force users to download 30MB .net framework to run 300KB IE toolbar?

name one major commercial app

[petermgreen]

thats NOT written in native code.

java and .net are certainly taking vbs share of the desktop market (primerally internal apps that users are forced to use) as well as a large chunk of the server side but they don't seem to be touching the major commerctial apps!

Re:name one major commercial app

[easter1916]

Quest JProbe. The TIBCO suite of tools. Both commercial, both excellent, both written in Java.

Re:name one major commercial app

[gatkinso]

I believe "major" was a criteria of the posters challenge.

Re:name one major commercial app

[gatkinso]

Google Earth (I think).

Re:name one major commercial app

[easter1916]

And both of those are "major" in terms of complexity, mission-critical use (TIBCO), performance...

Keep in Mind...

[Strake]

The line between interpreted and compiled, however, is blurring. Languages that are traditionally compiled can sometimes now be interpreted, and vice versa. There exists both a C interpreter and a Lisp compiler, for example. One could write a performance-hungry program in, say, Perl, run it normally (using a Perl interpreter) for testing, and compile it when it's ready for use.

Also, interpreted and compiled languages can play nicely together if you let them. Guile Scheme, for example, can be embedded in a C program. There also exists a feature of Perl that allows the use of C libraries from Perl code. There is nothing stopping one from writing the core of a program in C and allowing extensions/plugins to be written in Scheme; in fact, several programs (i'm looking at you, GIMP) take this approach.

End of Native Code? Er, no

[awol]

Many excellent points by many posters about the "life" left in native code. Let me add my $0.02. We have a system that has a fundamentally non-parallel* execution profile where it is hard to determine the "full" scope of the objects that will be touched by a given transaction. We keep all our data in memory and so we are starting to care about the organisation of a data structures so that we can keep more and more of them on the L1/L2 cache to avoid having to go to memory to get records that we just looked at (its just too slow). From a singe processor (obviously a multi processor machine but one of them used to 100% by the system) we seem to be seing around 40K transactions per second.

With that as background, native code to us means that we are able to control, influence and ensure the code path that each transaction is executing and thus squeeze as much as possible out of the single transaction path that we are constrained to use. It also means that we can truly _find_ the sluggish parts of the most commonly executed code and make them X% faster thus making the system almost X% faster itself.

*Whether our problem is parallelisable or not is an interesting question but since it is like that the most popular objects will be involved in the vast majority of transactions then it is very hard to think of a way that paralleising the process will give us any real benefit since we woul have to handle the locking/deadlocking and race conditions for a fractional increase in performance, all of which is probably going to cost more than that fraction for all the other transactions as well.

Are you sure about performance?

[Branko]

An average PC nowadays holds enough power to run complex software programmed in an interpreted language (...)

Apparently, Intel does not agree with you:

http://www.behardware.com/news/lire/10-06-2006/#82 15

If even a relatively simple GUI of driver control panel is considered unsuitable for "non-native" technology, then it is understandable why more complex desktop applications are still far away from being routinely developed in such languages.

In my personal experience, I'm yet to see "non-native" application that does not feel sluggish compared to a similar native application.

Linux is pretty snappy as well.

[jnelson4765]

It takes a couple of seconds for medium-complicated stuff to fire up on my P3-800 at work, but nowhere near as bad as Windows. Linux treats it the same as perl or python - just uses the java runtime to execute it.

My recent experiences with some rather well-coded Java stuff has even made me give up my native prejudice against it (formed in 1998-99, when it truly did suck). The GUIs went from hideous to okay...

End of Native code? It's all about the app

[garfieldbarnett]

The key here is the application you're writing - The vast majority of enterprise apps do more or less the same thing -
1) They put a form onto the screen
2) They wait for some user input
3) They perform a database search on the basis of that input
4) They perform some basic math (multiplying the unit price by 1.05 to add sales tax for example)
5) They put some data back into the database.

When you look at the app's behaviour, it's actually waiting for something most of the time - Waiting for the user to press a key, or for the database to return some result.

It doesn't matter how fast your code is - All apps "wait" at the same speed.

The scenario I've shown above may be generic - but it's what the majority of enterprise applications do. In this scenario it's very hard to justify writing the app in a 3GL or Assembler.

There are plenty of other scenarios, though, where no matter how fast processors are, or how cheap memory is, there is going to be an advantage in writing native code. Any very complex math, massively parallel task management, device drivers etc will, in general, be more suited to a lower level language. But even here, I think that exceptions can and will emerge - Domain specific higher-level languages will increasingly do a "better job" of creating fast code than we can.

In practice higher-level languages, scripting languages, 3gls and Assembler have co-existed for decades and will continue to do so. Better approaches to interfacing and re-use should actually make this even easier to do - So we'll use higher level tools and scripts to tie things together, paint UI's and do lots of groovy IO and presentation layer stuff, while invoking services that have been implemented using all sorts of lower-level techniques.

There's a cultural factor too... I've seen evidence of "language machismo" in my time... developers insisting that their hand crafted code will "always be better than that nasty generated stuff" - In my experience, while this is sometimes true, it isn't always the case. So perhaps we need to exercise a little more circumspection when we sit down to make our choices?

Re: C++ is bad? Move to Java or C# !

[gigi]

Majority of native-language development is still done in C++.
I agree with Animats that C++ si full of security holes - the lack of checks is what gives C++ the 'native speed'.
But after some years of dealing with C++ memory leaks, buffer overflows, smart pointers going dumb, incomprehensible templates,
code which compiles but does nothing (see below), you want change. More C++ rants here and here.
And now Bjarne Stroustrup wants to create another version C++09? That's just wrong.

My suggestion: Think about moving.
Move to Java via http://jazillian.com/trial.html,
or translate your code to C# on code2code.net.

Disclaimer: code2code is my web site.

PS. Example of code that compiles with GCC and microsoft's CL.EXE but never does what it seems to do -
It never calls fct2():

int fct1();
int fct2();
 
int main()
{
    int x = fct1(), fct2();
}

Re:What?!?!?

[Branko]

If I could find such a thing, I'd probably still write all my CGI programs in C instead of only writing the most performance-critical pieces in C. As it stands, it's enough of a pain to make C CGI code work correctly that it isn't worth the trouble for me, and so I suffer the performance hit (generally of PHP).

You make some good points, especially about fragility of C on server-side, but I think you are missing the main reason of why CGI in C (and CGI in general) is sub-optimal solution in most circumstances:

CGI does not provide state management.

Basically, you end-up with having to do all the initialization steps all over again for each HTTP request - you are unable to retain non-trivial state, such as database connection or COM reference, across the user session.

We had this particular problem with one of our recent project that exposed certain PTC Pro/INTRALINK (which is a kind of CAD version control system) functionality to the Web. First version of our application was CGI written in C++ that talks directly to Pro/INTRALINK API. We ended up having to reestablish Pro/INTRALINK connection each time user requests a new page. New solution, which is combination of ASP.NET and COM wrapper around Pro/INTRALINK API, is able to initialize COM object (which then connects to Pro/INTRALINK and does some other one-off tasks) at the start of the user session and then retain reference to this COM object until user session expires.

Speed-up is several orders of magnitude.

Re:What?!?!?

[jacksonj04]

If performance of PHP is absolutely critical, you can use one of the Zend packages to pseudo-compile your code. From what I've seen there is a noticeable improvement on any script which does anything above 'light' work.

Re:On the subject of looses...

[Marlow the Irelander]

Ai feer it wud saund...exactly the same, just be spelt differently.

Re:My head's going to explode!!!!!!

[stepanxol]

Actually, non-native speakers are usually much more careful about the spelling, since they were already able to write when they learned the language. Also, speaking personally, I've always been unable to learn (ie remember) a new word without figuring precisely in my head the way it was written. That said, "loose" is nothing compared to the "its/it's" and "they're/their/there" disasters... ciao S

Re:On the subject English, Welsh, Netherlands

[zoney_ie]

The Kingdom of the Netherlands, comprising Netherlands, Netherlands Antilles, and Aruba is a federation established 1953.

OK, perhaps that is a *bit* pedantic. Even so, the Netherlands has been a parliamentary democracy since 1848. The US is still older.

Ask Microsoft

[jspraul]

Is there any truth to the rumor that Windows Vista had big chunks of managed code ripped out because of performance issues? If that's what happened, they certainly couldn't admit it...

finally somebody gets it

[nobodyman]

the obvious answer is that native vs interpreted is basically simply the balance of developer cost versus cost of end-user resources

I guess I've become "old enough" to recognize the cycles in computer science debates and schools-of-thought. Unfortunately, it seems as though far too few people recognize these patterns and get caught in the same inane argments.

• start here: Assembly eplaces many tasks formerly accomplished in hand-written machine code. But I can write much smaller programs by manually plugging/unplugging these-here vacuum tubes
  
• "macro-assembly" allows programmers to code for different cpu instruction-sets simultaneously. But, but... the hc11 has an extra 16-bit register than the 6809, I can shave 2 bytes off your macro-code, you lazy bastard!
  
• C replaces assembly in the majority of roles traditionally set aside for assembly. Your sacrificing all that speed to save time. (snickers at your times-two multiplication expressions)
  
• c++ blah blah c. blah blah syntax sugar blah blah ...
  
• ....
  

Wash rinse repeat. In 10 years the Java camp will mock the young 3DUML-on-rails punks that use tactile feedback gloves.

Easier to port??

[Jessta]

The JIT compilers and virtual machines don't make it easier to port between platforms.
Java code only runs on the java virtual machine, porting that to the python interpreter or .NET is difficult and time consuming.

If you are refering to being able to run the code on different hardware platforms then software virtual machines make different hardware platforms pointless in creating because to the software they are all the same.

Portability is silly if it makes you unable to take advantage of any of the features of the platform you're developing for.

- Jesse McNelis

It's All A Nefarious Conspiracy

[smcdow]

Here's my tin-foil hat theory:

In a nutshell, programmers and computer scientists are uncomfortable with the fact that there's actual HARDWARE in the system, and this somehow taints their pure, beautiful software designs. That is to say, they unconsciously can't stand that software has to run on hardware. So, they've invented "virtual machines" to abstract away the icky hardware with all of its yucky "engineering hacks". Of course this is justified with the old, battered strawman of "portability". But really it's all about not having to worry about registers, MMUs, memory addresses (physical and virtual), I/O ports, etc.

But if you forget that ultimately, software is nothing more than machine code being interpreted by a CPU, then you've lost a huge part of what computers are all about.

Joel Spolsky says it best (OK, it's dated, but substitute Java for Pascal, and it still applies):

I've discovered that understanding pointers in C is not a skill, it's an aptitude. In Freshman year CompSci, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their Atari 800s when they were 4 years old. They are having a good ol'; time learning Pascal in college, until one day their professor introduces pointers, and suddenly, they don't get it. They just don't understand anything any more. 90% of the class goes off and becomes PoliSci majors, then they tell their friends that there weren't enough good looking members of the appropriate sex in their CompSci classes, that's why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. This is an aptitude thing, not a skill thing - it requires a complex form of doubly-indirected thinking that some people just can't do.

The conspiracy is that the software industry has moved in a direction to accommodate people who don't understand pointers. To acknowledge pointers would be to admit that there's machine-addressable memory in the system, which would be to admit that there's hardware in the system.

And we can't have that, can we?

Re:It's All A Nefarious Conspiracy

[bnenning]

Your post combines amusingly with your sig.

Re:It's All A Nefarious Conspiracy

[Junks Jerzey]

In a nutshell, programmers and computer scientists are uncomfortable with the fact that there's actual HARDWARE in the system, and this somehow taints their pure, beautiful software designs. That is to say, they unconsciously can't stand that software has to run on hardware. So, they've invented "virtual machines" to abstract away the icky hardware with all of its yucky "engineering hacks".

Nonsense. Embedded systems programmers deal with the hardware directly, and there are more embedded systems programmers than desktop PC programmers.

The reason for VMs is simply that, unlike a little 8051 CPU running a fuel injector, desktop hardware is not constant. Even on x86 systems, different models of Intel and AMD chips have different performance characteristics. You can't just pick one CPU and hardcode everything for it. You'd go insane. You isolate yourself from that level of things.

Java developers

[Joce640k]

There are some successfull java apps. Azeurus and limewire/frostwire are just 2 I know of

...and they're awful. The "native equivalent" programs totally kick their bloated butts.

Java apps are written by developers who only care about themselves, not their customers.

Re:Java developers

[Baki]

I use azureus regularly while downloading at 500KB/s on 40 trackers, very complex screen with lots of updates, charts and the like. I know of no native client that comes even close.

Re:Java developers

[zootm]

Java apps are written by developers who only care about themselves, not their customers.

Nonsense. What if they have a customer who cares about reliability? Writing it native will increase the cost hugely, compared to Java. There's plenty of reasons to write things in Java. The fact that the default GUI toolkit is lacking compared to the rest of the platform (and since it's the focus of current development on Java, it's likely that this is not a trend that will continue).

Furthermore, the only native alternative to Azureus I've seen which comes close is uTorrent, and it's not cross-platform, and specially designed to be lightweight so it misses a lot of features.

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

[SenseiLeNoir]

Its funny, but us native "english" (ie those from england) actually can still read that even without havign to pause!

Maybe us english are more aware of other peoples use of spelling that other users of english?

Re:Euro-English

[Yizzerin]

Huh...that sounds remarkably like the Chicago Tribune's attempt to simplify the Inglish Langwaj a number of years ago :-P. And, yes, it failed utterly...but it did give us "catalog"...thank goodness for that!

Re:Euro-English

[Doc Ri]

Well, I have to confess I did not make that up myself. Ironically, I am german (I live in England, though) and the Euro-English post was sent to me by a friend from Bulgaria this morning. It fitted so well, I could not resist the urge to paste it in.

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

[SenseiLeNoir]

That was the pun. To sound like german

Re:Euro-English

[andymadigan]

I figured.

Re:Euro-English

[sr3d]

is this idea originated from the novel 1984?

Re:Euro-English

[Modorf]

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.

Has anyone else noticed the issue with paragraph? The 'c' in changes shouldn't be there, since it was removed in the last paragraph with either a 'k' or 's'. What is it?

Re:Euro-English

[rolandog]

Agreed, also this paragraph:

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!

Has a conflictive 'ch'... I propos a 'shange' to ze rulez: 'shange' 'ch' to 'sh' in order to eliminat ze pronunsiation isues.

Re:Euro-English

[rolandog]

Gahh, Ze speling eror:

Has a conflictive 'ch'...

Korrekt sentens:

Has a konflictive 'ch'...

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.

Re:Euro-English

[mindmaster064]

Atclulay in the fturue we wlil gvie up on sfecipic senpillg baecsue it dseont mtater.

(just an observation)

- Mind

Re:Euro-English

[Bastard of Subhumani]

The 'c' in changes shouldn't be there, since it was removed in the last paragraph with either a 'k' or 's'. What is it?

Bzzzt, wrong. In the ch combination it's acting neither as hard c nor a soft one. The ch is in fact a workaround for a sound that didn't have its own letter.

IIRC, some languages count certain combinations as separate letters - Ll in Spanish? Makes sorting a pain in the ass.

Re:Euro-English

[Bastard of Subhumani]

what does it mean if I, a Frenchman, can also read that without having to pause ?

As pointed out below, it sounds like German. So what it probably means is that you learned it from your mother or grandmother, both of whom were very familar with it.

Re:Euro-English

[Bastard of Subhumani]

Is the first time that someone has WHOOOOSHed himself?

Re:Euro-English

[andymadigan]

actually I posted that for the idiot 13 year old americans who browse the site and can't name one country that borders Germany.

Re:Euro-English

[epee1221]

Perhaps we kould replas "ch" viz "tsh."

Re:Euro-English

[boteeka]

It's a known fact that the screwed up order of the letters in a word doesn't make it much more hard to read as long as the first and last letters are in the right place. Even for me it's easy to read, being a native hungarian speaker.

Re:Euro-English

[treeves]

Wir denken dass du bist ein Karma-Whore!
Und zat vas nicht zo funny!!

Re:Euro-English

[Doc Ri]

You must be new here.

every instruction is important

[eneville]

I personally think that the cost in watts to execute an interpreted program is greater than a native binary. Shouldn't we be thinking about the electrical cost? Surely we should be burning coal/gas for more useful things rather than some glitzy program.

Still going to be awhile.

[mattgreen]

I have yet to be impressed by a Java application on the desktop. Everyone cites IntelliJ as a great example of Java on the desktop. It makes me cringe when it has to garbage collect occasionally, pausing for a couple of seconds. (GC may be faster than manual memory usage over the long term, but if it stops the user from getting anything done, it is slower in their eyes.) It consumes, on average, two hundred megabytes of RAM. The interface mimics a native application, getting it wrong in several places. Several common keyboard accelerators just do not work.

We need better native languages, thats all. D looks like it could step up here and fill that gap.

Re:What?!?!?

[Adam Hazzlebank]

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.

I had a similar situation. Used XMMS for a while, then went back to:

cd music
mplayer *

for it's speed...

This question is flamebait

[flithm]

To merely ask this question shows that you've never done serious amount of real work programming.

First of all every problem has a tool that's going to solve the problem best. Sometimes it'll be java, sometimes C, C++, python, ruby, php, etc, etc.

And second of all JIT compiled or virtualized languages often offer little benefits (in terms of what you've prescribed -- which is very little) over natively compiled languages. What I mean is... there's nothing inherently "better" about virtualized code. It's great in certain cases but that's it!

Did you even think about the question before asking it? Would you write a top-tier 3d game in java? How about an office suite in python?

The answer is no, and no. Not because java and python are bad (in fact they're great!), but rather because there's another tool that's better suited to the job.

Think before asking. It's a sad day when this makes it to the front page.

Re:This question is flamebait

[flithm]

It's too bad more people won't see this post. Good job. All excellent points and I couldn't agree with you more.

I wish there were more programmers out there who really understood all of this.

This is a fake dilemma

[djelovic]

This is a fake dilemma.

Languages compiled into bytecode can be JIT-compiled into native code, or they can be pre-compiled into native code using a utility like Microsoft's NGEN. And when you are pre-compiling you have all the time in the world to optimize.

In a small but non-trivial program you can usually get C++ to beat Java and C# by throwing away all the high-level features and programming in what can be called "C with templates". But as soon as you start relying on, say, std::basic_string you may get surprised to see that C# and Java are winning. Java and C#'s GC-heap allocated strings are faster than C++'s basic_string if you use them in data structures because in Java and C# you only allocate the string once and pass it around by reference, where in C++ the each copy of basic_string is either going to allocate separate copies of its contents or do thread-safe reference counting which is unfriendly to the processor's cache.

I can also provide examples where real-world C++ will provide significantly better performance than Java or C#.

On a real-world program the performance of C# or Managed C++ is going to be roughly the same as the performance of C++, while depending on the problem Java may trail a little bit because it lacks structures so some data cannot be packed as tightly thus leading to more cache misses.

To see an example of C++ and C# being pitted against each other on a real-world problem take a look at the follow thread:

http://blogs.msdn.com/ricom/archive/2005/05/10/416 151.aspx

As I said, this is a fake dilemma. A more interesting question is how does the performance of mostly dynamically typed languages (Python, Ruby, Lisp) compare to the performance of statically typed languages (ML, Java, C#, C++)?

Peter Norvig has some numbers from four years ago:

http://www.norvig.com/Lisp-retro.html

On a real-world problem without external bottlenecks (database, network) dynamically typed languages can expect to be between two and five times slower than statically typed languages, though the trend is expected to worsen somewhat due to the expanding gap between the speed of the processor and main memory.

Also note that Lisp has by far the best performance among the dynamically typed languages. Companies that write Lisp compilers have been working on the problem far longer than the authors of Python and Ruby, and have significantly better type inference engines and compiler back-ends.

Dejan

Re:This is a fake dilemma

[djelovic]

I use them. References are mostly used for passing things by reference, but that's worthless for data structures. (Plus, they tend to play badly with templates.) Consider a case where you have two hashes that use mostly the same basic_strings as keys. Those two are going to either store separate copies or do reference counting on strings, which, as I explained, are both bad for performance as compared to .NET and Java strings.

Or I can just use char*, but then I can forget about automatic memory management. Since that's very error-prone I prefer to do it only for performance-critical sections of the code.

Dejan

Re:What?!?!?

[gnufied]

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

Me too...but the news is at least Amarok is written in C++, and i find Amarok and Banshee comparable in speed.So...where are we? Native code is not necceasrily fast.

But Amarok is still a lot popular..there are speed/memory/CPU freak inside all of us..who want to run "free -m" or rather set that as PS1 itself..or do top or run some other CPU/memory monitor.

Basically, If we have 1GB ram and lets say FF and Amarok together takeup 300MB and we have some 400MB free...then there are freaks here...who would switch to XMMS, because they think...what the heck Amarok is taking sooo much of memory. Its psychological and have felt myself sometimes...are you gonna take that "free memory" to your death bed? You have a sufficient fast system with Suse10 but you get this constant "need" to compile Gentoo on your notebook, so as to save CPU cycles and memory. Few guys...who advocate native code here...are just speed freaks like this....they dont care how user friendly or useful a program is, but they are gonna dump it because it takes memory and curse the hell outta plugin engine/scripting engine supported by that app.

And somebody talked about gaming apps...agreed they will be written in Native languages mostly, but just write the AI logic for me in one of those big games in C. Will you? Ha...second life...runs almost >2000 script threads in their games.There is a place for everything..just dont curse interpreted languages yet.

I am not sure..how interpreted languages will scale once multi-core and cell architectures take over the world..i don't know basically.But can't we have runtimes written specifically for those architectures...and may be they will provide us new PARAMS to optimize the interpreted code.

And like M$ bashing, one of these days..everybody would dump some shit on ruby on rails.People would compare it with PHP..and what not.Somebody asked about a high load server and who is stupid enough to write it in interpreted languages? Well...we are working on a application server almost entirely written in ruby ( parts in C actually, which were not doable in ruby) and it works as charm.

Re:What?!?!?

[gronofer]

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

I don't think it's true to describe Perl as an "interpreted language". Firstly because it's compiled, at run time before execution. Secondly, and more importantly, it's not a language. It's line noise.

This will be the end!

[anton.baula]

The end is coming. If we complete our project - http://gotdotnet.com/Workspaces/Workspace.aspx?id= cc3191af-1b3c-425c-a21d-4729196ec37e The idea is to produce mutable OS core with MSIL to x86 compiler build in it. Join.

C++ is like this one Tom and Jerry cartoon...

[Mingco]

C++ likes to hide things from the programmer... There are so many cases of this, I won't even list them to prove my point. If you're a C++ programmer, you'll know what I mean.

If you're not a C++ programmer, then the best way to describe it is like this:

There was a Tom and Jerry cartoon where Tom finally catches Jerry in his hands. As he peeks into a hole made by his fists, he sees Jerry peeking into his own tiny hands. Tom is curious what is in Jerry's hands and tries to look, too. Jerry pulls his hand away and hides it out of Tom's view. Now Tom is really curious and has to kindly ask Jerry to show him what he's hiding in his hands. Jerry then gets his fist near Tom's eye and then gives him a big sucker punch in the eye and runs away.

Tom is the programmer (you) and Jerry is C++. You *think* you have control. But when you want to look very closely at things, then Jerry won't let you. You have to do a few things "against the spirit of the language" in order to get your work done (or else have a very costly rewrite for very marginal additional features.) After you have done this dirty deed, Jerry will sock you in the eye some time later. You don't know when, and you think you got away with it, but it'll happen... usually before a critical deadline because that's when the highest volume of code changes occurs. Of course, you feel kind of dumb that Jerry did this to you. But there are so many countless ways, you can always get caught by a new one, and then eventually he tries an old trick on you that you forgot about. An experienced programmer will sort of just accept that this abuse is part of why he gets paid so much.

C++ is like this Tom and Jerry cartoon where Jerry sucker punches Tom in the eye. Until we invent a language that doesn't do that, we will be stuck in this prehistoric age where future generations will look at our existing programming languages in puzzlement in the same way as we now look at doing math in Roman numerals as peculiar and unintuitive.

Whether the code itself is interpreted or native compiled is irrelevant to our progress in software development.

You would think that by now someone would have invented a better language to replace all of our existing ones. But then again, you would have thought that the Romans would have invented a numeral system that allowed them to progress in mathematics to a point where they could understand how their multiplication tricks worked:

http://www.phy6.org/outreach/edu/roman.htm

But that never happened, and similarly, Western civilization may expire before we have a competent programming language.

Eve Online

[CyberNigma]

I think Eve Online (in its current state) goes to show that interpreted languages can be a favorable choice to develop in. From what I have read, it uses Stackless Python extensively, which is what they are claiming makes the online game as fast as it is (c/c++).

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

[zootm]

To be fair, delegates (which is most likely what is being discussed) are not syntactic sugar. They're a feature of the CLR allowing one to treat functions as objects. Although Java and C# are not very different languages (to say the least), delegates are a language feature of C# that Java could really use (many people use anonymous classes or lots of seperate classes with single methods to achieve what can be done with simple methods in C#), particularly for GUI functions.

I agree though; "syntactic sugar" is a term that is bandied around altogether too often. Syntactic sugar is accused of reducing a languages base simplicity to gain the advantage of making a specific use-case simpler, but it's not as simple as that in practice. Some "syntactic sugar" extends well universally and acts to enhance the language — it's a question of good design.

Negligable performance hit my ass!

[ameline]

For numeric intensive code it's more like a 3x hit for .NET. And yes, I have test cases that measure that.

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?

2x speedup, not 5%

[Chuck Messenger]

... but there'll always be problem spaces where a 5% speedup pays huge dividends.

Try 2x or more speedup. See the Programming Language Shootout.

Re:2x speedup, not 5%

[Pseudonym]

First off, the programming language shootout does not represent real code, and the maintainer knows it. (Sure, my language sucks at writing an MPEG compressor, but look how fast I can do an insertion sort!)

Secondly, of course it depends on the task. But the general rule applies that the art of software performance is a tradeoff between programmer time and computer time, and programmer time is always more expensive. Qualitatively, any investment of programmer time needs to pay for itself several times over in computer time to be worth it.

This is why web applications are usually written in interpreted languages. When your application runs at the speed of the network, there is often computer time to spare, so it doesn't pay to invest a lot of programmer time. In such a situation, higher-level languages win on the ROI analysis.

Re:2x speedup, not 5%

[Chuck Messenger]

First off, the programming language shootout does not represent real code, and the maintainer knows it. (Sure, my language sucks at writing an MPEG compressor, but look how fast I can do an insertion sort!)

Sounds like special pleading. The site uses many (dozens, even) of different algos to make the comparison. You can't so easily just wave away a 2X performance difference. I agree the site is far from perfect. For example, the Intel C++ compiler is shown to be much slower than G++, when in fact, on an Intel processor, it is significantly faster. Who knows why the site's numbers are off -- maybe he uses an AMD processor...?

Anyway, it's _possible_ that that explains everything -- the site maintainer just doesn't handle Java right. Java's just as fast the compiled languages. But I very much doubt it. I think it's much more likely the explanation lies in the fact that Java uses a VM.

Secondly, of course it depends on the task. But the general rule applies that the art of software performance is a tradeoff between programmer time and computer time, and programmer time is always more expensive. Qualitatively, any investment of programmer time needs to pay for itself several times over in computer time to be worth it.

That's fine -- use your language which is X slower but Y% faster to develop. Reasonable values for X and Y will vary by application area. Some apps, you just utterly don't care how slow they run. All that matters is developer time. In many application areas (in particular, the ones I generally work with), performance matters _alot_. I wouldn't accept _very_ slow developer times to get marginal speed improvements. But if, for the sake of argument, C++ takes a little longer to develop than Java, but delivers twice the performance, then I'm going to end up using C++.

Consider this: when your language is slow, it will often lead you to try performance-enhancing design solutions. If your language is inherently fast, it will let you get away with simpler (hence faster to develop and easier to debug) designs.

My application area has almost always been what I would describe as "engine" work. That is, I'm creating huge number-crunching black boxes. Akin to a database. That might help you to appreciate my biases...

This is why web applications are usually written in interpreted languages. When your application runs at the speed of the network, there is often computer time to spare, so it doesn't pay to invest a lot of programmer time. In such a situation, higher-level languages win on the ROI analysis.

No doubt Java makes sense in lots of programming areas -- explaining why it's so popular. But I do believe that, in comparison with C++, it is much slower (perhaps 2X), and it isn't all _that_ much faster to develop in (in my application areas). In fact, without generics/templates, I'm sure Java would be alot slower to develop in than C++. Use of generics yields very important productivity improvements. I understand that Java now has generics, so that's a good thing.

There are things I like about Java. I've considered it before. There are certainly things I hate about C++ (lack of garbage collection isn't high on the list). I often find myself considering alternatives. I need something _fast_, with static typing and generics, but also allowing for functional programming. O'Caml seems like a decent candidate, altho I'd pay a performance hit. Java's problem here is that it doesn't allow functional programming. At least it allows anonymous classes, which is nice. But if I'm going to go changing my main programming language (I only like to use one compiled fast language, and one interpreted slow language), the language needs to solve real problems for me, without creating very many new ones.

Re:2x speedup, not 5%

[Pseudonym]

The site uses many (dozens, even) of different algos to make the comparison.

...and many of them are biassed. In particular, any "same way" test is going to discriminate against some language. This is especially true of the more declarative languages. In such a language, for example, mutable arrays are usually less elegant and less efficient, but such languages almost always have other higher-level data structures which are more appropriately used in places where you'd use an array in C.

IMO, a much fairer benchmark is something like Pseudoknot, which takes a nontrivial real-world problem and lets each language solve it in an idiomatic way. Unfortunately, the results are ten years old now. It'd be interesting to see how Java does.

My application area has almost always been what I would describe as "engine" work. That is, I'm creating huge number-crunching black boxes. Akin to a database. That might help you to appreciate my biases...

My previous job was on developing a high-performance database server. Believe me, I know where you're coming from.

Database servers, linear algebra systems, operating system kernels and the like all have several features in common. First, performance almost always really matters. Secondly, and more importantly, they're all useless on their own. A database server is useless without an application, a linear algebra library is useless without client code, and an operating system kernel is useless without user tasks to manage.

Yeah, your black boxes are, no doubt, very important. But someone, eventually, has to feed information into those boxes and extract and interpret the results. That's a high-level task, for which raw performance may not be as important as flexibility.

Re:2x speedup, not 5%

[Chuck Messenger]

But someone, eventually, has to feed information into those boxes and extract and interpret the results. That's a high-level task, for which raw performance may not be as important as flexibility.

True. I'd also say that GUI's are an application area where performance really matters. People are very sensitive to responsiveness. They like snappy response times. A sluggish app gives a decidedly bad impression. Most GUI's, of course, are so simple that even a purely interpreted language (e.g. Tc/Tkl) will give adequate performance. But a big GUI, say, a browser, or a spreadsheet, or an image processor, or a word processor, or a desktop: in these cases, performance really matters.

I think where Java has a niche is in the middleware domain: lots of symbolic processing; relatively fluid requirements, such that adaptability really matters; a domain which is dominated by huge numbers of API's -- so that a langauge with a rich API set has a distinct advantage, as does a language with built-in memory management, simplifying interactions between complex subsystems; a domain where security issues are particularly important -- so that a VM-managed environment becomes a useful way to manage risk. Middleware is an application area which I've never worked in. If I did, I could see where Java would look pretty attractive.

Still, in making a comparison of the relative strengths of Java vs C++ in a given application, I think C++ really is much faster.

Think back to assembler

[dstrickler]

While a good question is posed, I the answer it easy to see. Just think back a few years, when the current thinking said "If you want it coded right, use assembler". Soon C came into fashion, and then a host of "higher level" languages. If an interpreter fits the bill, they'll go there, albeit a bit cautiously. When programmers are forced to do more and more, in each piece of code, they'll seek the clearest path to that goal.

Re:What?!?!?

[gnufied]

Dont say ITunes is fast man...i am on AMD64 3200 with 1GB of ram(Win XP) and what not...and it is slow..Amarok or Bunshee runs faster on my inferior notebook.r

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!

Good bye native...

[crazzeto]

In my college years I would have been seriously against the idea of not programming Native. I was a huge C/C++ fan and thought that programming languages such as java were evil. But in all honesty... These days... Programming in C/C++ is more of a pain than it is worth. They (and most nativly compiled languages that I know of) fall (far) behind languages such as C# and Java when it comes to ease of maintenance and OO prettyness (yeah C++ supports OO but ANSI C++ OO is fugly). I'd hate to say it but the only people who should be working with native are the folks and Microsoft, Apple and the OOS community. Developing operating systems and programming tools to allow the rest of the world to not deal with the uglyness of native code.

I still program "old school" and it's faster!

[MrJerryNormandinSir]

What is this? Now we want to dumb down our future? No matter how fast processors evolve it's always better to porgram them natively! My Dual Core G5 screams, especially when you take advantage of the altivec core.

I guess some people are worried about what happens when more people can harness the pwer of the microprocessors comming up.
Jack the ripper screams on my dual core G5. Yes I run Linux on my g5 as well as OS/X. Dsniff works great as well.

remeber, when it comes to code, GO NATIVE!

no, it isn't, and it doesn't

[Ender Ryan]

No, it isn't, and it doesn't. There may be something wrong with your machine or your configuration. Have you tried different audio output engines? Some of them aren't very stable, arts in particular has been bad in my experience.

Re:What?!?!?

[maraist]

Why wasn't the whole stack written in perl?
Ok, what about SQL.. That's not even JIT'd. What about about the startup process.. Why isn't that compiled directly into the kernel? Boot-up-times could be insanely fast.. Hell, you could even embed the mysql and apache and slash-code directly as a kernel module (a la tux)... You could have slashOS.

Obviously separation-of-concerns plays a role in these decisions.. But more importantly is the UNIX mentality of tool-boxing. Each language performs a single role (ideally) and each module is built out of the most appropriate tools (including language).

If 90% of the "Thinking" goes into the web request and the database reconciliation, and those aspects of thought are VERY uniform and consistent across all applications, then they BELONG as raw mathmatical code (e.g. c or pascal or take your pick beyond my expertise). Since there is no varyance, there is no benifit in JITing them every time they launch. Incidently if apache or Mysql were done in Java (i.e. hsqldb and tomcat), I doubt there would have been any performance hit, as both apache/mysql are services which have long live-runs, so load and JIT time are neglegable compared to boot-time.

The thing that should be scripted is what is most highly deviating between deployments.. Obviously shell-script being the most crude of the available languages (perhaps surpased by the non-Linux VB-Script), or maybe PHP (which I know many sys-admins who do shell scripts via PHP).

Perl is a fullly featured language (and if you don't believe me, try comparing it to bash and try to escape every possible string, and get back to me). This fact makes perl better than AWK, SED, grep or [ba]sh to do full system programming... Now I would argue that perl doesn't scale well into large projects (code-management wise).. It's harder than C to anylize since almost everythign is symbolic and has side-effects (the fact that whether you last referenced a scalar as a string or integer affects what it does when you concatenate is a big element-of-surprise when performing data-encapsulation). But single-focused applications like bugzilla or even slash-code are perfectly fine to write as perl applications.. You don't have unrelated application-level modules being brought together (meaning while IO::File is a module, it's purpose is to be reused, whereas bugzilla-preference-manager is not meant to be used for anything other than bugzilla... But the author is forced to be aware of the bugzilla-list-bugs module).

With Java and .NET (and I'm sure other languages), it's hard to write un-anylizeable code (though with the advent of XML and xdoclet it's getting easier). Note that I didn't say unreadible or unmaintainable.. In Perl you can load a module which forcibly redefines many of your functions.. This is not only feasible, it's common practice.. Now "good practices" says a module should use cooperative symbol injection (meaning the caller asks for symbols to override). In C++ you scatter the definition of your methods throughout many classes using the a::b::c syntax to pull them all together.. Convention reduces the propensity to abuse this, but it's still common practice to use include-file magic to completely alter which methods are compiled in. Java does use reflection and proxies more and more, which are just as bad (and often uses XML to define when/where/how to use such proxies). But this at least only provides "deviations" away from the base code; and more importantly is similar in effect to generalization-specialization... Since OOP often has you over-riding methods, reflection is more like dynamicly coded specialization. So it's no more inelegant than multiple overrides which OOP commonly allows (not aware of all the implementations of OOP)... Of course, you could always choose to say OOP should only ever specialize each method exactly once.

Someone else's comment about google spread sheets being butt-slow is not an issue of throughput, but latency (both being elements of

Most optimizations are NP-hard

[p3d0]

That's why optimizers use heuristics.

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

[Doctor Faustus]

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.
He or she was talking about games. Does anyone really write games in anything but C or C++?

Re:you'll learn

[ealar dlanvuli]

No one cares about games, they are perhaps 0.1% of all development. Why are they perpetually brought up?

Games have no bearing on reality. Not at design time. Not at compile time. And definitely not at playing time.

Re:you'll learn

[John Courtland]

There's no reason C/C++ development has to take longer than Java/Python/Ruby (except for some trivial exercises you will never see outside of academia).

Where is time being "wasted" developing C/C++? Most of the time, if there is a waste occuring, it's due to lack of foresight in design spec rather than language choice. Even a team of experienced assembler programmers can pump out an application pretty quickly, given a proper spec and APIs.

Re:you'll learn

[Decameron81]

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.

No offense, but if you are getting faster Java code than C/C++ code then you are a terrible C/C++ programmer.
Java certainly has its strengths, but it can't compare to C/C++ performance-wise. Not when the code is written by an experienced programmer.

As an example of what I mean, how many successful processor intensive games written in Java do you know?

The right tool for the right job. If you want performance don't use Java.

Diego

Re:you'll learn

[G Morgan]

Irrespective the poster made a point about games so decided the context. To argue outside that context would be similar to me saying that rally car x is fantastic then have somebody compare it to a formula one car in terms of speed.

Re:you'll learn

[imbaczek]

It doesn't matter who writes (or doesn't write) games in what. It is a know and well established fact that the majority is stupid. In every game there are parts which needn't be Damn Fast. See World of Warcraft for a most popular example.

Re:you'll learn

[w1ll0w]

I would think they are brought up because the performance they need seem to show that managed code isn't the answer to all software development. Games need to run fast, most business apps don't.

Re:you'll learn

[arevos]

No offense, but if you are getting faster Java code than C/C++ code then you are a terrible C/C++ programmer. Java certainly has its strengths, but it can't compare to C/C++ performance-wise. Not when the code is written by an experienced programmer.

There's less difference than you might think. Take a look at this computer language shootout benchmark. The only significant bottleneck Java has is its startup time.

Typically, professional programmers have a limited time to develop software in, and languages that produce results faster leave room for implementing better algorithms, which can have a marked effect on the performance of a system. That said, there are limits; if you want cutting edge graphics, native code (at least for the engine itself) is pretty much a necessity. For most other systems, where performance is not the priority, native languages are less useful.

Re:you'll learn

[arevos]

There's no reason C/C++ development has to take longer than Java/Python/Ruby (except for some trivial exercises you will never see outside of academia).

I will never understand why people feel the need to be so assertive about things of which they have only limited understanding. A good programmer should keep an open mind about systems they are unfamiliar with. A wise man admits he knows nothing, and so forth.

All programming languages have their own niche, their own environment in which they perform optimally. Remove the language from it's comfort zone, and things rapidly go down hill. This applies as much to C++ as it does to Python or Ruby. Knowing the limitations of the tools one uses is the mark of an experienced programmer - indeed, the mark of any experienced craftsman. You cannot be a good programmer without knowing where the limits of the tools you use lie.

Example: what percentage of web applications are primarily coded in C++? Clearly very few, only performance intensive services such as Google use the language. This is because the design goals of the majority of web applications lie outside C++'s particular niche.

Re:you'll learn

[John Courtland]

I will never understand why people feel the need to be so assertive about things of which they have only limited understanding. A good programmer should keep an open mind about systems they are unfamiliar with. A wise man admits he knows nothing, and so forth.

Are you directly addressing me in your statement or am I reading into it wrong?

Re:you'll learn

[arevos]

Are you directly addressing me in your statement or am I reading into it wrong?

I was. Bluntly, perhaps, but my statement holds true, nevertheless. You assert that "there's no reason C/C++ development has to take longer than Java/Python/Ruby". This is, frankly, uninformed nonsense. Again, I'm being blunt, but sometimes the direct approach is necessary in a discussion.

Re:you'll learn

[Decameron81]

Typically, professional programmers have a limited time to develop software in, and languages that produce results faster leave room for implementing better algorithms, which can have a marked effect on the performance of a system. That said, there are limits; if you want cutting edge graphics, native code (at least for the engine itself) is pretty much a necessity. For most other systems, where performance is not the priority, native languages are less useful.

That was basically my point as well. I totally agree that each tool can be better or worse for different tasks. I tend to write processor intensive applications mostly, so I tend to notice that difference in what I do... however this different is surely becoming smaller and smaller on other kind of applications.

However I am not quite sure that interpreted languages will be the ultimate solution. In my humble opinion at some point we will see some sort of standarization in APIs and better native languages that incorporate part of the concepts of Java, and other similar languages.

I personally see interpreted languages as a sort of non-solution for the lack of standarization across platforms. Something like Apple's Universal Binaries using a standard API would be much nicer IMO. This is just my personal view of the issue though.

Re:you'll learn

[John Courtland]

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.

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.

Re:you'll learn

[Kent Recal]

There's less difference than you might think. Take a look at this computer language shootout benchmark [debian.org]. The only significant bottleneck Java has is its startup time.

Are you blind or did you just choose to not read your own link?
Java is 1-2 times slower in each of these microbenchmarks.

If 100% is not a significant overhead to you then, well, lucky you.

Also these microbenchmarks don't even consider the java garbage collector
which can and does create all kinds of "funny" situations (thrashing) on it's own.

Re:you'll learn

[John Courtland]

I sort of regret writing what I did, it was at the end of the work day in haste. I had a whole thing detailing almost exactly what you have here, except taking about Django, JSP and Rails instead of TurboGears. Then I erased it and wrote that so I could go home.

Anyhow, to address your points, I suppose I don't consider the available frameworks part of the language. I talk rather academically about languages, so to me it's all about designing the problem properly. From my perspective, web development is childs play. The problem is already solved: With TurboGears, a machine literally does all the work for you. How much Python do you really write? 10 lines per page, maybe 30 if it has a lot of form elements. That's not writing code, you've got a machine to do it all for you, the choice of language is already made. In this aspect, I concede, I don't even think of this when I'm discussing writing code, so you can go ahead and lambaste me if you want. I do feel, however, that maintenance of that code is not much easier than any other well-designed solution.

That said, the custom back-end business code to that webpage could be in almost any language and it would take nearly the same amount of development time. VB, C, anything. Almost any problem you could create have had libraries written to solve them in almost every language, just utilize them and be done. Or, like TurboGears, if there's a package already written for you, use that, and then fire your programmers.

Re:you'll learn

[TikiTDO]

Jumping from C/C++ to Java may be quite trivial, and same can be said for many languages. But to claim anyone should be able to jump into any language and code is just ridiculous. What of languages with completely different concepts behind them?

Jumping from say, Python and a rather open data access model, into Lisp with its list oriented approach is likely to give any coder who does not regularly work with both at least a bit of culture shock. True, most people would not need to make such a drastic change, but to say that any decent coder should be able to do so is a bit naive.

Re:you'll learn

[arevos]

If 100% is not a significant overhead to you then, well, lucky you.

In many common server-based applications, which is where Java mainly excels, the amount of resources required is proportional to the number of requests made. A good example of this would be a website, or a database. This form of problem lends itself to parallisation; it's not uncommon to have heavy-use websites or databases running off multiple machines.

Generally speaking, it's far cheaper to buy another server than it is to employ a programmer for any significant period of time. A 100% overhead means nothing, if it saves the programmer some time.

For GUI applications too, 100% inefficiency means very little. If it takes 10ms instead of 5ms to complete an operation, the user is not going to notice. The only set of applications where this level of efficiency would be a problem, would be a CPU-intensive, single user application.

Re:you'll learn

[arevos]

I sort of regret writing what I did, it was at the end of the work day in haste.

My apologies too, if my writing caused any offense. It wasn't intended.

Almost any problem you could create have had libraries written to solve them in almost every language, just utilize them and be done.

I've come across many, many problems where this simply isn't true. Whilst almost every language has libraries that handle regular expressions, graphics, network access and so forth, once you get into specifics, the difference between the libraries for languages becomes far more apparent. Java, for instance, has some very mature XMPP libraries, whilst in Python, all the equivalent libraries are in a much earlier stage of development. And as I've mentioned before, C++ doesn't have an equivalent to the Turbogears framework.

However, let's put the library issue to one side, and concentrate on whether the syntax of a language has any significant benefits for the programmer.

That said, the custom back-end business code to that webpage could be in almost any language and it would take nearly the same amount of development time. VB, C, anything.

I disagree with this as well, but for reasons that are less easily explained. I'll let a quote from Paul Graham's Beating the Averages essay start my argument:

But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be.

Lisp macros are a good example of high level syntax that C++ does not possess. In Lisp, macros are used to manipulate code in the same way functions are used to manipulate data, or, to put it another way, Lisp macros enable you to make local changes to the syntax of the language. They are very different from the macros found in C or C++.

Given that the programmers in the startup Graham was involved in were writing so many macros, one has to wonder why. If programming in Lisp has no significant advantages over C++, why use a language construct like macros that has no direct analogy in C++?

There are two conclusions you can draw: either Lisp has no significant advantage over C++, and the programmers were using macros pointlessly. Or, that macros did serve a purpose, and thus Lisp does indeed offer advantages over C++. Given the success of the company, they must have been doing something right.

Indeed, one can see this same theme with many other libraries. Turbogears uses high level functions and metaclasses throughout its systems. Again, these are language constructs that C++ lacks, but are used often enough that one has to wonder about the benefits of these features, even if one knows nothing about them first hand. If Python offers no significant advantage over C++, why are these constructs put to use so commonly?

Re:you'll learn

[Kent Recal]

In many common server-based applications, which is where Java mainly excels, the amount of resources required is proportional to the number of requests made. A good example of this would be a website, or a database. This form of problem lends itself to parallisation; it's not uncommon to have heavy-use websites or databases running off multiple machines.

Yup, the interesting metric is the rate at which you have to add new machines to keep up with the load and
how soon you run into bottlenecks (i.e. i/o throughput) that can only be addressed with rather expensive
hardware upgrades.

Generally speaking, it's far cheaper to buy another server than it is to employ a programmer for any significant period of time. A 100% overhead means nothing, if it saves the programmer some time.

Well, that's a common myth which holds true for small to medium installations but kicks back horribly in larger
setups (>20 machines). Rackspace and power are cheap but not free. Maintenance overhead is expensive.

I agree that a constant overhead is generally not a big deal. But once you decide that throwing hardware at your
problems instead of solving them is "cheaper" you've chosen a dangerous route. Encouraging sloppy programming is the
last thing you want to do because it leads not only to poor scalability but also to misguided design decisions
that will quickly eat up and reverse your dream of "increased productivity".

No hardware can replace good programmers. Good programmers don't cheat by crying for more hardware early.

For GUI applications too, 100% inefficiency means very little. If it takes 10ms instead of 5ms to complete an operation, the user is not going to notice. The only set of applications where this level of efficiency would be a problem, would be a CPU-intensive, single user application.

Different story.

Re:you'll learn

[arevos]

Well, that's a common myth which holds true for small to medium installations but kicks back horribly in larger setups (>20 machines). Rackspace and power are cheap but not free. Maintenance overhead is expensive.

Which is why Google use C++ for their performance intensive systems, but a very small percentage of software projects need that level of computational efficiency. Modern computers are fast. Even Ruby, which can be as much as 300 times slower than C++, can maintain a web application that gets several million hits per day with fairly modest hardware requirements.

Put it another way: how many systems will have their CPU requirements double every two years? Anything less than that rate of growth, and the pace of progress rapidly outstrips the resources necessary to use the system. The efficiency of C++ simply isn't required for the majority of server-side applications.

Besides, if efficiency is that important, why not use C or even write parts in assembly?. At some point, the benefits of programmer efficiency outweigh the benefits of CPU efficiency, and a higher level language becomes more advantageous than a lower level one.

Encouraging sloppy programming is the last thing you want to do because it leads not only to poor scalability but also to misguided design decisions that will quickly eat up and reverse your dream of "increased productivity".

Inefficiency, poor scalability and sloppy programming are three separate things. One does not automatically imply either of the others.

Re:you'll learn

[Kent Recal]

Which is why Google use C++ for their performance intensive systems, but a very small percentage of software projects need that level of computational efficiency. Modern computers are fast. Even Ruby, which can be as much as 300 times slower than C++, can maintain a web application that gets several million hits per day with fairly modest hardware requirements.

True, the database is usually the bottleneck (when using RDBMS).
I, btw, question your claim that ruby can maintain "several million hits per day" (or did you mean cache hits?) on "modest" hardware. That would either be a very simple app or not so modest hardware.

Put it another way: how many systems will have their CPU requirements double every two years? Anything less than that rate of growth, and the pace of progress rapidly outstrips the resources necessary to use the system.

Sorry but it's a bit naive to assume that hardware can simply be replaced every two years.
And if the CPU was the only bottleneck things would be easier. Memory throughput is another common
problem, esp. with java apps and their object churn.

Inefficiency, poor scalability and sloppy programming are three separate things. One does not automatically imply either of the others.

I have first hand expirience that sloppy programming does indeed almost always imply the other two.

Re:you'll learn

[arevos]

I, btw, question your claim that ruby can maintain "several million hits per day" (or did you mean cache hits?) on "modest" hardware.

According to Wikipedia, Penny Arcade handles 2 million page requests daily with Ruby on Rails. On the forums there, it's been mentioned that Penny Arcade runs off a cluster of 5 machines.

If Penny Arcade's content is too static for your tastes, then the Robot Co-op family of sites, which consists largely of AJAX web applications such as 43places, manages 2.5 million daily page requests with 6 machines.

I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic. You may disagree.

Sorry but it's a bit naive to assume that hardware can simply be replaced every two years.

You misunderstand me. What I'm saying is that, in general, the average increase of CPU requirements for server applications is likely less than a 100% increase every two years. Given this initial premise, the logical conclusion is that, in overall, the number of server applications that use Java will tend toward an increase, and correspondingly, the number of C++ server applications will decrease.

Obviously most server-side systems last for longer than two years, but what matters is the rate of increase. For instance, if the average lifespan of a C++ server system is ten years, then unless resource requirements have increase a thousandfold in that time, then it makes more sense for the replacement to be programmed in Java (or Python, or Ruby), than in C++.

I have first hand expirience that sloppy programming does indeed almost always imply the other two.

Most of the time, I'll agree with that. My point was more that inefficient programs (in terms of computer resources being used) does not imply sloppy coding, nor an unscalable system. A program need only perform up to spec with the resources it has; efficiency gains beyond that point will be increasingly less useful and more costly.

Re:you'll learn

[m874t232]

He or she was talking about games. Does anyone really write games in anything but C or C++?

Most games actually are not "written in C or C++", they are written in a game engine or scripting language.

Re:you'll learn

[m874t232]

No offense, but if you are getting faster Java code than C/C++ code then you are a terrible C/C++ programmer.

No, it's just that in the real world, there is a limited amount of time for developing a piece of software. Every minute I spend on worrying about memory allocation or tracking down a pointer bug is a minute I can't spend on putting in a more efficient data structure or profiling my code.

Re:you'll learn

[Decameron81]

No, it's just that in the real world, there is a limited amount of time for developing a piece of software. Every minute I spend on worrying about memory allocation or tracking down a pointer bug is a minute I can't spend on putting in a more efficient data structure or profiling my code.

If you're a good C/C++ programmer you don't spend "minutes" allocating memory and tracking pointer bugs. On top of that, being able to allocate and free memory when you want is part of the power of C/C++ meaning that it let's you work on the application's optimization process at a level that you simply can't control in Java.

And to put it into a different perspective... I have yet to find a Java application built for performance tasks that can compare to a C/C++ natively compiled counterpart. Java is a hell of a language, just don't mistake the tools. C/C++ is for performance and scalability, not Java.

Re:you'll learn

[m874t232]

Geez, you talk like someone who programs by himself in his basement and fancies himself a good programmer. In the real world, memory management in C and C++ is a major issue on real-world software development projects: it has a profound effect on anything from API design to testing. Just the fact alone that errors in C/C++ are not isolated to the module they occurred in results in enormous increases in effort during testing and debugging. It's an even worse problem that people like you think that because they have somehow cobbled together a program with matching new/delete statements (most of the time), they have mastered memory management and are doing an efficient job; people like you don't even know how poor their memory management actually is in practice.

On top of that, being able to allocate and free memory when you want is part of the power of C/C++ meaning that it let's you work on the application's optimization process at a level that you simply can't control in Java.

That control is illusory; it means that C/C++ programmers often will choose inefficient storage management strategies and retain memory long after it has become garbage because doing things right is too hard for them.

Java is a hell of a language, just don't mistake the tools. C/C++ is for performance and scalability, not Java.

Actually, I think Java is a lousy language and I don't recommend you use it. But it got one thing right: it is a safe language with fault isolation that still has excellent performance for both memory management and compute-intensive tasks. Where Java fails is its inefficient I/O and inefficient standard libraries.

Re:you'll learn

[arevos]

I often find it helpful to read and understand a person's post before replying to it. Obviously, you don't adhere to this particular philosophy.

If you had read my post, you'd discover that I did not once refer to the performance of Rails as "impressive". Indeed, I did not mention the word even once. Instead, I said, "I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic." This is quite different from the statement you appear to think I said.

In my previous post, I merely pointed out that for a website that handles several million potential customers a day, six servers is a modest requirement to keep everything running, both financially, and in terms of support.

Further, your figures are idiotic. In March this year, Google handled around 91 million searches a day. That's around 1000 searches per second. Why, that's not even 10% of the capacity of your one hypothetical machine, and Google have over 200'000 servers. 10'000 request per second might be more realistic if one was only serving static content, but hardware requirements rapidly increase once you start to factor in dynamic content, such as is produced by RoR.

Why not virtualization?

[ThinkingInBinary]

If the trend is towards virtual machines, why are we using emulated virtual machines? Things like VMware are taking off, and Intel has Virtualization Technology (TM) that essentially allows a program to run another protected mode task, with any privilege level, and simply trap any privileged IO operations. If any mainstream OS implemented it right, they could basically do what "386 Enhanced" mode did for older programs, and sandbox them while running at full speed for the rest of the code (that doesn't require interaction with the sandbox to decide whether it's okay, or redirect it to host resources).

No laughing matter

[maximthemagnificent]

I'm an engineer and I regularly write programs that my PC fails to "laugh off". End of native code, my butt.

Re:What?!?!?

[tomhudson]

You do know that you can use the C preprocessor on any text file, right? It's a standalone program on systems using GCC. You will have to avoid shell-style comments (#), but otherwise it works well. It is a bit weird running Make on your PHP files, though.

I used it + some funky header files + some perl-fu to convert some c to java. Just to see if it was possible. It works, and it was nice being able to type main() and get it replaced by the proper class designations, scoping, etc., as well as much simplified syntax for other stuff.

It is a bit weird running Make on your PHP files, though.

One good use is to use a script to replace all the "include('filename.inc')" stuff with "cat filename.inc.php >> target.php". No more .inc files, and only 2 hits to the filesystem on the server (1 to read the dir, one to read target.php') as opposed to the usual dozen or so ... and you can include a command to strip all the comments and extraneous whitespace from your target.php while you're at it, making it load and run slightly faster, then move target.php to your ftp upload dir (or even automagically ftp it to the server if there are no errors).

Just don't use it to embed your common css or javascript in target.php - its better to pay the penalty for an extra couple of file reads on the first hit, and have the user's browser cache the result for the rest of the browser session :-)

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.

Re:simple

[CaptnMArk]

The reimplementation is not swing's major problem.

There are 2 problems:

1. It's far too slow/bloated. GC makes it worse as soon as you hit the page file.

2. It's not feature rich enough. It should not be the lowest common denominator, but should support the platform features and degrade gracefully.

Also, reimplementation of obsolete windows MDI in Swing was a stupid waste of effort which could be spent elsewhere.

Re:simple

[Anonymous Brave Guy]

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.

The problem is, machines just aren't good at visual design and HCI stuff.

Sure, some things can be automated: do we centre the titles over related groups of controls on this platform?

Other things can't: the conventions for labelling buttons are wildly different from platform to platform. We can say, "Platform A's convention is much clearer, so we'll just use those labels everywhere," and it might even be true from a UI perspective. However, it would still look out of place on Platforms B and C.

The same is true of pretty much any aspect of graphic design, typography, or other presentation. The best fonts are still hand-hinted by experienced typographers. The most impressive web pages often use solid, carefully planned layout and judicious graphics, rather than relying on browsers to render fluid layouts as effectively. Publishers don't rely on the templates that come with word processors or DTP packages, they get their own designed for each publication. And software developers who care about their users don't trust algorithms to generate a clear, effective user interface, they get a real person who understands HCI and platform conventions to design it.

Re:simple

[m874t232]

The best fonts are still hand-hinted by experienced typographers.

Is that merely your opinion, or do you have some concrete, experimental evidence to demonstrate that?

That's, in fact, a problem with lots of your statements and lots of the things people say about HCI: it's opinions, hunches, and anecdotal evidence, with little or no facts to back it up.

Re:simple

[Anonymous Brave Guy]

Except that it's not really "just my opinion" at all, nor even just the opinion of many professionals in the industry.

Regarding the typography, academic studies of both perceived readability (which font people prefer to look at) and actual readability (how fast and accurately people can read text in different fonts) have been carried out. Several factors appear to affect both, not always correlated as directly as one might assume, and there are no known algorithms that effectively optimise some of those factors (optimal kerning to give even colour, for one).

Likewise, there is a whole industry, albeit a relatively small one, dedicated to usability. Jakob Nielsen's useit.com is probably the best-known web site on the subject, even if it's not what it used to be these days, and there are many more. These people perform quantitative studies on how effectively user interfaces work. Again, their conclusions don't always agree with what "everyone knows", but those conclusions are typically based on objective studies of what users actually do, not reading some big company's handbook of UI design standards.

So no, this is not based on idle conjecture. My opinions have been formed after studying this field for several years, and the sources I'm most interested in are those that are not hypothetical but based on objective evidence.

Re:simple

[m874t232]

Regarding the typography, academic studies of both perceived readability (which font people prefer to look at) and actual readability (how fast and accurately people can read text in different fonts) have been carried out

Yes, and their results don't support your statements.

Likewise, there is a whole industry, albeit a relatively small one, dedicated to usability. Jakob Nielsen

Yes, and Nielsen couldn't back up his statements with actual facts if his life depended on it; usually, he takes a tiny factoid from some vaguely related experiment and completely overgeneralizes from it.

So no, this is not based on idle conjecture. My opinions have been formed after studying this field for several years, and the sources I'm most interested in are those that are not hypothetical but based on objective evidence.

Sorry, it doesn't work that way. Either you back up specific claims with specific evidence, or your statements are just hot air.

I note that you still have not provided references to back up your claims about typography.

Re:simple

[Anonymous Brave Guy]

Yes, and their results don't support your statements.

Which results and statements, exactly, would those be? For someone who's so keen on justifying "specific claims with specific evidence", your criticisms of my argument here are remarkably troll-like.

For a start, I haven't really made any specific claims in this thread. In fact, my whole point was pretty much that this is a general issue with today's robotic, mathematical systems vs. human perception, that does not seem to be restricted to specific cases. About the closest I can think of with typography was "The best fonts are still hand-hinted by experienced typographers," and since I didn't specify best in what sense and have mentioned at least two relevant ones (which I called "perceived readability" and "actual readability" for want of better terms), that's hardly a specific claim.

Now, I could make specific claims. Indeed, I had several in mind to support my general premise, but decided not to elongate my earlier post by listing them. But before I do, I'd be fascinated to know what specific claims you think I should back up with specific evidence.

Yes, and Nielsen couldn't back up his statements with actual facts if his life depended on it; usually, he takes a tiny factoid from some vaguely related experiment and completely overgeneralizes from it.

Have you ever actually read one of NN Group's usability reports, or even the web site articles? They frequently discuss the experimental methods and sampling techniques they use, and how they derive their quantitivate data. Your claim sounds like you used to insist on doing something your way, and you don't like the fact their more objective studies have debunked your "expert" views.

Sorry, it doesn't work that way. Either you back up specific claims with specific evidence, or your statements are just hot air.

So cite some claims Nielsen has made that are over-generalised "tiny factoids from some vaguely related experiment" and explain why his method was flawed in each case.

Re:simple

[m874t232]

Which results and statements, exactly, would those be?

The statement that I quoted:

The best fonts are still hand-hinted by experienced typographers.

For someone who's so keen on justifying "specific claims with specific evidence", your criticisms of my argument here are remarkably troll-like.

It's quite clear what you sound like: a weasel.

Re:simple

[Anonymous Brave Guy]

I notice you've ducked my direct question about your challenge on Nielsen.

As for the typography thing, perhaps the most obvious recent example is the use of Verdana and Georgia on the web. Both fonts are designed for screen use and then heavily hinted to allow them to display well at the kinds of resolutions used on-screen. In readability studies, Verdana is consistently favoured over Arial by a large margin at the font sizes typically used on web pages.

For some examples of the problems with not hinting fonts, please see The raster tragedy at low resolution at Microsoft Typography.

For display use, anti-aliasing is the best technological answer to this problem in use today, and the sub-pixel anti-aliasing in Microsoft's ClearType technology is very impressive. Even then, though, they still use tools like Visual TrueType to keep the rendering "honest".

The above is most relevant to display on-screen, since they are much lower resolution than printed matter. However, many of the same legibility/readability issues arise in printing, which is why professional-grade fonts often come with several "optical" variations intended for use at different size ranges (typically a "caption" version for 6-8pt, a "regular" version for say 9-13pt, a "subhead" version for 14-24pt, and a "display" version for 25+pt). These have small adjustments that don't change the flavour of the font, but make it easier to read or more visually appealing at the different design sizes. Caption fonts intended for use at smaller point sizes employ many of the same tricks as those designed for screen: slightly larger bowls, for example. The larger fonts tend to tighten up the spacing a touch, to avoid the kind of disconnected appearance you get with a poorly-kerned font at body text sizes, which again is something consistently shown to hurt readability in studies.

So, although I was talking about "hinting", which is primarily a concept relating to screen fonts, the same sorts of ideas apply to printed typography as well. Again, today's automated scaling technologies haven't yet caught up with the fine adjustments a human typographer would make. This isn't to say that it couldn't be done, but right now AFAIK it hasn't been, and if it has, it certainly hasn't entered the mainstream yet.

So, which parts of the above do you think the research contradicts? And which of Nielsen's claims are you going to critique, since you're so keen on specific claims and specific evidence?

O(n^2) vs O(n!) Native vs Interpreted

[tarpitcod]

Like the parent says - It Depends.

(1) What is the target application, does it have latency requirements? You may not want to use Java if it does - or program like your writing code for Javacard or J2ME (Create your objects at startup and don't just new yourself into GC hell).

(2) You probably want to think about the algorithm first. A 100x faster native CPU won't do much good if your algorithm is coded O(n!) vs O(n^2) on the interpreted platform.

(3) Bandwidth is money, latency is forever.

(4) It was once said that LISP / PROLOG were too memory hungry. Big Institutions could afford memories of say 4 MB and fast CPU's. Now you quite possibly have more than 5 VAX MIPS in your cellphone and more memory than that late 70's / early 80's VAX too.

Here's a final question. Suppose your requirement was to write the embedded code for a medical radiation therapy machine. The machine has to: 1) Turn on and off the beam. 2) Rotate the beam around some axis.
Screwing up could mean fatality. What language / environment would you use then? Imagine your loved one has to lie on this thing.

Java with the GC possibly getting in the way?
C? -- Pointer smashing?
C++ -- Ditto...
Lisp, Mercury, Erlang, Ada, Modula 2, Eiffel, Assembler? No software?, hardware? / a finite state machine?

Hint for googling: Therac-235.

Do you care about this?

[cyberdrop]

ScottGu's Blog: Handling 1.5 Billion Page views per day using ASP.NET-2.0

Re:Do you care about this?

[sh4na]

If you had *bothered* to go and look for yourself what's really going on in myspace.com instead of copy-pasting an url, you would have noticed that *everything* but the browse users feature is Cold Fusion. Really interesting hmm? And in the browse users feature only the search part is asp.net, details are cold fusion.

And if you join up, you will notice also that in the intro they specifically say that they have cut down on the amount of friends listed as connections due to excess information that the servers couldn't handle (which part is asp.net again? hmmm)

So they redesigned a half part of a 10th of their site to asp.net, so that tells us that they took out that part and put it on different servers, most likely. And the article says that processors are down to 27% from the 80% something they had before the redesign? Surprise, surprise!

So who's really handling the billion-plus pageviews in myspace, I wonder? Asp.net, or CF?

I work with .NET full-time, have been for 4 years now. Believe me, I know what it can handle. IIS didn't magically improve just because you slap it an ASP.NET label you know, it's still the same hog as it was. And to handle those types of numbers, you'd really have to have a majorly awesome network coupled with some really good connections to databases and good (i.e., configured properly!) servers, not to mention good code (as in, veeery careful with session handling, templating and cache, or it's bye bye memory).

I say pfffft.

Re:Do you care about this?

[sh4na]

Ok, I call pffft on myself, just noticed they mapped the cfm extension to .NET. Still can't believe the numbers though.

hides away in a box...

Re:Do you care about this?

[cyberdrop]

I think the point is that managed code IS capable of running such a huge site. Improvements to the infrastructure that may have happened do not matter.

So what your saying is

[TheSkepticalOptimist]

Rather then writing efficient and powerful native software, write system crippling interpreted applications so that you never realize the fullest potential of your brand new hardware? For what purpose, so that you can write an application that targets both 90% of the worlds Windows users on PCs AND the other 10% of mismatched users using alternative *nix based OS'es on a variety of hardware?

Sorry, as a Windows programmer, I will target the 90% and forget about the rest. I will earn a good living making native Windows software without worrying about crippling my software so that it can run poorly on the other 10%. If Open Source advocates create a Wine or other Windows emulator that can run my software, good for them, I will even optimize my code so that it runs more efficiently under Wine, but I will not abandon my largest marketshare by crippling my software in order to cater to the other 10% who don't believe in paying for software.

Vista will offer me a whole new level of expression and creativity, using their native API's. I am no longer constrained to creating apps with static grey boxes. Making a cross platform application, most UI is terribly utilitarian and uninspired. While there ARE exampled of decent cross platform applications (FireFox) for instance, most shareware open source software is crap and pure examples of why you need to define a target market rather then trying to appeal and cater to everyone.

Java still isn't improving. The few Java based desktop applications I have tried still cripple a reasonably powerful Dual Core AMD system. I mean, the system becomes sluggish and almost unusable if I have th Java applications UI visible. As soon as I minimize the Java application, the system snaps back to full speed. When Sun can make Java run as fast as native code (or even come withint 90%) without crippling the OS then I would consider using cross platform interpreted code, but not until then.

I have only ever found python to be effective for writing quick system scripts to perform repetitive tasks. I would shudder to have to write a actual application using the script language.

I don't see the end of native code any time soon. The argument that just because you have a beefy system that can run interpreted languages quickly isn't sound. I bought that beefy system so that I can maximize its effectiveness, not just make do with software that runs at 50% capacity, even at optimal conditions.

Why hasn't someone created a Java co-processor? I mean, create a hardware bit that can be slapped in as an add-on card, or embedded on the motherboard to run Java as fast as running native code on general CPUs? I mean, if Sun was serious about Java as a universal cross-platform language, then why not put some of their hardware development skills into making a Java co-processor. In the worst case, you have to run Java as a software virtual machine, but if you believe in Java and want it to succeed, then you will buy the co-processor and run Java in an optimize hardware machine.

Re: C++ is bad? Move to Java or C# !

[j1mmy]

Who cares that it never does what it seems to do -- that's not a useful piece of code. Why would you write something like that?

you got it backwards

[m874t232]

JIT compilers aren't "interpreters", they are real compilers. And not only do they not "struggle" with optimizations, they open up the ability to perform optimizations that batch compilers simply cannot reasonably perform. For example, they offer template instantiation without the bloat associated of C++ templates, they perform dynamic method inlining, and they optimize code for the specific set of processors and communication hardware available on a given piece of hardware.

The profusion of architectures, as well as extensive code reuse, are what is increasingly driving JITs, and the more complex and parallel hardware gets, the more import JITs become because batch compilers are hitting a brick wall there.

Java

[m874t232]

Ah, if it only were as simple as "Java is 5% slower than native". Unfortunately, performance can't be characterized that easily.

In real life, Java is as fast as C/C++ on microbenchmarks.

In real life, Java is also often slow as a pig, not because of the byte code or JIT, but because of the way class loading works, the way JNI works, library bloat, and lots and lots of other problems.

Java has given a bad name to JITs, but it has also demonstrated their potential.

Re:Java

[bunions]

library bloat

This is my pet peeve with Java. I've always wondered how much faster/smaller Java would be if it dumped the less-used stuff and one (both?) of the windowing systems. Crypto? LDAP? Kerberos? Why are implementations of this stuff in the core?

JIT compilers are the future

[m874t232]

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.

If you lump together Java, C#, and interpreted languages, you really don't know what you're talking about. Java and C# are natively compiled languages, they just happen to perform compilation at runtime.

And for high performance computing, that's the future, because that's what's needed to adapt software to the specific hardware and data you have; batch compilers simply can't do that.

Java itself has lots of problems for high performance computing, but don't confuse a particular implementation with the approach. You'll likely see JIT-based Fortran implementations become widely used in the future and Fortran-specific JITs for high performance computing.

Compiled binaries *should* always be faster...

[WerewolfOfVulcan]

I've been writing business applications exclusively in PHP for almost 4 years. WHen I attended PHPCon in 2002, Rasmus Lerdorf was the keynote speaker. During a question and answer session, one attendee asked about the limitations of PHP in computationally intense situations. Rasmus said to write your business logic in C and call those binaries from PHP. Since that time, various PHP compilers have emerged which may may or may not make the whole issue irrelevant. I've never felt it necessary to either write external C routines or compile a PHP app because the apps I've written perform acceptably on commodity hardware. I love C and C++ dearly, but writing userland business applications in C is just way too much hassle.

But what interpreted language can I use to write a device driver? Or a web browser? Or an operating system?

Interpreted and compiled languages have coexisted peacefully for decades. It is reasonable to conclude that they will continue to do so.

Why not both in a single lang

[Adkron]

I personaly would like to see a language that has the ability to be both interpreted and compiled. That way you could have the best of both worlds. If you need the low-level functionality certain parts could require compilation if used, but if you just want something quick and don't need that access you could interpret it. This would reduce the need to learn as many languages, and would make for a powerful platform for programmers. Now all we need is an able bodied group to come up with such a language.

Re:Why not both in a single lang

[Whip-hero]

It's been done a long time ago. Lisp has had this ability for decades, along with a few other features that are only now making it into mainstream programming languages. It's been said for a while now that language design is slowly converging on Lisp. When the s-expression syntax is finally adopted by the average programmer, we'll have caught up with 1968. :)

Missing the point...

[bjk002]

Working in a LARGE corporate environment, I see this entire discussion as moot. Corporations are trending toward the complete elimination of GUI desktop apps in favour of RIA (Rich Internet Applications). Write them once, run them anywhere. Traditional BATCH processing is accomplished through services, daemons and objects.

Java's place in on the server. JSP is OK, but I wouldn't want to write full-blown RIA's in it. Look at FLEX or CF for your front-ends, then write the objects you need in Java to support you RIA front ends and appropriately represent your backend. J5EE with all the new Hibernate stuff, Generics, etc... as well as the stuff in the new concurrent package give you so much power and flexibility in writing FAST, solid, flexible frameworks, why would you want to use anything else.

What if it was the other way around?

[Rush2k]

What if every piece of software was written to use the minimal amount of ressources needed to do its job?

As a professional game developer, I am amazed at how slow my favourite PC apps run these days, native or not. When I can do physics simulations, AI, complex animation, networking, and render 10 of thousands of objects with tons of processing to set them up, all in 33ms, on the PSP's 222Mhz cpu with 24Megs of RAM available to me, Why the hell does my Azeureus take 20Megs of my 512Megs of memory and 3% of my 2.8Ghz, even when I'm not downloading anything!!

I am sick and tired of lazy developers wasting cycles left and right on the assuption that the machines are so powerful they shouldn't care. imagine if gas consumption and cars were thouht of the same way.. And these developers then assume they own my machine.

Have you ever tried running Azureus, Maya, Visual C, Media player, outlook, some RSS feed thingy, an Antivirus, Google desktop, Trillian, Picasa, Word, Excel, ITunes, Photoshop, Google Earth, and a bunch of windows in firefox, all at once, and all of them being responsive and super fast? No Way!
But that's what my system should be able to handle if apps were written properly, and still have enough idle time for the SETI grid. These apps should be able to load and close in less than 1s too.

And no, don't listen to the BS about unnecessary optimization will slow down development.. it's all about common sense and good architectures, and not releasing the first test code that works and call it beta forever.

Stop the waste cycle!!

Give me native code!

[X3J11]

Give me native code over interpreted code any day! End users (at least the ones with knowledge of such things) are always complaining about code bloat and how, in spite of improvements in hardware speeds, software always seems to be running slower.

I think it's time to go back to native assembly programming.

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.

The real question hasn't been asked yet

[CokoBWare]

We know that native assembly and low-level compiled code always tends to be faster. We know that JIT/interpreted languages provide a great tool-set to work with (reuse, reuse, recycle). Sure one could make arguments on both sides why these aren't true, and why one truth could apply to the other. The real questions aren't being asked here. These questions need to be asked:

1) What added value does the JIT/interpreted code base bring to the table for end-users (not programmers)?
2) What added value does the native code base bring to the table for end-users (not programmers)?

I think there are many value-added propositions when both questions are answered. The truth I think is that we can't live without EITHER model. IT benefits from the JIT/interpreted codebase, and mathematical computation applications (games, science, etc.) benefit from native code.

There is a place for both in our world. Let's just accept this and move on.

Native Code will ALWAYS be there....

[Chanc_Gorkon]

Native code is going to always be around. Someone has to WRITE the Virtual Machines. C is STILL valuable after all of this time.

What you WILL find is that applications programming may all switch to Java or C#. The reason is it is very hard to have some of the traditional problems with programs with a properly coded JVM. Sure, buffer overflows can happen in the JVM, but it's way less likely to happen in Java/C#. That means the applications will need less work over time. With that said, the JVM's and the .Net Virtual Machine will still need programmers to write them and add to them. Kernels will still need to be written and X windows will still need to exist.

Re:What?!?!?

[rbanffy]

Can you clarify this? You mean SIMD functionality was available in some (which?) CPUs _before_ SIMD instructions were added to the specs?

You dont see games/driver/oses in managed code

[mrjimorg]

If Microsoft wants to demonstrate how fast managed code is, then why dont they write their drivers and their lower level os in managed code? But, as you'll notice, they don't. There are reasons for that - its just not fast enough, and garbage collection has too many problems (wasted memory, pauses, etc)

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.

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

[Monkelectric]

Delegates are *really* arrays of function pointers that have the conveniant notation of being able to call the entire array with one line of code. This is handy when thats what you want to do (event/subscriber pattern). Its horrible when you actually want JUST A FUNCTION POINTER :)

Loss of Control

[Sentry21]

As much as I'd love to love Java, and as much as I know most people would if it truly delivered all that it promised, there are a lot of issues with it that can tend to cause problems. One example that bit my company:

Our company writes and sells a large medical imaging archival system, and one of the components of it is a web-based front-end using Tomcat, which accesses the backend database for pretty much everything.

Recently a feature was added to our software which opens a database connection to the various other servers in the system to check the status of their queues. This worked fantastically in testing, but when it was deployed, we found sites whose frontend became completely unresponsive.

After some digging, our developers found these:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4263113
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4912686

The long and the short of it is that JDBC calls (DriverManager.getConnection()) are sychronous, meaning that you can only be opening one connection at a time. This works fine in an ideal circumstance, but if one of the hosts you're trying to connect to happens to be off the network, then all threads in all apps in that JVM have to wait before they can open a connection.

As a result, when our background thread cycles through the databases to check the status of their queues and comes across a down server, DriverManager.getConnection() blocks - for three minutes! - while the TCP connection times out. This means that our entire application locks up completely, since every action requires a database connection. Sun's response?

'Introducing a change such as this risks breaking existing applications that have come to expect this behaviour.'

I like Java, but problems like this are just absurd. In C, I could either rewrite the library, or (preferably) change the source of the existing library. Failing that, I could fork separate processes instead of threads (ugly and inefficient). In Java, I don't have this option, because it affects the entire JVM. Fortunately, there is a workaround, but it's not a particularly fantastic one.

Java/C#/etc have a great deal of benefits over C/C++/etc, but there are always going to be problems as long as someone else decides what should be fixed and how. The real question is whether or not, for your application, the benefits outweigh the (potential) drawbacks.

Re:Loss of Control

[chez69]

connection pooling was invented to get around that problem. the connection is already open when you get it (unless the pool needs to create another one)

I've been a programmer on some very large DB driven apps, and I've never run into that kind of stuff. you just need to use the tools that are available.

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

[ciggieposeur]

I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi.

If you are looking for the next One Great Language (as I was last year) I'd strongly urge you to look beyond Java for a few practical reasons:

1) Sun and IBM may be gung-ho on Java, but it's losing ground compared to Python, Ruby, C#/Mono, etc. (Check this out too: http://oodt.jpl.nasa.gov/better-web-app.mov .) As a former J2EE developer, let me also state that Sun is very slow with fixing critical bugs, and many more of those bugs appear on typical desktop applications than the server.

2) As a language, Java is "OK" but not all that great, and it doesn't look like it's going to get much better over the next decade. "Better" in this case means how quickly you can write good abstractions.

3) Its lack of a Java-certified yet free-as-in-speech runtime stack is a problem. I wouldn't commit any of my future livelihood to the sufferance of any vendor, Sun or otherwise.

4) Java doesn't integrate that well with non-Java code. JNI is a pain to use (I've done it), the APIs that do talk to the OS are lowest-common-denominator and hence usually incomplete for any serious work, forcing you into JNI. If you're going to use a platform that insists on a clear separation between its runtime and the underlying OS, you may as well go with Lisp and at least get multiple free implementations and serious language abstraction.

Anyway, I'm not trying to preach here, Java's got a great place and powers a lot of the world. It's just (to me) not a good choice for the One Great Language, he one that you switch your primary problem-solving-think into. It would be like deliberately choosing to use Cobol in 1988 when Turbo Pascal was already available.

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

[theonetruekeebler]

A lot of people are dismissive of Java as having failed on client GUI apps.

I'm one of them: The early Java GUI tools were a well-thought-out abomination that sent droves and droves of developers in search of better solutions. A lot of them saw VB just sitting there, and all their customers were on Windows anyway, and now Java's in an irredemable hole as far as GUI development goes. This is good, because innovative projects often start as a reaction to suckage elsewhere.

So Java itself will never make a serious dent in the realm of GUI clients. The reason is very simple: AJAX and SaaS are using the interface provided by the browser. Browsers have reached a capability threshold that is making them the client-side platform of choice.

We're reaching the point where, as far as desktop machines are concerned, the OS simply the framework for a windowing system, and the windowing system is simply the framework for the browser, and all HCI will happen in the browser. Sure, the server-side of the app may reside on the same system, and be written in just whatever language happens to be there, but all it will do is exchange XML and HTML with Firefox.

The OS is becoming an afterthought, and the Windowing system is an afterthought with skins. The browser is where it's at, and MS is gonna be hurtin' if people see Vista as merely the tool behind the tool behind the tool they use to get their jobs done.

Programming as if performance mattered

[Junks Jerzey]

article here

He Who Laughs Last

[Prototerm]

MS-Windows Vista's system requirements means that future Windows boxes will laugh at the memory/processor requirements of current interpreted/JIT compiled languages

That is, of course, unless it is the consumers who laugh at Vista's absurd requirements, and just stick with Windows XP. Anyone who wants the pretty eye candy can just spend a few bucks for Stardock's Object Desktop, which works without the hardware investmnent. As for the so-called security enhancements, we all know that, for every vulnerability fixed in Vista, Microsoft will introduce two more, thanks to their Insecurity By Design principles.
So the assumption here is flawed. Vista will have little or no impact on memory/processor power out there in the real world.

Arrrrrgggg Is it 1983 again?

[mlwmohawk]

Short and simple, interpreted/virtual machine code has its place, but it does not make porting easier. Simple programs can be written in *any* language and be easily portable, obviously, some more than others, but all pretty easy.

Once you get in to complexity: memory constraints, performance constraints, large processing, and so on, interpreted and vitual machine systems directly impact the viability of the code. A virtual machine or interpreted system can use more than an order of magnitude more resources than a well coded C/C++ program. If your program is a couple megabytes, well, 20 or so megabytes is not too bad for Java. If your program takes a gig of RAM, then 10 Gig may make your program unworkable.

Then there's porting, don't get me started. Most of my time coding in "portable" java is figuring out the differences in the different virtual machines.

Like I said, an easy program is easy, almost any language and environment will do. More complex programs require more direct control over the actual processing.

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

[zootm]

Actually that's only true of multicast delegates — there are some which only ever point to one function, although they're obviously not used so much since the main use of delegates is the event/subscriber pattern.

Of course, there's always the issue that function pointers, in most implementations, are inherently unsafe, so they're quite hard to wedge into a "safe" language like C#. It's one of those quandary things. I'm not convinced that, in the paradigm that C# implements, there's all that much use for function pointers as it is, though.

Why lump JIT and interpreted together?

[induhvidual]

JIT compiled languages give you native binaries... don't group .NET with python, et al - it makes no sense to do so. Do you really not understand the difference, or are you simply a fan of some of the interpreted languages and are looking to manufacture some sort of fake equivalence as an excuse to use them? Your argument amounts to "we will have a huge amount of ram and CPU cycles, therefore we can feel free to waste them on interpreted code rather than compiled native binaries". Huh? Good luck with that - I am sticking with .NET and C#.

Have Your Cake And Eat It, Too

[Whip-hero]

You're not really asking about interpreted vs. compiled languages. What you're really asking is whether computers have gotten fast enough for us to stop using low-level languages and let the computer handle many of the details in high-level ones.

But, I think the whole question is bollocks because it's based on an incorrect assumption.

There is no inherent tie between LLLs and compiled code, and HLLs and slow, interpreted code. Some HLLs can be compiled into very fast native code. A quick scan of the comments tells me that the name has already been dropped, but I'll put in my plug for Common Lisp. It allows you to use interpreted functions and compiled functions both in the same environment, so that you can develop code quickly, then compile it to get a speed boost. If you need more low-level control to get some extra performance in a bottleneck, you can even do things like declare data types and lower compiler safety levels for individual functions.

Lisp was doing this decades ago, and it was even being used for operating system code in the Lisp Machines. So, computer power really has no relevance to the issue. I think the real barrier to adoption of these kind of high-level techniques is not in the machines, but the beliefs of developers who still think that real programmers do thier own pointer math.

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

[blakestah]

I am a Pascal programmer from ancient days

I'm sorry, you lost me there when I spit out my coffee on my keyboard.

Pascal was a language written to teach people to code, not to actually
get work done.

Interpreted languages, or scripting languages as I like to call them, GENERALLY are real crappy with memory management, bloated, pigs of software.

Perl is a lovely exception.

But Java or Matlab or VB seem to thrive in using as much RAM as possible to get a job done. Any serious work I do in any of them I end up re-writing in C/C++ in order to streamline the RAM usage and make the program work reasonably.

And this is the main reason Java will not take over as a dominant desktop theme. People actually like programs to work and not lock up the machine and screech it to a halt.

Real programmers manage their own memory usage, and don't think of it as a nuisance, but as a mission critical objective, because too many scripting engines are REALLY bad at it. Java on linux is a great example. It is real buggy and locks up a lot, and cannot do ANYTHING without loading 250 MBytes of libraries into RAM. That's crap, and it will always be crap. It is possible to write scripting engines that do not suck, and when that happens in something like Java it WILL take over because programmers want their programs to work first and foremost, and secondarily want to code it quickly.

It's colloquial, not absolute

[Jesus_666]

I'll add to this rather pointless discussion: We're talking about colloquial language here, which is highly region-dependant. Don't expect things to have just one meaning. For example this is how words are used in my region (Northern Germany, more specifically the Bremen region):

"North America" is a continent.
"South America" is another continent.
"Central America" is what's between the above.
"The Americas" is not used at all and most people would tell you that "America" is used in the singular.
"America" is an ambiguous descriptor used for either North America, North and South America or the United States of America. South Ameria is usually called by its full name.
"American" or "Ami" (say: "uhmmie") is an ambiguous descriptor used for an inhabitant of North America, an inhabitant of America (where the exact continent is not explicitly mentioned), an inhabitant of the USA or a large sugar cookie made from sweet dough related to the "Black and White" cookies that came to Germany during the occupation (cf. de,wikipedia.org).

There is no unambiguous term used to refer to an inhabitant of the USA, except for the term "US American", which is not used colloquially.

charming

[sgt scrub]

Talking about bringing out the grinders. Anyway.

I agree that people are going to be buying ever larger and more powerful systems. Yes, this will make bloat less important. Yes, this will give jit type languages a bigger role in larger applications.

I'd rather the future become more charming. http://charm.cs.uiuc.edu/

More than Just Portability

[Bob Uhl]

There're more advantages to interpreted than simple portability--and in fact interpreted code can be just as unportable as native code (if I'm calling Win32 APIs on a Linux box, that's a Bad Thing). However, most interpreted environments provide at least some portability by their nature (bytecode or sourcecode), and most provide some portability layers.

There's another advantage, though: interpreted environments typically provide a great deal of introspection, reflection & dynamism. One can redefine functions & methods, extend classes, extend the environment and such at runtime.

And of course Common Lisp offers the portability & flexibility of an interpreted language with the speed of a compiled language: yes, it's a language as dynamic as Python or Perl (much more so, in fact) which is compiled down to native code. How's that for nifty?

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.

Re:Philosophical reason why higher level is key

[SkipStein]

I agree. See my white paper on this subject: http://www.skipstein.com/Documents/wrong_turn_in_c omputing.htm

sweeping generalizations

[cow-orker]

The performance hit is not always negligible (there's a reason why numerical work is still coded in Fortran), and I'd like to see the "intepreted language" that has shorter development time and is more powerful than OCaml. And what's more widely available than C? Probably only BASIC.

Besides, being compiled/interpreted/something-in-between is NOT a property of a language but of a language's implementation. Use Haskell and you can choose between all three. There are more things than C- and Perl-lookalikes.

Re:What?!?!?

[Doctor Faustus]

15 years ago I benchmarked assembler vs c for graphics code - c was 200 x slower.
Did you try a "compile via assembler" and see what the compiler was doing? There must have been something stupid happening.

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.

Not likely

[TuballoyThunder]

First, your interpreted language has to use "native code." Second, in applications that are CPU bound, like scientific computing, the overhead of an interpreted language is not acceptable. Third, the largest computer market, embedded processors, will, in all likelihood, always compile to native code.

Re:What?!?!?

[tomhudson]

No problem. First, look at Intel's first effort:

http://en.wikipedia.org/wiki/Streaming_SIMD_Extens ions

ntel was generally disappointed with their first IA-32 SIMD effort, MMX. MMX had two main problems: it re-used existing floating point registers making the CPU unable to work on both floating point and SIMD data at the same time, and it worked on only integers.

Now keep in mind that you can load 8 different values into the fpu, and issue one instruction to act on all of them.

MMX used the fpu registers. So did 3dNow.

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

[julesh]

Err... the first public release of Java was on 23 May 1995. There might have been some code for it in 1990, but it sure wasn't ready for release.

But the other dates you quote are first release dates. You're comparing apples & oranges.

(Admittedly, Java's was the longest period without public release... of the others, Ruby had the longest such period having been started in 1993) (All information from Wikipedia. Look it up yourself.)

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

[gnuLNX]

"Perl is a lovely exception."

I am sorry you lost me there when I choked on my coffee. Perl is pathetic attempt at a good scripting language. Having learned several languages now I have to say Python takes the cake "I am a scientific programmer". If however I wasn't doing computational work I would almost certainly use Ruby. I hate perl. I despise Perl. Perl Sucks. Perl blows snot rings...bet ya don't know what a snot ring is do ya? That's becuase you program with Perl! j/k btw

I used perl for several years. I honestly hated it from teh get go.

Re:What?!?!?

[tomhudson]

Thus, while the server is running, it is executing mostly JITed native code.

... and it still runs SO much slower because of the overhead in runtime checking ... the runtime has a LOT of housekeeping stuff to do, as well as verifying that yes, we've encountered this method call before, so lets look in the VM method cache. Even if it turns out that every method invoked already has a native code equiv. already compiled, its always going to be s.l.o.w.e.r.

Plus I really like the ability to do pointer arithmetic. Can't futz around with pointers in java, so you're always taking the long road from here to there.

Re:What?!?!?

[tomhudson]

It wasn't that there ws "something stupid happening" with the compiler ... its that, for some repetitive operations on video card hardware registers you can take shortcuts the c compiler can't. It doesn't "know" enough.

When will boneheads stop asking this question???

[sribe]

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

Some of us work on projects where multiple orders of magnitude is not considered negligible. Anybody who's actually delivered software of any complexity understands this. Twit. ...are just as powerful as languages that generate native code.

"Substantially more powerful in many cases" would be more accurate. And since there's no point in using any interpreted language that is not, I'd abbreviate that to "substantially more powerful" and be done. In other words, your attempt to sound neutral on the subject is transparent. Twit. ...current state of interpreted/JIT compiled languages?

Uhm, don't JIT compiled languages output native code to be run? We could argue about whether it's better to compile early or late, but... And anyway, JIT compiled languages are really not much more powerful, if at all, than compiled languages. Java and C# are incremental improvements, at best, over modern C++. It's the interpreted languages that are really more powerful, so you're conflating 2 subjects. Twit.

Interpreted languages are very very useful. And there are also very many projects where they are simply not appropriate.

Britain is not just England

[jdbartlett]

What about the English spoken in Wales?

It's British English; it's a standard throughout Great Britain, not just in England.

static vs. dynamic typing

[monkeyGrease]

The real difference to me between compiled and interpreted is not the speed. It never really has been. It is the typing. There are areas where I want static typing, such as large architectures with many developers touching related code. Compiler type checking can be very valuable in such cases.

On the other hand in projects with more isolated nodules, lots of shallow glue, or quick turnaround prototyping, I like the freedom of dynamic typing.

Note that languages like haskell, Java, and C# really fit into the compiled camp, not the interpreted camp...and they are all static typed. JIT is still compiled. True interpreted languages are more like python, perl, lua, and sh.

I think compiled and interpreted are very complementary, and I personally like stack of python/C++/lua. Extend python with C++ which in turn embeds lua. lua is easier and faster than python for script embedding, while python is easier to extend and has more libraries for the orchestration/glue role.

Interpreters have their place, but also limits...

[duodave]

I've not yet seen a virtual machine that was fully useful. The inform z-machine, java, Apple's early forray into running old Mac software on the PowerPC, the SoftPC that ran Windows on a Mac. They all had limits. While they can emulate a processor, they are still a virtual machine. While there's a certain security in running applications within a virtual machine (if theres a crash, it happens within the virtual machine and hopefully doesn't affect other applications, or in Java's case Java is prevented from greatly affecting the system at all) I'm not convinced it's worthwhile to market full-fledged applications written in virtual machines.

I will have to say, however, that the enterprise software market has embraced the virtual machine. Many enterprise groupware apps are written in Java and .NET. That, I'm sure cuts down on development time and opens their products to more platforms, but I'm sure it's limiting in what their developers can actually do.

England is in Britain, it is not Britain

[jdbartlett]

But England is only one unit of the collective that is Great Britain. British English is the standard throughout Great Britain. Great Britain is not England. It's also Wales and Scotland. Complicating the matter is that there are still Gael folk in Wales and Scotland, but that doesn't change British English from being the standard English throughout Britain.

Look on Wikipedia and you will also find these variations of English within Britain:

English English
Scottish English
Welsh English
(among others)

Here is a complete list of dialects of English:
http://en.wikipedia.org/wiki/List_of_dialects_of_t he_English_language
Note how many dialects there are within Britain!

Re:What?!?!?

[bunions]

right, but that wouldn't have made a good joke ;)

Re:What?!?!?

[dave1g]

lol I guess I wasn't thinking correctly. I meant hard drive :-p

The problem is language design

[HiThere]

C and C++ are just poorly designed languages for medium to large projects. The problem isn't native code, it's language design.

My current favorite language design is D (Digital Mars D). Unfortunately, it's still Beta and doesn't have any libraries to speak of, and won't link to GCC libraries. (There's an offshoot of it that will, called gdc, but building it requires recompiling gcc.)

Python and Ruby are very nice languages, but I would prefer not to choose them, and take the performance hit. Python, however, at least has the libraries (and so does Ruby in some areas). Python and Ruby are nicer languages than D, but they intrinsically have the performance hit of an interpreter (virtual machine). This causes much problems when you are trying to multi-process your code. So far my best answer is multiple independent processes that communicate over sockets...at one VM/process...I'm really hoping that D either matures rapidly or acquires the ability to link to gcc C libraries. If your code slows by a factor of two every time your processor speed doubles...then you aren't getting ANYWHERE.

Try Erlang

[h4ck7h3p14n37]

Take a look at Erlang, it's an interpreted language from Ericsson and can support that sort of load. It's used mainly for soft real-time constrained, telco applications. There's an old video demonstration of the language available here.

Re:What?!?!?

[SillyNickName4me]

Hehe, I figured.

That said, I'm running the mldonkey p2p client (does a whole variety of different networks, including bittorrent) and its sharing some 60 or so files and downloading another 50 or so. It currently needs 30mb for the core, and another 35 for the gui if I want to run that.. Which is quite a bit less then Azureus in similar circumstances it seems.

For all I can tell, the reasons for this is not so much java as a language but the universe of libraries and junk that comes with the typical jre and the fact that using a garbage collector without too hefty a performance penalty (or a gain at times even) requires quite a bit more memory.

Re:What?!?!?

[heson]

There are still heaps of amazing stuff released on the demo scene. And the scene is trojan and virus free.

Re:What?!?!?

[An Onerous Coward]

Fair enough. But C does provide about as little abstraction as one can expect from a language. I would argue (with some expectation of objections) that the greater the amount of abstraction, the more functionality a programmer can readily keep in his head. Say you have a subroutine that you can do the simple, slow, easily understood way, or do it the blazing-fast, well optimized, difficult to comprehend way. Which one you go for depends on several things, one of which is, "how likely is it that this code will need to be modified in the future?" If it's nice and modular, and you can wall it off so nobody need touch it again (and the performance boost is worth it) then go ahead, and shut the door behind you.

On the other hand, if it will require future programmers to understand and modify it, and you still need the performance boost, then the additional inherent complexity the programmers will have to memorize necessarily comes at the expense of something else.

Therefore, I believe that a simple, easily-grokked codebase is important. I think interpreted languages (esp. my favorites, Python and Ruby) allow for such simplicity. It might not be an overriding factor, depending on the job. But it's something to account for.

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

[blakestah]

Perl is very C oriented in its syntax.

I shouldn't have excluded Python. Both Perl and Python are reasonable in memory management, as in a simple "Hello World" program doesn't require 250 MBytes of RAM to execute.

Others, not so much, ESPECIALLY Java.

I do mostly scientific programming, I use Matlab for a lot of quick and dirty stuff, Perl when it requires a little more programming, and C/C++ for any real heavy computing because the others are JUST TOO SLOW. There is no good reason that Matlab or Perl or Python should be 10 times slower and use many times the RAM as C/C++, but they do. And Java is a complete memory hog, off by an order of magnitude.

Erlang Video

[h4ck7h3p14n37]

Speaking of Erlang, have you seen the video?

Re:What?!?!?

[G Morgan]

A good example of that, consider Azureus. Say there are 500,000 Az users on the planet and say a 2GB memory stick costs £50. Thats £25,000,000 spent to account for the use of crippling Java. Now consider uTorrent, it will run on a 133Mhz machine with 16MB of RAM. You've actually saved people a lot of money because machines that were previously rendered useless due to the spread of intepreted and JIT code have now been given a use because uTorrent can run on them. Personally I'd pay money for uTorrent because I like to multitask and thats entirely impossible with Az taking 2.5GB of page file on XP on a machine with 1GB of RAM, just a pity that theres no Linux port but I can run Linux in a VM while uTorrent runs on the host machine and its still more efficient than Az. When you can run an entire second OS in a much smaller footprint than a BT client then something is wrong. As I see it, people code in Java to save time/money. I expect that saving to be translated into the price. I'd also spend more on C/C++ equivalents quite happily.

Re:What?!?!?

[kiatoa]

Try chicken scheme. http://www.call-with-current-continuation.org/ most of what you want and an (IMHO) elegant language.

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

[Monkelectric]

Agreed. But I like to live dangerously. The more "dangerous" features a language has, the more leeway it gives us architects.

I really would like to see Iron Python work out :)

Re:Linguistic maturity

[Anonymous Coward]

Why are ticket trackers written in zope not even 1/10th as good as eventum written in php?

But, of course, then you are distorting the meaning of the statement. The original statement, as written, means "there is not a single ticket tracker written in Zope that is comparable to Eventum." When you change the language like you have, it now can be taken to mean "any ticket tracker written in Zope will not be as good as Eventum" -- which might be true, but is not what the parent was trying to say. The correct way to rephrase it would be:

Why is it that not one ticket tracker written in Zope is 1/10th as good as Eventum, which is written in PHP?

...which, of course, isn't much different from the original "how come," except that it avoids the colloquialism. In so doing, however, it constrains the language to a prescriptive, whitewashed subsegment of its full vocabulary -- in other words, it's boring.

And, as usual, the real lesson is that if you're going to be a self-righteous pedant, you should at least know what the fuck you're talking about, or else leave the English language to the professionals.

Evolutionary algorithms versus fast CPUs

[DamnStupidElf]

Okay, a more obvious example. Take the TI-85, the calculator I used in high school. Speed it up by a factor of a million. It doesn't get any more accurate, because it's still using the same number of bits to calculate. It doesn't magically gain the ability to solve problems that it couldn't before (unless the problem are time or memory-bound). The advantage to hardware improvements come from the ability to use the right algorithm, instead of hacks to bring in an answer in an acceptable amount of time.

So what happens when you run existing genetic algorithms or neural nets on a computer that's 1,000,000 times faster? I agree that running Word or Quake on a 1PHz computer would be silly, but protein folding or QCD is not. The algorithms already exist, it's just the problem size that is CPU/memory limited. Technically the algorithms may have scalability problems, but if you have a magical computer that's just a million times faster instead of having a million times more processors, the current algorithms will work just fine.

Re:Evolutionary algorithms versus fast CPUs

[An Onerous Coward]

Please step back and try to see the point I've been trying to make this whole discussion: If you don't know the algorithm that will get you the right results (AI), or your source data isn't fine-grained and accurate enough (weather simulation), then all the speedup in the world is only going to get you the wrong answers faster.

This is true even for neural networks and genetic algorithms. For any given neural net configuration and set of inputs, you can only train it so much before your results stop improving (and eventually start getting worse due to overfitting). If your NN isn't properly configured (not enough layers, or an inappropriate number of nodes for each layer) or if you've chosen the wrong features as input, or if your training data is warped, the NN won't get good results. All faster hardware can do is get you to "the best you can do with what you have" more quickly.

Of course, faster processors let you do things like use genetic algorithms to select the ideal configuration for the neural net. But even genetic algorithms aren't magic. They're just one possible shortcut for exploring a large number of hypotheses. At best, GA can only match brute force of all enumerated hypotheses when it comes to the final performance of the selected algorithm. You still have to design your hypothesis space in such a way that a good solution lies within that space.

The problems I was referring to strike me as the sort where we haven't developed ideal approaches to the problem, and running the current approaches on beefier hardware aren't going to close the gap. Hence, my indignant response. My hunch is that, once we do find the proper algorithms for them, many of them will run surprisingly well on current hardware.

Uh, "negligable performance hit"?

[Heretik]

Despite what the VM fanboys like to spout, performance does still matter for a lot of applications.

What do we lose? Speed. Duh. You had to ask?

Re:What?!?!?

[Kazoo the Clown]

I've only identified one task they're good for so far.

If you're a professor who needs to present an application to students over the web for some purpose-- such as a simple physics equation simulator or some kind of calculator for instance, you can't assume that all your students are going to have PCs. So, by implementing something in Java it will run on PCs and Macs and most anything else...

I've seen a few of these, and they're usually pretty quirky but they apparently work on any platform. I've yet to encounter another need for that kind of platform independence, and I'm not a professor so I've not needed to do this, but it would appear to be about the only tool for the job so it is defacto also the best tool for the job.

On the other hand, No way would I buy a commercial package written in Java. A long time ago I realized that if you buy a computer, there are packages written expressly for your machine, and there are "ports" which are written to run on a variety of machines. Generally, the native packages perform far better and are not afraid to take full advantage of the special features of the hardware which is why I chose the machine in the first place. Now there are exceptions, I've seen packages that come in both Mac and PC versions that both seem to be well done (and largely native-coded too, BTW), that are worth buying. But I've yet to see a Java program that is anywhere near the quality or performance of a Photoshop, or a Maya or even a Star Office or a first-person shootemup or flight simulator. Is there anyone actively working on such products in Java? Or even in .NET managed code? Wake me up when there are, and then ask me if I'd buy such a package...

Re:What?!?!?

[John Courtland]

Come on, 3D graphics have been around a lot longer than 15 years. OpenGL itself is almost 15. Even a 286 PC could render 3D (fixed point or on a 287), it's only linear algebra, it just wouldn't look as pretty or be as fast on that old hardware, but the math is the same and you can do it in assembler just the same.

And no, the compiler is not "smarter" than a properly educated assembler programmer who understands the problem domain. The compiler is better than a poor assembler programmer, sure, and probably even an average one, but it will not beat a well thought out, hand tuned assembler program.

HLL game engine example: Panda3d

[Mark Programmer]

A couple of posters have mentioned that even though they would do regular desktop applications in an interpreted language, they would still leave high-performance applications (like games) to low-level native-code languages.

For those who haven't seen it, Panda3D is a game engine with a Python interface. It is the system underpinning Disney's Toontown MMO game for kids (IE required, because the website needs ActiveX). Panda3D is a full-featured game engine for Windows and Linux (with an unstable port to OS X; the Windows release tends to lead the pack). It has support for graphics, sound, networking, UI, collisions, physics, AI, and the Cg-shader language for high-end graphics cards. On top of that, the developer gets the advantage of a built-in engine profiler (for ironing out those trouble spots), an object placement tool, and the regular reflection, auto-documentation, debugging features, and libraries of the Python language. It's also open-source.

We used Panda3D on a project and were able to go from scratch to a complete product in a matter of two months. I sincerely doubt we'd have had that kind of turnaround with almost any other language / engine combination. From the nifty things specific to Python (pickling, solid dynamic typing, interactive runtime mode, runtime mutable classes) to the simple things that you expect from any high-level language (strings as a type, as opposed to "bag of characters;" automatic memory management; exception objects), we used about every aspect of the system to keep our project on-time and on-budget. If we had chosen a system such as SDL / C++, I suspect that the memory management issues alone would have bogged us down terminally.

Personally, I think there are a couple of lessons to be learned from the Panda3D example:

1. Many problems are well-understood and well-implemented. If you find yourself spending much of your programming energy re-inventing the wheel, you are wasting your time and your employer's money. HINT: Memory management is a terribly well-understood problem, as is capturing keyboard and mouse input, as is reading and writing a file or network socket.
2. High level languages let you get to the trouble-spots of a design more quickly so that you can address them earlier in the implementation phase. During development, we found the framerate started to drop precipitously. However, the profiler showed the issue was not in the game logic, but in the render loop. A quick trip through Panda3D's 'analyze' tool told us that we were asking the graphics card to handle 500MB of texture per frame; we simply hadn't placed a limit on our texture sizes. If it had taken us twice as long to get to the point where we realized this mistake (say, if we had burned a lot of time coding memory management and file I/O, or even if we'd burned time making sure our .h files were aligned with our .c files or tweaking our Make scripts), we'd have been in twice as much trouble.
3. While we never had to optimize to native code, if it was necessary it could have happened. Python has tight native bindings allowing you to expose a C or C++ interface as a Python type, which means that the "workhorse" part of that type's function is happening in native code. It is worth noting that large chunks of Panda3D are in fact written in C++; however, other chunks (the chunks that are better expressed as metamorphic constructs where components can be easily added or removed, such as the "direct" GUI widget system) are kept in Python for easy subclassing and modification. Much as C allows you to slide into assembly if you must, good high-level languages make it easy to transition to a low-level implementation where needed. I'm not sure the same can be said of the ease of accessing high-level features from a low-level language.

So there's one programmer's experience with hig

Re:HLL game engine example: Panda3d

[Dr. Sp0ng]

Something you failed to mention - Python, as compared to other interpreted languages, is particularly slow, and yet is still fast enough for commercial game development. A .NET language would have even better results (I have actually used C# quite extensively in a game engine), as well as having the added benefit of a much more pleasant DirectX API than the native COM interface provides.

Re:What?!?!?

[Junks Jerzey]

I don't think it's true to describe Perl as an "interpreted language". Firstly because it's compiled, at run time before execution.

By that definition, almost no languages are interpreted. Perl/Python/Ruby/Lua, etc., are tranformed from text to an internal format: either a parse tree or bytecodes or a list of addresses (a.k.a. threaded code). Then that internal format is interpreted at runtime. None of these languages are compiled to machine code.

Re:What?!?!?

[tomhudson]

[Quote[
        But C does provide about as little abstraction as one can expect from a language.
[/Quote]

Okay, but the c preprocessor allows you to do a lot of "magic." For example, this is a c program that compiles, even though it doesn't LOOK like a c program (I wrote it this morning just to show that a cgi in c doesn't have to be complicated):

        #include "html.h"

        title("this document was generated by a c cgi");
        body("bgcolor='silver'");
        b("Hello, world");

        end;

It doesn't look like a c program, but it compiles just fine with gcc. Even someone who doesn't know html OR c can grok this in a few seconds.

Go to http://groupehudson.com/postnuke/index.php?name=Ne ws&file=article&sid=98 to see the header "magic".

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

[zootm]

Well, it's a case of which "unsafe" things you allow, I suppose. I don't personally think that direct memory manipulation through pointers and the like helps you if you're using a rich language, and you don't want to actually write something which manipulates memory as its primary function (like a garbage collector or whatever). Dynamic typing is a different matter though, particularly for Rapid Application Development. Another fun-looking language for the CLI is Boo, which is "Python-inspired", with (optional) stronger typing and more influence from CLI languages, rather than an actual dialect of Python, as IronPython is.

Re:What?!?!?

[tomhudson]

I see they STILL haven't fixed the "extra spaces in long urls in a long line" bug ..
http://groupehudson.com/postnuke/index.php?name=Ne ws&file=article&sid=98

Lets hope THIS url doesn't get b0rked by slashcode.

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

[gnuLNX]

I agree. I hate Java...I'm also opinionated!! LOL. I am a C++ code for the most part. When forced to use a scripting language I have found that python is the easist to extend and embedd. It's all just a matter of opinion for sure, but I will say that once I was convinced to learn Python I did have to conceed that it was the most maintanable language simply because it doesn't allow 50 million way's to do something. Just my thoughts tho.

Re: C++ is bad? Move to Java or C# !

[Anonymous Coward]

PS. Example of code that compiles with GCC and microsoft's CL.EXE but never does what it seems to do - It never calls fct2():

That's because the int x = fct1(), fct2(); declares a variable x and assigns it, as well as declares a function fct2() that returns an int. In other words, the fct2() is a function prototype. Normal behaviour.

standards

[Stu Charlton]

Since when do standards bodies make for a higher quality specification? They exist as a political process to ensure a wider 'supported' specification & to ensure stakeholders get their say at the table.

The Java langauge spec is very well defined, and there's more than one reference implementation of a JVM available to study... which is why you tend to see a lot of separate codebase VMs for Java (Sun v. IBM v. BEA JRockit v. Aonix v. kaffe v. GCJ) and value added derivatives of Sun's implementation (HP has variants for Tru64, UX, OpenVMS, and NonStop, and some have OS-particular features). Compatibility wise, they broadly work well with minor issues -- see BEA's support matrix, for example.

Optimize your thoughts

[fm6]

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

Which you will see is possible, once you get away from your preconceptions.

I knew this conversation would be full of misconceptions as soon as I saw that it classified non-native languages as "interpreted/JIT". Runtimes like Java and .NET have not been based on either interpreters or Just-In-Time compilers for almost a decade. They use dynamic compilers which optimize on the basis of what the program is actually doing. This is something that no C++ compiler can do. This kind of optimization can result in "interpreted" applications that are actually faster than native apps. Not always, of course — it depends on what kind of application you're running. But it does happen.

Also the notion that optimization is about producing the most efficient machine language possible has been obsolete since about the time they stopped using Z80s in PCs. Software applications nowadays are more than symbol crunchers: they consist of complicated I/O and network components, which have to work together for the app to run efficiently. And adding multicore processors to the mix does not reassert the importance of micro-optimization. Quite the opposite: a multicore application is a concurrent (what people used to call "multithreaded") application. Actually, concurrency has been important ever since processors got so painfully fast — but now that the Mhz wars have been replaced by the multicore wars, concurrency is 10 times as important. And the best native code compiler on the planet does nothing to help a concurrent program run better. Only a good concurrent runtime can do that.

When early releases of the Java runtime ran so slowly, everybody blamed the fact that it was based on a simple bytecode intpreter. That was certainly part of the problem, but there were many other parts. One of these was the fact that Java's concurrency API was absurdly primitive and inefficient. That's no longer the case. And with a modern, powerful concurrency API, the Java runtime can handle your umpteen-core systems as well as any native code runtime.

Why Java was invented

[phunctor]

... Java was invented mostly to get around the memory safety problems of C and C++ ... It was invented as an attempt to break Microsoft's hegemony. If it could be a good language too, that was OK. -- phunctor

I am not the author of every GPL program

[tepples]

That's exactly my point. Your choice of a license is what is causing problems here

It's not my choice of a license; it's the program's author's. Besides, as I mentioned earlier and you conspicuously omitted in your reply, neither the compiler nor the binaries it creates work with my Linux-incompatible hardware.

Re:I am not the author of every GPL program

[everphilski]

It's not my choice of a license; it's the program's author's

Doesn't stop you from compiling it on your end. GPL only speaks to the transport of the program.

Besides, as I mentioned earlier and you conspicuously omitted in your reply, neither the compiler nor the binaries it creates work with my Linux-incompatible hardware.

Because you were conspicuously ambiguous as to the hardware/platform. I'm not gonna make a blanket statement about something I don't know about. I'm not an idiot.

Re:I am not the author of every GPL program

[tepples]

Because you were conspicuously ambiguous as to the hardware/platform.

I was under the conception that I had specified the "platform" adequately when I wrote "spend $400 on the Windows compiler". I am a Windows user, and I don't feel that switching from Windows to Linux is worth the increase in performance of the Intel C++ compiler over MinGW GCC.

Re:What?!?!?

[NemosomeN]

I'm not arguing the obvious. Yes, native code is going to be faster, assuming same code quality. They will not be more than two orders of magnitude difference. If the difference is a factor of 200, chances are something is wrong. That's hardly "The nature of the beast".

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?

Two facts

[GWBasic]

FACT: x86 CPUs convert x86 instructions to native microcode.

FACT: .Net bytecode can be compiled when the program is installed.

Deep Blue

[mangu]

We don't know how deep a pure lookahead algorithm would have to go to beat, say, Kasparov

FYI, we do know the answer to that question.

Re:Deep Blue

[usrusr]

the point is: the deep blue software does not do pure lookahead. it does very sophistcated selective lookahead, and by doing that it could certainly beat a computer 100 times as fast as long as that machine would do pure lookahead.

No

[4D6963]

An average PC nowadays holds enough power

No, a PC will never hold enough power, period. There always will be something that will need all of its power and more, therefore ASM will always be used for some tasks that need to be highly optimized.

Re:What?!?!?

[baxissimo]

And no, the STL does not suck.

Riiiight.

<tt>
std::vector<MyClass*>::const_iterator iter = myVec.begin();
std::vector<MyClass*>::const_itera tor end = myVec.end();
for (; iter != end; ++iter)
{
  MyClass *p = *iter;
...
}
</tt>

It makes me want to chop off all my fingers and file for disability every time I have to type something like that, which is quite often. Granted it's all C++'s fault -- STL sucks, but it sucks about as little as possible given the constraints that C++ places on it.

Re:What?!?!?

[atrus]

So? Its explicit. Its clean. And if you want to save typing, use typedefs.

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

[MmmmAqua]

(well, just about - I don't think you can use the top-of-screen menu bar in Swing apps)

System.setProperty("apple.laf.useScreenMenuBar", "true");

Without looking at the documentation, I am not sure if this works with J2SE 5, but for 1.4.x Swing apps it works nicely. :)

One Great Language

[Latent Heat]

Think of me as a customer who drives a Delphi, coming into the showroom to look at a Java and compare it with a Python, and perhaps there is another model that I don't know about, and decide which one to start making payments on and drive home. From the response to my remarks, I feel like I was thinking out loud about why I was leaning towards the Java and a raft of salesmen came out to tell me I was ill-informed about cars.

I have experimented with Python, and Python is great. But it lacks an intrinsic array type, and arrays are as necessary as oxygen for numeric, audio signal processing, frame buffer graphics/image processing, and related work. Yes, there is NumArray and Numeric and NumPy, but a defined array type is a work in progress and there is far from universal adoption of any of them with frame buffer packages. Python is compared with Lisp, and even Lisp came around to having an array type which I understand was well-implemented with slices and all of that, but the Python array situation remains a work in progress. Java on the other hand has an intrinsic array type -- arrays are objects, but they are special types of objects where iterating over the subelements is almost as fast as native code.

Matlab -- very popular in the scientific community for data visualization -- also has intrinsic array types and is highly interoperable with Java and interoperable between the Matlab and Java array types. While there is a movement to develop libraries to make Python a FOSS alternative to Matlab, Python and Matlab don't readily interoperate, and Python doesn't interoperate with Java unless you go the Jython route, which is almost a whole other language, or go with some JNI support packages from CPython that are not actively supported.

Java has the much maligned Swing, but the BufferedImage class and the Graphics.copyArea() method are pretty much direct replacements for CreateDIBSection (frame buffer support) and ScrollWindowEx() (scrolling) in Windows -- I don't see anything equivalent in wxPython or in .NET/Mono/C# apart from "unsafe code" for that matters.

So people tell me the browser, not Java is the platform. Great, I am going to have to figure out how to blast arrays to frame buffers in AJAX and get those images to scroll.

Maybe I am jumping on the Java bandwagon too early -- maybe there is this product/project for implementing scientific data visualization called Python on Steroids, Matlab only following sound software development principles, that is this really well integrated object framework for such apps that is just coming out. Don't know. What I do know is that everything has its product development cycle, and Windows flopped around as a toy for 10 years (Windows app: Dog slow! RAM hungry! I can do graphical apps with mouse selection in DOS (I actually went that route)! They are much faster! DOS games, data visualization, even word processors were much faster in DOS). Then Windows 95 came along. Java is about at the same depth into its development cycle.

Python? That too has a development cycle. Maybe in a couple years it will have the features I want. Maybe I should ignore Java and wait for Python to come around.

My point is that everything has its development cycle and it can take a long, long time for products to reach maturity. Java look and feel all wrong, load times too long? There was a time when Windows was a wart on top of DOS with all of those odd fonts that didn't look right on the low resolution monitors of the day, and you had to run Windows first before you could run your Windows app.

Java, like pre-Windows 95, is a wart on top of the OS that seems foreign to the native OS, but it is a wart that runs on top of multiple OS's. Windows was an abstraction of the underlying PC, and oh the complaints about resource usage, slowness, and loss of access to the hardware and especially the graphics frame buffer. Windows fixed that with a combination of Moore's Law and the WinG initiative and later DirectX to

Re:What?!?!?

[tomhudson]

They will not be more than two orders of magnitude difference.

a difference of 200 is certainly less than 3 orders of magnitude difference, so its not THAT far outside your 2 orders of magnitude expectations.

There was nothing wrong. If you had written assembly/assembler/whatever you want to call it 15 years ago, you would know that the difference was often a couple of orders of magnitude. Heck, I wrote one routine just to spool data off of hard disks, and in assembler the disk transfer rate was twice the official rate on the drive. Surprising, but not that surprising. Custom routines tailored to the hardware are always going to yield better results.

USians? Hah, that's Americans to you, pilgrim!

[tjstork]

Listen up pilgrim, we have the right to call ourselves Americans because everyone on our continent wants to be one!

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

[SteeldrivingJon]

The early Java GUI tools were a well-thought-out abomination that sent droves and droves of developers in search of better solutions.

Netcode Constructor looked promising, but then Netscape bought them and it disappeared.

it's much easier to hide code with compiled langs!

[codedj]

I know a lot of projects that decided to use compiled languages (that compile to machine code, not bytecode) because it allowed to "hide" source code and logic. Originally Java and .NET code was easy to decompile too, but now there is a whole industry for obfuscation of compiled Java and .NET assemblies that scrambles the logic and removes names of identifiers.

Fortunately, tools to hide source code for trully interpreted (dynamic) languages also exist (here is a sample catalogue of JavaScript, Perl and VBScript obfuscators), though sometimes they require adaptation of source code.

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

[JulesLt]

Thanks very much. Hopefully someone will mod your post informative.

Now I know it's actually a case of people not bothering, rather than it being technically difficult.
Or to be closer to my original point - it's the philosophical rather than technical differences that make cross-platform GUI hard.

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

[vtcodger]

***Err... the first public release of Java was on 23 May 1995. There might have been some code for it in 1990, but it sure wasn't ready for release.***

Hmmm. There was a publically released formal spec for Java unlike the other languages. I agree that a formal spec is not the same as a working release. But neither is it a fragmentary prototype or something like that. You can actually start teaching yourself the language if you have a spec and think it is reasonably firm.

I don't know exactly when the spec became available, but I know I reviewed it intensively in 1992 or 1993 before deciding that the proposed data structure for the IL was going to be an ungodly mess -- bad enough that I'd pass on devoting a year or two preparing for a Java wave that might never materialize. I was told later that the data structure laid out in that spec was not, in fact, the way that data actually ended up being represented. I'm not sure where I got that 1990 date from, but I did look it up and the sources looked credible. Trying again, I find a lot of dates, for the beginning of Java mostly around 1991.

I'll plead guilty to comparing oranges to tangerines.

Re:What?!?!?

[rbanffy]

So, as http://en.wikipedia.org/wiki/MMX says, MMX was the first SIMD extension to x86. People were not abusing the FPU - MMX instructions were present in every processor that was SIMD-capable.

The fact MMX shared the FPU registers in a different way does not make pre-MMX CPUs SIMD-capable.

Interpreters for compiled code or vise-versa?

[phorm]

Why can't we have interpreters for compiled code, and compilers for interpreted?

That is to say, when I'm developing and/or debugging, I'd much rather be running my C/C++ code through some form of interpreter, and watching/debugging as events occur. No mysterious segmentation faults, no inserting a gazillion "printf('Works at line X'); ", statements to find that one screwed up line or even character.

By the same token, I'd love to have more interpreted languages happily compile. Perhaps it could boost the speed a bit, and sometimes it would make the packaging a bit more convenient. Also useful when there are things in one's code you just don't want visible (even though I am a fan of open-source, some security/etc routines are best left safe from the unwashed masses). Between the two, neither one is better than the other, but there's no reason we shouldn't be able to enjoy the best of both worlds.

Re:What?!?!?

[tomhudson]

People were using the fpu to do single-instruction multiple data (SIMD) before MMX. MMX meant that they no longer had to pack and unpack the values.

So, no, MMX was NOT the first use of SIMD. It just made the process easier.

JIT coding style creates waste....

[speedplane]

Even though the JIT and interpreted languages are (nearly) as fast as native code in execution, in practive they are not. Languages like C# and Java make it very easy to create many wastfull objects. In C/C++ you don't have convinence of a garbage collector to clean up your mess. In C/C++ you have to keep strict record keeping of all of the objects, and as a result objects get reused more often.
I have found that C#/Java software runs slower only because the coding style does not enforce object reuse.

In a few years there won't be a choice.

[Myria]

From recent actions by Microsoft, it appears that Microsoft's goal is to make native code unsuitable. It is very likely that NT 7.0 will not run native code unless it is digitally signed (or it is so sandboxed that it doesn't matter).

It is impossible to hack DRM when you can't run native code, and that's probably what it's all about.

Melissa