Follow Slashdot stories on Twitter


Forgot your password?

The End of Native Code? 1173

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?"
This discussion has been archived. No new comments can be posted.

The End of Native Code?

Comments Filter:
  • by MBCook ( 132727 ) <> on Monday June 12, 2006 @08:26PM (#15520763) Homepage
    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.

  • by The Evil Evil Muppet ( 857282 ) on Monday June 12, 2006 @08:26PM (#15520767) Homepage
    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 - 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 - []. It has the vast majority of C++'s features (and more), Java/C#-style syntax and ease whilst compiling to native code.
  • The choice of language does not determine if something is cross platform. It has more to do with the choice of toolkits. If you are using GTK or wxWidgets you are pretty safe for being cross platform. C/C++ are cross platform languages, but if you use MFC and COM, they're not.

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

    It doesn't matter if the language compiles to byte code, if that byte code doesn't use a cross platform toolkit, it won't be cross platform.
  • Re:What?!?!? (Score:3, Informative)

    by Midnight Thunder ( 17205 ) on Monday June 12, 2006 @08:46PM (#15520869) Homepage Journal
    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: []
  • Java and Mac OS X (Score:5, Informative)

    by Kelson ( 129150 ) * on Monday June 12, 2006 @08:46PM (#15520871) Homepage Journal
    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.
  • by NutscrapeSucks ( 446616 ) on Monday June 12, 2006 @08:51PM (#15520895)
    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.
  • by kpharmer ( 452893 ) on Monday June 12, 2006 @09:37PM (#15521092)
    > 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:Its inevitable (Score:5, Informative)

    by lbrandy ( 923907 ) on Monday June 12, 2006 @10:44PM (#15521366)
    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".
  • by popeguilty ( 961923 ) <> on Monday June 12, 2006 @10:54PM (#15521407)
    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.
  • by JoshRosenbaum ( 841551 ) on Monday June 12, 2006 @10:55PM (#15521411) Homepage
    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:-1 flamebait (Score:2, Informative)

    by procrastitron ( 841667 ) on Monday June 12, 2006 @11:10PM (#15521471) Homepage
    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 []
  • Re:What?!?!? (Score:2, Informative)

    by larry bagina ( 561269 ) on Monday June 12, 2006 @11:24PM (#15521524) Journal
    take a look at GNUStep Web [], the FREE version of WebObjects. It's Objective C but otherwise satisfies most of your criteria.
  • Re:What?!?!? (Score:3, Informative)

    by tomhudson ( 43916 ) <barbara@hudson.barbara-hudson@com> on Monday June 12, 2006 @11:27PM (#15521541) Journal

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

  • by uniquemorgan7 ( 770320 ) on Monday June 12, 2006 @11:38PM (#15521581)
    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 eng/compilers/clin/219856.htm [].
  • by davidwr ( 791652 ) on Monday June 12, 2006 @11:38PM (#15521582) Homepage Journal
    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.
  • by PassMark ( 967298 ) on Monday June 12, 2006 @11:46PM (#15521609) Homepage
    We wrote the same search engine code in 4 languages, PHP, ASP, C++ & JavaScript. The results are published here, []

    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:What?!?!? (Score:5, Informative)

    by atrus ( 73476 ) < minus berry> on Monday June 12, 2006 @11:49PM (#15521617) Homepage
    Half of what you want is in the C++ STL.

    And no, the STL does not suck.
  • by fozzy1015 ( 264592 ) on Monday June 12, 2006 @11:50PM (#15521619)
    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++.

  • by lokedhs ( 672255 ) on Tuesday June 13, 2006 @12:18AM (#15521767)
    You might find that the D programming language [] is right up your alley. It seems to match most of your requirements.
  • Re:What?!?!? (Score:2, Informative)

    by twitchingbug ( 701187 ) on Tuesday June 13, 2006 @12:19AM (#15521768)
    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?

  • by Kadin2048 ( 468275 ) <slashdot,kadin&xoxy,net> on Tuesday June 13, 2006 @12:41AM (#15521859) Homepage Journal
    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.
  • by kpharmer ( 452893 ) on Tuesday June 13, 2006 @12:47AM (#15521879)
    > 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

    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:What?!?!? (Score:5, Informative)

    by masklinn ( 823351 ) < .at.> on Tuesday June 13, 2006 @01:10AM (#15521941)

    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?!?!? (Score:3, Informative)

    by Sparks23 ( 412116 ) * on Tuesday June 13, 2006 @01:48AM (#15522078)
    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.
  • by ceeam ( 39911 ) on Tuesday June 13, 2006 @03:08AM (#15522281)
    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 :)

    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.
  • by vtcodger ( 957785 ) on Tuesday June 13, 2006 @03:36AM (#15522364)
    ***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.

  • by IamTheRealMike ( 537420 ) on Tuesday June 13, 2006 @05:57AM (#15522676)
    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:two things (Score:2, Informative)

    by mog0 ( 318807 ) on Tuesday June 13, 2006 @06:21AM (#15522734)
    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.
  • by Anonymous Brave Guy ( 457657 ) on Tuesday June 13, 2006 @08:44AM (#15523183)
    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.

  • by QuesarVII ( 904243 ) on Tuesday June 13, 2006 @10:41AM (#15523859)
    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".
  • by julesh ( 229690 ) on Tuesday June 13, 2006 @11:44AM (#15524473)
    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:Euro-English (Score:4, Informative)

    by santiago ( 42242 ) on Tuesday June 13, 2006 @01:25PM (#15525508)
    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 hp#meihem [] for some historical versions.
  • by Anonymous Coward on Tuesday June 13, 2006 @03:04PM (#15526631)
    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.
  • Re:you'll learn (Score:3, Informative)

    by arevos ( 659374 ) on Tuesday June 13, 2006 @06:01PM (#15528034) Homepage
    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.

  • by Fejimush ( 982116 ) on Tuesday June 13, 2006 @06:48PM (#15528355)
    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?! 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.

If graphics hackers are so smart, why can't they get the bugs out of fresh paint?