Internet C++: Competition For Java And C Sharp?

Justin Goldberg writes: "I saw this article over on Linuxtoday about Internet C++, a new language that will bring standard languages and APIs, as well as current applications, to the Internet. Doom has already been ported to Internet C++, as well as X Galaga and Tetris. IDoom (the name of the Doom port) runs pretty jumpy on my machine running X on FreeBSD, but the release is in alpha stage." The reader forums on the site are pretty interesting, too, in discussing whether this is a truly (Free / Open Source) language, and about the extant alternatives.

Problem is, JVM is optimised for Java

Yes, you can technically compile any language to Java bytecode, but there are a few problems to deal with:

* a fixed set of types. For instance, Java doesn't use unsigned numbers, so Java bytecode has no support for them.
* no tail recursion - this is a biggie. If I have a function that the last thing to do is to call another function, then if I compile it to machine code, I can arrange to remove the stack frame before making the second call, so that if a the call path is f() -> g() -> f() -> g() ..., then the stack doesn't blow up. This is really really important for some functional languages.
* Java bytecode assumes that the Java model object orientation is used. This is bad for languages that do things in a different way (such as Eiffel with multiple inheritance), or the many functional/logic languages that aren't object oriented.

These can all be worked around, but at a great cost in efficiency.

What is needed is a bytecode that is designed to be source language independent - able to handle the constructs for any source language without making assumptions about it, and be compiled relatively efficiently into any machine language. Java bytecode is not this language.

I'm confused.

Could somebody tell me why I would want to even come near this when I already have Java and Python? (And real C/C++ for when speed is crucial?)

Both Java and Python are much much nicer to program in than C++. What am I missing?

Do you have any idea what you are talking about?

...e.g. Collections/containers/algorithms that aren't the abomination that is STL.

I do Java and C++ professionally, and believe me - the STL is the best thing to happen to C++, ever. It makes C++ accessable and almost as easy to program in as Java, and it's performance is wonderful. Not only that, it makes writing reusable code simple, and lets you worry about the logic of your program rather than supporting classes like collections.

If you really thing the STL is an abomination, the either you are using a very early version or your programs are very different to what I write.

Re:It's all about the portable libraries

I think you're underplaying the performance problems of Java. I've been using some XML libraries, and was absolutely shocked by the bad performance. In this application at least, Java is at least 10-100 times slower than C++ code.

Bad Java is slower than good C. Good Java is faster than bad C. In actual comparative benchmarking [aceshardware.com], Java is faster than C in two of the three tests done. I'm not aware of any recent benchmarking which has come to the opposite conclusion. If your Java is slower than your C, that's your coding, not Java.

The JVM is not a millstone; on the contrary it is extraordinary powerful technology. JITs are better, of course. But static native compilation is not only not necessary, in real testing it confers no benefit.

Let go of the C myths

It really is time to let go of the C myths. There are two which really get to me:

• C is faster than higher level languages.
  • This hasn't been true since the mid-eighties at least, when repeated actual tests showed that the best LISP compilers produced faster, tighter code than the best C compilers.
  • More recently the myth is that C is faster than Java, usually justified by people who include the startup overhead of the JVM in their Java timings. In fact, careful benchmarking shows that with the best current JITs, Java performs as well as the best C compilers at most tasks, and better at some.
• C is somehow uniquely good for writing operating systems. This view is based on the fact that UN*X was written in C, and UN*X actually is a rather good operating system; and because BSD was available with source early on, UN*X has typically been used as the example when teaching OS design. But operating systems can be written in a wide number of languages. A number of the operating systems I've used over the years have been written in LISP (a good language for the purpose), a number in BCPL (not something I'd recommend) and two (UN*X and Linux) in C.

C is a language which is extremely good for creating hard to trace bugs - memory leaks, data corruption and so on - and extremely poor for programmer productivity.

*gasp* a NEW language?

Slashdot 2003:

Tom Goldfunk announced today the release of the brand shiny new Super Duper Does it all, can cut a can in half, and still not make mush out of a tomato, Ginsu ++ language. This new revolutionary language, though completely the same as other languages, touts the unique ability to "Do the same thing all those other languages do, plus some more cool stuff." Of course, backwards compatibility is shaky, so most applications that run fine in C++ will have to be re-written in Ginsu++, but that's not really a problem, is it?

During his press release, Tom stated that "Ginsu++ is going to revolutionize the way we look at computers. A language that is useable across the spectrum of computers has really been lacking in the past millenium. This will change the way programmers work, since they'll now have to learn a new language on top of the ones they already know. And, to make it more intriguing, we've changed the way the language looks to one of those funky top to bottom "MATRIX" style readouts, which breathes new hope into those die hard monochromatic monitor folks in Zimbabwe."

Tim Goldfunk also used the public release of Ginsu++ to tout his company's next project, SuperGinsu+infinity, due out next summer. "That one," Tom promised, "Is going to rock!!"

Oh, I'm sorry... I forgot the Irony tabs...

krystal_blade

Not really open

Sice most of the code is in a difficult to understand file with over 200000 lines, how can it be consdered open?

What I like about Java and where I hope it goes.

Complete source compatibility is almost as elusive as the "philosopher's stone" which alchemists believed would turn base metals into gold.

Java gets around this problem by creating a binary compatibility standard. But this introduces one very major problem, speed. Java might be a programmer's dream come true architecture wise, but it is a user's nightmare speed wise. The nice thing is that the difference between a targeted compiler and a virtual machine is pretty small. I'd like to see more true compilers for java so that we can do away with pesky virtual machines that just make the program less efficient. Unlike other languages, targeted compilers for java would still have to support the entire language in order to maintain compatibility. Once we see this, I think java will become a viable choice for real programming.

Lee Reynolds

Re:Speed Question?

check out HP's experiment where they emulated a processor using dynamic compilation. It turned out that the emulation was about 25% faster than the real thing.

Dynamic compilation is the future, now we just need a good portable, free, open, bytecode spec to which we can conform.

It's all about the portable libraries

As I see it, the big strength of Java is it's huge set of portable libraries. A portable and well designed framework for building GUI's.

The strength of a language (besides the fact that it has to not suck to begin with) is that language's standard lowest-common-denominator libraries.

If you've ever had to build a GUI in C/C++, you know it is not portable. You can write a front-end to your application in several different frameworks -- or try to work with a lowest common denominator framework that runs on your platforms of choice.

Java not only solves this problem, but does it nicely. Pluggable look and feel's. A well designed framework -- better than some of the other frameworks I've used.

But not only a portable GUI toolkit, but portable everything else with it. e.g. Collections/containers/algorithms that aren't the abomination that is STL.

In fact, it seems to me that Java's biggest weakness is execution speed. It has everything else going for it. Type safe. No unhecked runtime errors. RTTI. Garbage collection. Portable object code. And on and on. Given Moore's Law, it seems that Java, or a language like it is destined to become a widely used language.

Can Internet C++ (or C# for that matter) really already have the huge investment that Sun has made in Java? In fact, I find it ironic that Internet C++ and C# seem to be becomming more like Java than Java is like C++.

Or maybe I'm trying to ask, what does it really bring to the table that I don't already have? (Besides being the C++ language which might be useful if I have a huge investment in C++ code.)

The article talks about lots of standard libraries, POSIX, MOTIF, X, etc. This doesn't give me portability. It means I can only run on platforms with those capabilities. (If I read it correctly.) Or do they mean that they are going to bring X, OpenGL, etc. to everywhere. Now that would be cool. And a huge task.

I just got back from OOPSLA

I just got back from OOPSLA (Object Oriented Programming Systems Languages and Applications) and didn't see a mention of this. Not that that's surprising, but I'd've thought they'd've at least arranged for a BOF.

Still, one of the smartest things I heard at OOPSLA was David Unger(sp?) of Sun recommending that everyone learn at least one new language a year. His assertion was that everytime you learn a new language you also learn alternate strategies to apply in your other languages.
--

This is great...

Before it's ported to Windoze, I'd submit the language spec to the IETF or something and have it declared a Worldwide Open Standard. Then no one can pollute it or de-rail it, without showing that they don't "subscribe to Open Standards". Maybe the authors should have Bjarne Stroustrup [att.com] take a gander - he might provide a ton of help. I'm sure he would like to see this little beauty take a bite out of Java, and C# as well. Cool.

Re:Initial observations on the VM design

Dude, you are way out there.

What do you mean when you say that the problem with Java is that you can "push an integer on the stack and pop it as a pointer"?

First of all, in Java there are no pointers, only references, but I assume that that was just a typo and you really meant reference.

I've just scanned through the list of Java bytecodes. I stopped after the first half dozen I saw that popped values off of the stack because every single one of them stated that there is a requirement that the type of the value popped off of the stack must match the type expected by the bytecode.

In other words, Java's bytecodes as defined by Sun REQUIRE that the values on the stack be of the correct type. It's up to the VM to implement whatever checks are necessary to ensure that this is the case, and to throw an Error if a value on the stack is not of the right type (and I've seen it happen, with mangled code, so I know that VM's do it).

Exactly what bytecode do you think allows an integer to be popped as a reference? Please let me know, because I'd love to check my copy of the VM instruction set spec and verify your claim.

But I think you're confused. There is NO Java bytecode that allows such a thing.

And furthermore, this fictituous problem would have no bearing on the GC whatsoever. When a reference goes out of scope, but has been stored somewhere in the heap, then there are only two ways that it can ever be reclaimed:

1) There is a "free" opcode in the VM that the user can invoke to free the reference because they know that they are done with it. Sun does not provide such an opcode in the Java VM so we have to rely upon:

2) The GC tracks this reference and frees it when it has determined that is no longer reachable from any reachable data structure in the heap.

It would have been nice if Sun had made the GC optional, by allowing for manual freeing, but so be it.

Now as for the verifier - it also has nothing to do with the scenario you describe. The verifier does its work at link time, ensuring that the basic structure of the class file is correct. It is at RUNTIME that this scenario that you describe might happen. And it's not the verifier that handles this - it is the VM itself when, by following the letter of the VM instruction set spec, checks the type of values on the stack to ensure that they are of the right type for the instruction which is popping them, and throws an Error if not.

Your makes no sense and is clearly false.

I would really be interested in hearing a further explanation of your position though, if you still feel that you are correct after reading and considering the above.

Re:Language Bloat

Underground Slashdot Report: Tom Goldfunk held a press release 2 minutes ago detailing a plan to completely dialect out the entire C library. In his hastily prepared speech, he stated that "due to public concern over the ELITISM of programmers, the C language will now be written with the following dialects, so people from all walks of life will benefit." Planned releases of so called DC++ packages are as follows.

Ebonics C++ phat style

Redneck C++ with side order of pork rinds

Pygmy C++ (version has audio tape of clicking sounds)

C++ for Siberian Huskies

Oriental C++ with side order of Siberian Husky C++

Australian Outback C++ complete with the "This makes the deadly computer FURIOUS ANGRY" dude VHS tape.

Ex-Commune Hippy and now wants to make money C++

Government Lingo C++

C++ Mexico version with forged documents for border crossings

Homeless persons C++ in a big brown box

The above versions are scheduled to be released by January of this year, with more to follow dependent on the successful sales of at least one copy of the above versions.

krystal_blade

Why not standardize the BYTECODE?

It strikes me that in this frenzy to get platform independent binaries, the obvious point of convergence and compatibility is getting lost.

Java has its version of bytecode, C# has its own incompatible version, and now Internet C++ has its version. Each bytecode is tightly coupled to a specific language (or small subset of languages), and ne'er the `twain shall meet.

Why not develop the bytecode specification as the point of compatibility? A feature rich "meta-assembly" with all the basic operations, plus a widget toolkit interface, network interface, etc. Provide a specification to the API in a generic, language NON-specific form and provide a reference implementation in a language of choice (Java, C++, C#, Prolog, whatever). Write a compiler backend for gcc and you get a shirtload of language interfaces in one hit.

Then developers can choose they language they want to develop in, and compile to a binary object format that will run anywhere, and be binary compatible with objects written in any other language!

Provide a JIT compiler to convert bytecode to system code, and you get a system native binary, using system native widgets (finally ending the GTK/QT/Motif/Xt wars).

This would make bytecode a sort of half way house between Java et al (One language, one machine, tell me the path to the binary), and CORBA (Many languages, any machine, I'll find the path to the binary).

Granted, Java (and C#) has given the world a new language which does a better job of object orientation than C++, but they have left the world with yet another language dependency, and a shirtload of code that has to be rewritten in a new language to support the new binary format.

Am I missing some big point here?

Russ Magee

Re:Java's problems are not limited to performance

Header files. It's very hard to have an overview of what a Java class can do, since there's no list of methods.

That's just bogus. If the information you want can be cleanly generated from the source, why maintain parallel files saying the same thing?

To get an overview of what a Java class does, generate the Javadoc. That's what it's there for. Even if you haven't bothered to write javadoc comments, you'll get a list of methods and fields for each object. To get a list of methods without generating javadoc, use any semi-decent IDE.

Use a semi-decent IDE anyway. It's amazing how much more productive you can become with the right tools. I particularly enjoy stepping through a program, changing the source from within the debugger, and have it integrate my change directly into the still-running code.

Java classes can only extend one superclass. If you happen to have a whole hierarchy of classes, and only one of the most specialised is to be an 'Observable' as well - bad luck.

As a general rule, if your idea for a class name ends in -able, then you're probably thinking of something better off embodied in an interface.

I've only ever been in very rare cases where I really wanted to use multiple inheritance. Most of the time, instead, I found that when I refactored my code so that it would work with single-inheritance and interfaces, it ended up being far more elegant.

On the other hand, there's no excuse whatsoever for Java's designers having left out enumerated types.

Charles Miller
--

Don't forget this important one

Slashdot C++. It's the same language, but all the keywords are misspelled.

Re:I'm confused.

This isn't flaming, but it's obvious that you've never had to track down any non-trivial bugs involving memory allocation or error codes that were never checked.

When your paycheck depends on shipping code that works on a machine other than your own, you'll appreciate the garbage collection and exception handling.

No, Java and Python don't solve all of the problems, and there are many things that C++ does really nicely. But I've had to pull less overtime tracking down other peoples bugs since I left C++ behind.

Re:I'm confused.

FORTRAN, COBOL and old CPU's like the z80 haven't gone away yet have they? C/C++ is going to be with us for a long time in the future! People want to find the better next language but no one wants to port the old apps to the new language.

Re:I just got back from OOPSLA

What's wrong with a little Eiffel? Or some Algol even? What's wrong with COBOL for that matter?

He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.

Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)

What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.

And as long as the languages keep coming, there'll pretty much never be a chance to really run out.

My list would include:

• C [bell-labs.com]
• C++ [att.com]
• Pascal& lt;/a> [brad.ac.uk]
• Lisp (anything but eLisp)
• Python [python.org]
• Perl [perl.org]
• Smalltalk [smalltalk.org]
• ML [inria.fr]
• prolog&l t;/a> [umich.edu]
• Eiffel [faqs.org]
• Ada [adaic.org]
• a RISC Assembler
• Cobol (those who do not learn from history are doomed to repeat it)
• Java [sun.com]
• BASIC (the non-Visual kind).

Initial observations on the VM design

His heart is in the right place, but the implementation leaves a lot to
be desired. 200000+ lines of code in one source file! Yikes! It looks
like some of it may have been auto-generated. If so, then the starting
files for the autogen process should have been distributed - not the output.

From my shallow understanding of the code (I've spent 30 mins on it so far),
here are the problems I see:

1. Not thread-safe. The VM register state is kept in global variables.

2. If this is their "fast" VM, then I'd hate to see their "slow" one.
Dispatch functions are used for opcodes. i.e. every instruction
involves a table lookup and a function call overhead. Tip for
VM writers: use a switch statement! All of the VM state
can be kept in local variables, which C compilers can optimize
very heavily. If you split it across multiple functions, then
you are defeating the C compiler's optimization of the interpreter!

3. Doesn't appear to be pointer safe, so this cannot be used for
"download and run" applications, which destroys its usefulness
as a real Java replacement. (Yes kids, C can be made pointer
safe - see EiC - it's a question of how much overhead you want
to tolerate).

4. X11 access appears to be more or less raw to the X server. This
would allow lots of fun and games to be played: full X11 gives
you the ability to mess with other application's windows, inspect
the clipboard, the user's resource settings, and generally get up
to insecure mischief.

5. No instruction set documentation so that a better VM could be
written by someone knowledgeable about such matters.

6. Too much code. Another tip for VM designers: if you get 10,000
lines of code into a VM, and you've barely scratched the surface,
then your design is wrong and you should start again. The target
size for VM's should be around 40,000 lines max. Both Java and C#
get this wrong, BTW.

Nice try, but we'll have to wait for someone else to come up with a
better VM design before we can use C/C++ on the Internet. It's possible,
but not this way.

God save us.

According to their own white paper, all these bozos have managed to do is write a 32-bit virtual machine and a version of gcc that targets that virtual machine. Apparently, they've managed to get that virtual machine to run on top of "some" versions of Linux, and "some" versions of BSD, and soon, perhaps, they hope to get it running on top of "some" versions of Solaris.

I imagine this took a heck of a lot of work. Its kind of cool, in a geeky sort of way. But in the big picture of things, Whoop-de-freakin-doo.

The only libraries they claim to have abstracted out are Motif and X-Windows (which I don't recall being particularly system different on Linux and Solaris to start with). Which means that as long as you don't use any of the incompatible system libraries (such as sound, networking, process control, signals, or, umm, anything else), you can write a C++ application with an executable that runs on both Linux and Solaris! (Provided, of course, you have the virtual machine installed.)

It's hard to tell if these guys seriously think this is cool. I think they might be trolling the entire world -- I imagine it must take a few brains to write a new back end for gcc, and I can't imagine anyone smart enough to do that would seriously believe the ability to run the same executable on both Solaris and Linux has any real value any more. If so, they seem to have somehow totally missed where the real value of languages like Java (or Perl, or Python) lie.

Internet C++ shares with Java, Perl, and Python the ability to compile once, and run anywhere (slowly). But so what? If you don't use any libraries, you can already write a C++ program that will compile on Linux and Solaris anyhow. But it totally misses out on the huge portable standard libraries Java, Perl, and Python have developed. And it also totally misses one of the fundemental reasons for C++'s existence in the first place -- the ability to run "close to the metal" when needed.

So, its a new language that combines all the disadvantages of C++ with all the disadvantages of Java, plus all the disadvantages of being a silly little niche language written by a couple of hobbyists in their spare time. I'm certain that James Gosling is shaking in his boots.

Um, garbage collection?

I completely agree that C++ is one of the most versitile and prevalent languages in use today.

However, Java and C# were both designed to *add* value to C++. Sure, Java should have had enums, and C# is Windows only (for now) but the concepts of both are pretty clear -- take the best of C/C++ and extend it to create a new, more powerful language. For example, both Java and C# run on a virtual machine and offer memory management.

While Internet C++ may seem like a pretty nifty idea, it is missing the point a bit. The fact that C++ is hardly a standard (trying writing an application for both g++ and VisualC++) should *not* be addressed by creating a C++ virtual machine. It should be addressed by aggressive co-operation between compiler vendors and with standards bodies that move in internet time, not academic time. And since MS seems unlikely to co-operate with GNU (and vice versa), there is a definite need for new languages such as Java.

If Internet C++'s objective was to create a new language that a) ran on a cross-platform VM, b) added new language features such as garbage collection or invariants, and c) was a free standard, unencumbered by MSFT or Sun, then they would have my blessing. However, they're simply trying to add more overhead to solve an already weighty problem. In other words, this company is about 10 years behind the curve.

(Disclaimer, I'm ex-Microsoft. I think C# is a great step forward for programming languages. I just won't start using it until it runs on my OS of choice.)

Re:It's all about the portable libraries

I think you're underplaying the performance problems of Java. I've been using some XML libraries, and was absolutely shocked by the bad performance. In this application at least, Java is at least 10-100 times slower than C++ code.

I agree with you about the Java-the-language, but the JVM is a millstone around the neck of the language that has got to go. If Java could be natively compiled, it would still be slower than C++, but at least not orders of magnitude.

--

You've Confused and Saddened Us All

Both Java and Python are much much nicer to program in than C++. This isn't flaming, but you obviously haven't done any C++ programming. I have to take a java class in college right now, and even the instructor takes every chance he gets to point out how java is inferior to C++.

Sad, how I jump at this flamebait but here goes. Your instructor is the kind of clueless academic that makes me realize that the way CS in colleges is taught seriously needs to be overhauled. Before you attempt to question my C++ creds, I will establish that I am currently using C++ to implement the server end of this project [gatech.edu]. That said, let's go over why you think Java sucks.

1. 1.)
2. Java sucks because everything is passed by reference: When you take upper level classes and concepts like the call stack are explained to you, you will realize that passing Objects around by value is expensive, inefficient and wasteful. Even in C/C++ non-primitives are usually passed by reference either via pointers or explicit references.

1. 2.)
2. Java sucks because it forces you to write code to handle potential errors in a program: This reason is so illogical it does not deserve an answer.

Second Law of Blissful Ignorance

Doom is jumpy?

If Doom is jumpy on any kind of modern system then you know that this is one inefficient port.

Re:Why not standardize the BYTECODE?

Exaclty! Why doesn't someone come up with:

a bytecode that can acommodate many languages (new and old, not just Java),

a runtime and set of libraries that can be used by any one of these supported languages,

is designed to be cross-platorm,

and then submit it to a standards body (ECMA, for example) instead of keeping it propietary (like Java, for example).

While they're at it, why not allow support for prevalent technologies such as:

XML/XSLT

SOAP/WSDL

Multi-tier web applications

hand-held devices

Doh! [microsoft.com]

Re:Why not standardize the BYTECODE?

You can buy the Java VM specification or read it for free on-line. So there is a de jure standard. As for de facto, there are over 130 languages [tu-berlin.de] that can be compiled to JVM bytecode. There's even a GCC *backend* for Java (no, not the gcj *frontend*), which seems like it would obsolete this "Internet C++" project in short order.

~wog