Slashdot Mirror
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.
Yes, you can technically compile any language to Java bytecode, but there are a few problems to deal with:
..., then the stack doesn't blow up. This is really really important for some functional languages.
* 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()
* 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.
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?
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.
Bad Java is slower than good C. Good Java is faster than bad C. In actual comparative benchmarking, 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.
I'm old enough to remember when discussions on Slashdot were well informed.
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.
I'm old enough to remember when discussions on Slashdot were well informed.
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
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
Sice most of the code is in a difficult to understand file with over 200000 lines, how can it be consdered open?
Phear my l33t homepage.
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
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
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.
Jilles
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'll see your senator, and I'll raise you two judges.
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.
--
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 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.
"Depression is merely anger without enthusiasm." - Anonymous
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.
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
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
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
... and never, ever play leapfrog with a unicorn.
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.
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
--
The more I learn about the Internet, the more amazed I am that it works at all.
Slashdot C++. It's the same language, but all the keywords are misspelled.
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.
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.
Slashdot is jumping the shark. I'm just driving the boat.
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.)
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. That said, let's go over why you think Java sucks.
Second Law of Blissful Ignorance
If Doom is jumpy on any kind of modern system then you know that this is one inefficient port.