Internet C++: Competition For Java And C Sharp? 273
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.
Re:It's all about the portable libraries (Score:1)
I hope they succeed. Java-the-language managed to clear most of the worst nasty things of C++ without taking away much power.
I share the idea that the JVM is the worst part of Java - for people not developing applets but full-blown applications, there should be the option of blowing it away and going native. In the meanwhile, I hope the JVM of 1.3 is improved.
Java libraries are OK, but too involuted sometimes ( and something basic like lists and such should become part of standard language, as in python/perl). MMI API is nice, but awt looks awful and Swing is veeery slow. Anyway, I don't like languages too much bound to one set of API - I like the choice C/perl/python gives you in terms of libraries.
VM is not Open Source and isn't planned to be (Score:2)
There are technical problems as well, but I'll leave those to others.
Bruce
Re:Initial observations on the VM design (Score:2)
Autogenerating code ... anything that transforms one language into another (e.g. Eiffel to C, TeX to PostScript, etc). Since they have so many instructions (16-bit opcodes), it is conceivable that they started with a pseudo-language that describes the operations to be performed in groups, and then generates C code from the output.
e.g. There are likely to be large numbers of "move reg to reg" type instructions. Instead of coding every one, build a macro-like language that describes how one works, and then write a translator to convert to C. Sure, C's pre-processor can do most of that, but sometimes the transformation is algorithmic rather than straight text substitution.
40,000 lines. Yes Mr Wizard, it is possible to build something as heavy duty as a VM in 40,000 lines. IF YOU PICK THE RIGHT DESIGN. In fact, I've been working on VM's myself for quite some time, so I absolutely do know what I'm talking about when it comes to VM design.
Did you ever wonder where the bytecode verifier and the GC came from in Java? Really came from. Not just what Sun says. It's due to a bug in their instruction set. You can push an integer on the stack and pop it as a pointer - instant security issue. So the verifier and GC are necessary to prevent that from being a problem.
But, here's the kicker: what if you could design an instruction set that didn't have that bug? No verifier. No GC. No type checking. No complicated reflection guff. No single-language dependencies. But still 100% secure, and less than 40,000 lines!!
Sun made a mistake, which Microsoft copied blindly. But they didn't realize it was a mistake until it was too late to fix it, so they made up various marketing reasons for why "C++ can't possibly be secure because we were too dumb to figure it out".
The Internet C++ VM is what I normally describe as "Bob's First VM" or "Graduate Student VM" - obvious opportunities for optimization being missed (switch vs dispatch functions), and code that is pretty much impossible to read.
Have a nice day, and pick on someone clueless next time, instead of someone who's actually built a VM from the ground up.
A new approach? (Score:2)
You have to write with "Multiplatform C++ style" anyway if you're using Internet C++. Nobody will be able to make the MFC available on Unix, except Wine maybe. But that's at the end the native way too.
So I think Internet C++ fails the point (nice try...).
There are many people here who states that Java (and C#) is actually a bad thing and Internet C++ was what they've been waiting for.
I'll promise you: you're skills will have no advantages in this as it has no real advantage in any C Interpretors. It is not possible to do all "dirty" and "not so dirty" things possible in C++ on all machines. Alpha, PowerPC and Intel architecture are so different in so many ways, it's not possible to hold all the good things in C++ up while to not care about the platforms you'll support at the end. So it will be not possible to keep this in Internet C++ in that way you would like to have. There is also no way for Assembler, expect you'll allow this (which would be a break in multiplatform). As we all know, systems like Linux have allways an ASM-part, which is completely machine dependent.
I'm a full time C++ programmer here and I like Java, because it tries to make the core idea of C++ and OO easy available for everyone (as most would say: Visual Basic programmers...). I can't imagine a better language for a beginner in programming. Also for prototyping, Java is for me really a cool thing to test architectural ideas.
I don't like C# because it tries to make a new proprietary language mixing up with C++, Pascal and Java, instead of just enhancing C++ with garbage collection and such good things, but still back-compatible with my C++ and C sources (as Stroustroup would do).
I'm sure the most C++ programmers will agree in this.
Cheers
Bössu
Re:good in a way, bad in a way (Score:1)
I'm a huge Java fan, but I've always felt Smalltalks 100 % OO-ness and it syntax is a good
thing.
Re:kewlest??? (Score:1)
Re:Initial observations on the VM design (Score:1)
Precisely. The full source does not appear to be available.
> Tip for VM writers: use a switch statement!
Nah. That's the slow way. Use gcc's calculated gotos. See http://www.uow.edu.au/~andrewm/cs++.html for an example.
Re:Initial observations on the VM design (Score:2)
Re:It appears .Net is proprietary "global bytecode (Score:2)
Furthermore, C# has been (or will be) submitted to ECMA.
Finally, C# doesn't have its own runtime. It uses the
Problem is, JVM is optimised for Java (Score:5)
* 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.
Re:Problem is, JVM is optimised for Java (Score:2)
Might be preemptive, but.. (Score:2)
Re:Problem is, JVM is optimised for Java (Score:2)
This is why Eiffel with multiple inheritance can be compiled to Java byte codes (yes, it has been done) but Eiffel with multiple inheritance could not be compiled to CLR bytecode (hence we have Eiffel#).
Re:honest question (Score:2)
------
I'm confused. (Score:3)
Both Java and Python are much much nicer to program in than C++. What am I missing?
RTL as bytecode standard? (Score:2)
Now, as bytecodes, RTL would probably be very slow. It seems (to my most uninformed eye) to be very low-level: appropriate for compiling, but not for interpreting. But if you can make the entire compiling process robust, there's no reason that compiling should make something less portable, as long as you are willing to replace non-conformant OS-level code with your own (standardized) code. Lo and behold, such code even exists! GNU has been writing just this distributable code for a long time.
Now, I know there must be something wrong with this. As enticing as RTL seems, there must be a reason why people, say, compile languages into C instead of directly into RTL, e.g., many Eiffel compilers, Scheme compilers, ML compilers... and it took a long time for Pascal and Fortran frontends to come about.
It is also apparent when running cygwin on Windows that while the GNU code is portable to very different environments, it leaves something to be desired. But so far the GNU code has been written with Unix in mind. A little redirection could make for code with more portability in mind.
There's a lot of work to make such a thing really happen -- but all the pieces are there, and they are more proven than Java et al. GCC is ported to a wide variety of platforms. Compiled programs run fast. RTL is, at least, somewhat language-agnostic (though I'm sure much more could be done -- all the C variants, plus Pascal and Fortran, share a lot in common).
I'm sure there's a flaw in this... but I'm not entirely sure what it is.
--
What about FORTRAN? (Score:2)
The *real* issue (Score:2)
It's likely you could reverse engineer one based on the development tools' source and output. But this is only going to work if it's ported to every OS and CPU type possible. Keeping the VM locked up will definitely hamper this.
Re:You've Confused and Saddened Us All (Score:2)
Umm, pass-by-reference can be significantly slower than pass-by-value. In ref's, you put into the calling function's argument registers a pointer, which must then be dereferenced. Ideally, the contents are in L1-cache, but if you haven't used them in a while, they may be off in slower memory. Today, when memory is an order of magnitude slower than the CPU, that makes a significant difference. IF, the c-struct can fit within the argument registers (as might be the case in SPARC, IA-64 architectures for small-to-medium DTs), then you can make several calls deep without ever touching memory (so long as you don't use any pointers). Now, admitedly, x86 and many other's have a register shortage, so this probably doesn't apply to them (except that the contents would have been garunteed to be recently accessed, and therefore could be in an L0 cache (such as in the Athalon; at least, I assume this is what L0 is useful for)).
As an interesting point (I'd like to learn more on it), how does C++ do the following:
void foo( int& arg );
If it's nothing more than a transparent pointer, then C++ definately has less performance capability than C. If, however, it's a true alias, and you are passing-by-value, then architectures like the SPARC, Athalon, and IA-64 get a double bonus, since their calling parameter is the same as the returning one (thereby saving several regs).
That said, interpreted languages such as Java, scheme, Perl, etc require expensive operations to be performed for each op-code (or segment of text), so most of the point is mute. Especially since their data-structures contain a lot more bloat than just the desired value. (Note: I use the term interpreter because these languages do not compile directly to assembly. Their meta-data must be interpreted to determine code-flow. If you give me a better substitute for a word then fine, but you can NOT call perl or Java any more compiled than scheme; The compilation stage is simply more explicit and optimal).
It might be possible, however, for the interpreter to pass-by-value the low-level data-structure to the internal control-flow function, say as in ADD(DS& TO, DS& L, DS& R). With this, the intermediate operations which require internal-function calls could be optimized away. It's more complicated to analyze Java, especially with the JIT, but similar sorts of optimizations utilizing passing raw-values instead of just the pointers could be implemented.
The problem is that a function call has so much over-head in an interpreted language, that little of this matters.
Lastly, to the real point that the first guy was making. He doesn't like having to _use_ references. Well, in Java, you never know that they're references (except when you try and copy something). I rarely actually do a copy, so I can't imagine what his problem with it is. In C, you have the distinction between access and dereference, in Java, they both "look" like access, namely Foo.var, as opposed to Foo->var. Personally, I prefer the uniform access types (fewer errors). As for the lack-of-safety for modifying called parameters, you at least have low-level types in Java to avoid this. Beyond that, any really large data-structure is almost always passed as a pointer in C, so I can't imagine there's a debate here. Perhaps I'm being naive in comparing Java to C. Is there something that gets the job done better than Java or C/C++? Perhaps you might advocate Perl, which can do either references OR static-types (but no pointers). I can't imagine writing Word in Perl though; there's just too much over-head for a large-scale app, unless perhaps you were only trying to connect together GNOME/Qt components with Perl glue, but you'd still have written most of the components in other languages (like Java / C).
-Michael
Do you have any idea what you are talking about? (Score:3)
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:Not really open (Score:2)
Just because something is too hard for you to understand, doesn't mean it isn't open. Some things are intrinsically hard. Some things are badly written but open; provided they're open, we can study them and rewrite them better.
Open Source is not the same as Dumbed Down Source; if you want to take part, you may have to work.
Re:It's all about the portable libraries (Score:3)
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.
RTL + JIT? (was Re:RTL as bytecode standard?) (Score:2)
Actually, if combined with 'Just In Time' native code compilers, or Transmeta-like code-morphers, this sounds like an exceedingly good idea. Furthermore, the native-compilation elements of those JITs and morphers already exist for a wide range of processors, because they're part of GCC. So all that's actually needed (if it doesn't currently exist) is an RTL virtual machine and code-profiler. That way you could have a long step towards 'compile once in any language and run anywhere' fairly cheaply.
It has to be recognised, though, that part of 'run anywhere' (and part that Java has actually provided fairly well) is universally available libraries. For this to really fly you'd need something equivalent to the Abstract Window Toolkit (the Java UI toolkit which maps UI requests to functions of the native GUI of the OS it's running under, not Swing which invents a whole new GUI different from every other).
Re:This is great... (Score:2)
You have been reading different interviews than I. He's one of the biggest C++ nitpickers out there (makes sense... he knows it best). His biggest gripes are that they rolled out with incomplete templates definitions and standard libraries. He can easily name a dozen more problems in light interviews.
Generally, however, he does justify each decision, even if the explation is just "It Seemed Like a Good Idea at the Time" or "We Didn't Have Time to Do Better".
One thing he dislikes is how C++ handles strings... CUJ, DDJ or some other print magazine ran an entire article about it, including some nice hindsight ideas.
--
Evan
Re:It's all about the portable libraries (Score:2)
Xerces is what I'm playing with, using Sun's Forte under Linux. Parsing an 4K XML file (with empty SAX callbacks) took 117ms on my P/II 266 machine. Does anyone here think they couldn't write an XML parser that would parse a 4K file in under 5ms in C++? Or perhaps even 1ms?
I don't even think I could write a C++ program that took 117ms.
Incidently, that 117ms was after executing the parser once to make sure everything was loaded (the first time took about 1.5sec!!!)
--
Re:Why not standardize the BYTECODE? (Score:2)
That's a great idea!! All you have to do provide libraries higher up - those common and compatible with gcc, at least for a platform. You could have what-ever optimizations you want for all the sorts of complex tasks that a given language wants to use, like reg-ex, GUI's.. Each could be in their own libraries (since they're called differently).
Oh wait.. We already have that.. It's called assembly.
-Michael
Re:Why not standardize the BYTECODE? (Score:2)
1) Different languages make different assumptions. These range from calling methods to memory management, to threadibility, to the dynamic nature of the code (self-modifying code). It would be difficult to write a catch-all sub-system for any appretiable number of languages.
Now MS managed to use a JIT to translate both java and C# into the same byte-code, but they had the benifit of designing the second language to be compatible.
2) Dynamic languages are hard to compile into assembly. The most you can do is compile the main event loop with a static list of byte-codes.
3) You do NOT want to do anything that would make C slower. Namely, you're not going to use a generic interpreter that reads byte-codes, and based on the language context, treats them differently (i.e. reads the C-derived assembly, and interpret it). You're also not going to translate C-derived
So, essentially we can't have executable code that is common to all egcs-parsable languages. What you might be able to do is unify a couple high-level varients like Java, C# and Internet C++, which to me, on the outside, seem identical in nature. This wouldn't really work for Python / Perl / Scheme. They still need full-blown interpreters because their code changes over time (through the use of "eval"). But maybe we'll be biggots and say that they don't deserve coverage in this universal optimizer.
But here's what you get out of this. You have 3 or more languages that use the exact same byte-code underneath. They all have their plusses and minuses, but you have complete interpolability. But this "family" of languages is distinguished from raw C / C++ and purely open sourced Perl / Python / Scheme
My point is that you haven't solved the programming crisis, you've simply identified families of similar architecture and unified them.
-Michael
ECMA is a standards body. (Score:2)
STL is not an abomination (Score:2)
The STL is one of the more elegant and useful collection libraries I've seen in years. It makes the Java collections look amaturish.
One of the real weaknesses of Java currently is its lack of support for generic programming. (Another is the fact that while Swing is nice and portable, it's slow.)
Let go of the C myths (Score:3)
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.
Why RTL can't be a bytecode standard (Score:2)
Re:Problem is, JVM is optimised for Java (Score:2)
Hehe.. Perl Plug.. Perl has a special varient of "goto", which does just this.
I think what you're talking about are optimizations. I think you are assuming that the meta-byte-code would be Java-family-centric. IF this crazy scheme could work (and I don't think it could, but for other reasons), then you could perform translations at compile time. We obviously know that we can write OOP on top of FOP (that's how C++ originally came about, and it's how GTK+ works). But it's just as easy to write FOP on top of OOP, since you just implicitly pass the "this" pointer around.
The problem would, of course, be performance. It would be better performance if we assumed an FOP model then did something like GTK+ for all OOP implementations.. In this fashion, you get all the benifits of code-robustness inherent in OOP, but get the performance and compatibility of FOP.
What I would instead advocate (and I forgot to include it in another post), is that we might find some common intermediate ".o" language. You'd have egcs be a front end for all your langauges, then save them off in what-ever form you want in
Unfortunately, that's a lot of work to accomplish very little. Essentially you're able to have a directory tree of
-Michael
Re:good in a way, bad in a way (Score:2)
Very high level languages have their places. But until computers are many times faster then they are now we will need low level languages. Todays machines are *very* fast compared to the machines of only a few years ago but their are still things that are to processor intensive to do in high level languages.
Because the newest and highest tech software always pushes the limits of what a computer can do people will continue to use low level languages to do those types of programs in.
BTW I do realise that C is/was considered a high level langauge but compared to most languages in use today it is very low level.
So if all you ever want to do is to make a few applets or a text editor the use java, but if you ever want to do something like virtual reality, or program for a 3d display were instead of dealing with 1024X860 pixels in 32 bits of color your dealing with 1024X1024X1024 voxels in 32 bits of color, you'll need C/C++. (now that was a run on sentence.;) )
Write once Run Anywhere ... (Score:2)
Being interested in C++ programming myself I decided to see if maybe I couldn't compile a binary using Cygwin ... I was wrong :-)
So anyone else interested in maybe helping to make a port of this "universal" language for say ... windows/mac/be/qnx(haven't tried compiling under qnx yet) ???
A 13 MB source file? (Score:2)
$ ls -l
total 15758
...
-rw-r--r-- 1 rlk bin 1835540 Sep 22 08:31 icvmjunk.h
...
-rw-r--r-- 1 rlk bin 13958826 Sep 23 21:42 icvmsup.c
...
There are about 25 files total. What's more, that big
*gasp* a NEW language? (Score:5)
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
Re:Why not standardize the BYTECODE? (Score:2)
Not really open (Score:3)
Re:Is anyone or any business really gonna back C# (Score:2)
Well, why do businesses take to VB? Because a lot of what they need to do is to bolt together pieces of logic.
Nobody gives a shit about C# as a language. It's the virtual machine that it runs on that is important. There is a shortage of capable programmers, and believe it or not the clueless code grinders businesses have to use still can't get their brains around using COM. MS is targeting the right problem in its usual half-assed way.
Re:I'm confused. (Score:2)
What I like about Java and where I hope it goes. (Score:3)
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:Why not standardize the BYTECODE? (Score:2)
Yup, this is coming soon. (Score:2)
Re:Speed Question? (Score:3)
Dynamic compilation is the future, now we just need a good portable, free, open, bytecode spec to which we can conform.
Mozart's VM is What's Needed (Score:2)
Ultra light weight threads are one of the major advantages of the MVM, but another advantage is how well thought out and integrated with the other language features is it's thread synchronization scheme.
Re:It's all about the portable libraries (Score:2)
The reason I like C++ more than Java is very simple. There are a lot of annoying (and wonderful) features in C++ and if I don't want to use them I don't have to.
An optional garbage collection type modifier would be a great thing to have for very isolated situations where for some unknown reason, you can't keep track of your own dynamic memory usage. Garbage collection is not a cheap operation and can lead to nasty performance and memory overhead in certain types of applications. Forcing it upon the programmer is wrong.
An optional thread locking type modifier would be the ultimate godsend so one could not have to worry about sticking mutexes all over the place in applications that contain large amounts of shared data.
And finally, an optional compiler flag which asked it to print out warnings when there are exceptions that haven't been caught.
The reason C++ is the most popular language is simple, it allows the programmer to work with the features they are comfortable with in a flexible manner. You can work with with straight assembly, straight C, or use any combination of the features C++ gives you. Granted, having backwards compatibility with the massive amount of C code out there probably had just as much to do with it, but...
Of course, that's just my opinion, I could be wrong.
Language Bloat (Score:2)
It's all about the portable libraries (Score:5)
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 (Score:3)
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.
--
Security? (Score:2)
Re:It's all about the portable libraries (Score:2)
A GUI interface should not be a part of a programming language, any more than a GUI shell should be a part of an operating system. That's what libraries are for. Should there be GUI standards? Of course! But that's not the point. The machines themselves don't have standard GUIs, so why should a their translators have them?
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.
'Tis true! If your only concern is portability, then Java (or C console) is the way to go. But there are other concerns for other people.
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.
The STL is hardly an abomination. Perhaps you haven't grokked it yet. It is a completely different paradigm than functional or object oriented programming. It's *generic* programming instead. But even if you stick to the tried and true OO paradigm, the STL is till simple, robust and fast.
It has everything else going for it. Type safe. No unhecked runtime errors. RTTI. Garbage collection.
RTTI should not be counted as a major benefit. In all languages that have it, including Java, it's a hack to get around encapsulation. There are sometimes instances where you need it, but always keep it in the bottom of your toolbox under lock and key.
Re:You know.... (Score:2)
Uh.... You're joking, right?
Re:Might be preemptive, but.. (Score:2)
Browsers don't do GUI? What's with all the buttons and rollover effects and stuff then? This is all just text? Even the text is more interactive than standard text, it's so advanced they call it "Hyper-Text". You can point at it and click on it! This is far more than normal text handling. In fact, I'd say that most word processors have begun to add features along this concept of linking within a document because of how much everyone likes it in their browsers.
So instead of carping about the inadequacies of browsers, which in this case would be redundant on top of an X server (you need to run X to run a browser, so why not build the app to run as an X client directly). Or furthermore cursing the usefulness of X on the vaguely requirement defined "thin client" (you are really in danger of starting some sort of client anorexia here, the average client has a fast chip, plenty of memory, and a decent HD these days-- if my local library, businesses, etc are any indication). Why don't you offer some insightful suggestions as to alternatives, and relate that back to the discussion of Internet C++ (which sounds like a good buzzword to attract VC in the wake of C Sharp).
Re:Is anyone or any business really gonna back C# (Score:2)
Hmmm. I would bet that people have said the same about Visual Basic. Now, don't get me wrong, I dislike VB, but you certanly cannot call it a failure, wait... Its proprietary isn't it?
This is great... (Score:3)
Re:Initial observations on the VM design (Score:3)
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:You've Confused and Saddened Us All (Score:2)
The value of an object is an object reference, so that's what's passed when you pass objects. You can modify the object contents, but you can not modify the object reference because it is passed by value.
Saying C++ is better than Java because your beginning java instructor in college said so is downright silly. Most people I've met, with a few exceptions, teaching java in college barely have a grasp of the language themselves.
I've been programming professionally for four years, and java for about 2.5 of that. I've learned way more in the industry than I ever did in college.
To keep learning, I try to surround myself with people who've been doing it for a lot longer than I have (like around 20 years). Since I'm not a C++ guy I have to rely on them for information about the elegance of languages I have not used. These are the common opinions I hear:
Speaking strictly as a language, most I've talked to that have done both seem to like Java better than C++. C++ is powerful but leaves a lot of room for error. Java is powerful, removes some room for error, and at least tries to enforce OO style, and seems to implement some OO language features a little cleaner than C++ does.
Two other languages that people seemed to like were Smalltalk and Eiffel. Many seemd to like Eiffel better than java, and looking at it I aggree it has a lot of features I wish java had.
For the gentlement that was listing java deficiencies, I have a couple comments:
Lack of parameterized types:
Nice to have but can live without. Maybe in java 1.4.
Lack of assertions:
There are probably a bazillion assertion libraries for java, and how hard is it to write your own? Assertions are simple things and you can write a decent assertion library in about an hour or two.
Re:Language Bloat (Score:3)
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? (Score:5)
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
We did something like this in '96 with Omniware (Score:2)
Omniware was a RISC-like VM, with 16 registers and a instruction set that would not surprise anyone familiar with the MIPS or Alpha. We used a gcc backend to generate this code, and guaranteed against misbehaviour in network-downloaded code by inserting bounds-checking for loads and stores in our VM. We would translate from the VM into native code, doing it on the fly. Translation time was trivial - the translation process was pretty much a 1:1 thing, without complicated optimizations. Our code ran well within the 20% of native code; 10-20% overheads were typical (not counting translation time, of course :-) ).
The protection model was pretty simplistic - we could essentially build our own paging model (read permission, read/write permission) in software, but it was nowhere near as sophisticated as the mechanisms that Java uses to ensure good behaviour in unsafe code.
The project never went anywhere; Lucco & Wahbe formed a start-up (Colusa) which was acquired by Microsoft. Microsoft presumably bought the company as a hedge against Java and for the (ick) software patents that Colusa holds in this area (chiefly relating to the software-inserted-checking page protection model). I wouldn't be suprised to hear that C# has some common ground with Omniware.
The most important lesson, IMO, that Omniware held was that it's quite possible, and maybe even desirable, to do heavy optimization (global and interprocedural) on a low-level intermediate representation. This gets most of the possible optimization done _before_ you start shipping code around the net.
Of course, your optimizations are limited by the virtual machine - a 16-register machine results in register use that is profligate by x86 standards (we had a simple reallocator, very fast) and parsimonious by RISC standards.
Java takes quite a different tack. Java's IR is comparatively high-level. Thus, if you want to heavily optimize Java code, you have to do it everywhere, on each VM. This is despite the fact that there will be much in common with the optmization process across many of these different machine types - even between the RISC and x86 families. Of course, Java was solving a quite different set of problems.
Of course, it's all hogwash. We need to ship random snippets of untrusted code around the net the same way that we need an icepick in the head. What can I say? It was 1995, and we'd all drunk the "mobile code Kool-aid".
Re:Java's problems are not limited to performance (Score:2)
Nooooooo!!!! (Score:2)
Extending its reach into the internet will just make it into another COBAL. (A language that lives on through the inertia of its existing code-base volume.)
This may just mean that better languages like Java will grow at a slower pace than they might otherwise.
Re:Java's problems are not limited to performance (Score:4)
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
--
Don't forget this important one (Score:3)
Re:I'm confused. (Score:3)
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.
it's C/C++ that makes it hard (Score:2)
For example, in C/C++, a string can be a "char *", but that might also be a pointer to a local variable of type "char", or a single heap-allocated byte, or a pointer into the middle of a heap-allocated struct, etc. Other languages have the same concepts, but they use separate types. C/C++'s design choice is simple, but it inherently makes many kinds of runtime checks very expensive, and it makes it nearly impossible to automate the type conversions that occur in multi-language environments. Either the programmers has to write an IDL specification that really expresses what the code intends, or the runtime has to keep track of a lot of extra information.
Until C/C++ changes and deprecates its "pointer" construct in favor of a variety of other constructs (similar to what happened with casts in C++), an efficient universal runtime for both C/C++ and other languages is always going to be a big project.
If C/C++ isn't one of the target languages, a universal runtime is pretty straightforward. You could easily do a nice, universal runtime for Java, Modula-3, Prolog, Lisp, and many other languages.
STL has seriously damaged C++ (Score:2)
If you look at what most C++ frameworks and applications actually use, it's very little: some kind of array/list, maybe a multidimensional array, and a hash table. That is what C++ should have provided in its standard library.
If people had wanted something of the complexity and generality of STL, they could always have gotten it as an add-on (or, better yet, used a language in which STL-like frameworks are much simpler, like SML or GJ).
STL is out of any proportion to the needs of most C++ programmers. Its adoption has delayed the acceptance of standard collection classes for C++ by many years, because compilers needed to catch up with it and because people needed to learn it. That has done untold damage to the language in the market.
And despite its complexity, STL still fails to satisfy the basic needs of many applications, meaning that most application frameworks still include a number of incompatible collection classes.
By any measure, I think STL failed: it didn't help the adoption of C++, it didn't standardize existing practice, and it doesn't satisfy the basic needs of working C++ programmers.
Re:I'm confused. (Score:2)
Care to guess how many lines of code have been written in COBOL? Various machine languages?
The Cross-Platform Manifesto (Score:2)
Re:I'm confused. (Score:3)
Re:So I'm a "clueless academic", am I? (Score:2)
You are an idiot, masquerading as a programmer. If you wish to flame a clueless academic, you should at least make sure you have the wit to do so intelligently.
The const problem is a real problem. I like to be able to say that the method I'm passing an object to promises not to modify the contents of that object. Your mention of 'static' is totally irrelevant in this context. And the author clearly understands 'final' which is why he says there's no real analog to C++s 'const' methods.
Your 'finalize' method example provides absolutely no guarantee about when it will be called. You may run out of file descriptors, or whatever other resource you're using before the GC is run. The GC only deals with memory, so it won't run when you run out of file decsriptors to save you from stupid, needless errors when you open files.
The real answer to his 'no destructor' argument is the 'finally' clause of a try ... catch block, which is just as bad as having to remember to 'delete' things in C++.
As for the reference vs. value semantics of objects vs. primitive types, Java obscures the issue. It's easily as bad as the fuzzy distinction between arrays and pointers in C.
C++ container classes that contain by value do a good job of making it a bit of a pain (and sometimes impossible) to get a pointer to the value they're actually holding. Java, cannot make this a pain.
I personally, would shoot anybody who used 'instanceof' in an OO program in a statically typed language. That just screams 'bad design'. Templates are a far better means of achieving genericity than run-time type checked casting.
Re:So I'm a "clueless academic", am I? (Score:2)
While I agree that the interface idea is an excellent idea, I found, on occasion, that I want mixin interfaces that actually have code and data behind them.
In particular, I have a reference counting class that has a reference count in it. Several classes I have multiply inherit from the reference counting class, and a different data containing class, and this works out well.
This couldn't be done in Java. Of course, Java wouldn't need a reference counting class, but the principle is the same.
good in a way, bad in a way (Score:2)
I'd like to see some innovation in actual language design sometime - Python and Haskell are a good start.
-lx
Re:Java's problems are not limited to performance (Score:2)
And finally... When not doing Python, I'm a C programmer, mmm-ker? Much of the C I've worked on in the last year (except fixing stupid build issues and the like) has been kernel code. I'm no COBOL monkey, and much more than a UNIX admin only.
Re:Why not standardize the BYTECODE? (Score:2)
From a
The problem with this is that you might lose the features you wanted to use of a particular language in the first place. As an example, why would I want to use Eiffel instead of C#. Lets say because Eiffel allows multiple inheritance and C# doesn't. But the Eiffel compiler for
The feeling we got from the presentation was that we'd be better of using C# only as you would not gain much, if anything at all, by using other languages in
Vivek Mittal
Research Technologist
Telstra Research Labs
Re:Write once Run Anywhere ... (Score:2)
Re:I just got back from OOPSLA (Score:3)
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:
Re:Mac OS X (Score:2)
Second, this means Mac OS X supports development in C, C++, Objective C, Java, and soon Internet C++, while C# might be ported just to keep the antitrust types at bay. That's a lot of C, especially for an OS whose headers still feature the pascal keyword in places. Mmmm, irony.
Re:God save us. (Score:2)
Heheh... If they just wrote a backend to gcc, then doesn't this stuff have to be GPL? That's one of the big reasons I rejected such an approach... that, and the fact that if I ever wanted to distribute a Windows plugin for IE, I'd have to put up gcc for download (The vrml3d.com C-virtual machine is really cool, just sit through this 20 meg download and you'll see...)
OK, maybe now I'll get off my butt and splice my "security" hack together with the OpenGL module for EiC and build it into a Netscape/IE plugin for Windows. Anybody wanna wager I can pull it off in less than a week?
The only trouble would probably be the OpenGL module, since I've never fussed with it, and it might actually be a Mesa module, in which case it probably isn't Windows friendly. Other than that, this shouldn't be rocket science.
Initial observations on the VM design (Score:4)
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. (Score:5)
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? (Score:3)
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.)
Where is the mindshare supposed to come from? (Score:2)
It seems to me from reading the page that their major claim to fame is that they are Open Source and as all those who have watched GNU Hurd [mit.edu] development goes, being Open Source does not automatically imply mindshare.
PS: What the heck do they mean by the New Internet [xmission.com]? Sounds like a rehash of every major Sun, MSFT, etc launch of the past few months/years.
Second Law of Blissful Ignorance
Re:It's all about the portable libraries (Score:3)
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.
--
Re:This is great... (Score:2)
Maybe the authors should have Bjarne Stroustrup take a gander...
Bjarne has already gone on record as thinking he doesn't think C++ has any (significant) problems. I don't think he's looking for a "better" language.
--
Re:Is anyone or any business really gonna back C# (Score:2)
After developing my latest little project in Java, and having it run without recompilation on Linux and Windows, i'm sold.
As it stands, Swing is the worst thing about Java today, but hopefully we'll get a fast native GUI from Sun at some point in the future.
Anyone know of there is some kind of JNI interface for GTK+?
I quite like programming for the AWT, it's not too slow, but it does take some work to implement the groovy stuff like transparency and arbitarily rotated text and things.
If i wanted a language purely for its OO features, i'd use Smalltalk, Objective-C or Python perhaps.
C# is a waste of time.. If MS had concentrated on improving Java performance instead of getting all pissed off they couldn't use it as a tool to tie users to their licensing fees, we might have a high-performance Java today. Now theyre reinventing the wheel, yet again.
The most ridiculous aspect of the whole thing is their claim you can write C# code in any language you like, except the one that's semantically and conceptually closest - Java.
Is there actually a good technical reason for not supporting Java syntax with C#?
You've Confused and Saddened Us All (Score:5)
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.
Second Law of Blissful Ignorance
Re: UpDATE (Score:2)
iaddr2line.exe
iar.exe
ias.exe
ic++filt.exe
igasp.exe
ild.exe
inm.exe
iobjcopy.exe
iobjcopy.exe
iranlib.exe
isize.exe
istrings.exe
istrip.exe
anyone wanna help me out and tell me what else I need or if I'm even going in the right direction ... BTW still no luck getting the VM to compile.
Scrubbed C, EiC, etc... (Score:2)
I had the same idea [vrml3d.com] quite some time ago.
I've worked a little with EiC [kd-dev.com] which is an Open Source (Artistic license) package that allows you to run C programs as scripts on many platforms (but it does not have a portable binary VM format).
I have also written a VM of my own, and a parser for C99, but they are not releasable quality yet. If I ever do release it, it'll be either BSD or artistic.
I'm not really plowing a great deal of effort into this, because in order to gain wide acceptance, it would have to be free, and well... there's that pesky money issue.
When I saw this, my jaw dropped... but there is no Windows or Mac version. If they come out with a Windows version, this may be the one I've been waiting for. It would be so nice to see Java just curl up and die. It was a bad idea right from the start. I don't care if this guy releases his stuff as Open Source or not. Simply by putting a C/C++ VM on my box, and having my C/C++ skills be important for both stand-alone *and* internet applications, he would be doing a great service.
Doom is jumpy? (Score:3)
Re:Why not standardize the BYTECODE? (Score:2)
Re:Why not standardize the BYTECODE? (Score:4)
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:Cross Platform C++ libraries (Score:2)
The ADAPTIVE Communication Environment (ACE(TM)) [wustl.edu]
It provides abstractions for mutexes, threading models, standard libraries, etc. It's not perfect, but it works pretty well. And it's free, open source, and cross-platform. Does this fit your bill?
- Spryguy
Going the wrong way (Score:2)
As a developer of software in which execution speed it absolutely crucial, "Compile once, run anywhere" doesn't mean a damn thing to me if it runs slow. "Compile n times, run on n platforms" is what I *really* want. If we only had decent NATIVE code Java compilers for every platform upon which Java runs, I'd be happy.
--Mnem
Java's problems are not limited to performance (Score:2)
While I prefer perl's compact syntax, I think for most people Python offers a useful comprimise.
Writing code in Java is only going to get you RSI.
Re:Don't forget this important one (Score:2)
Re:I just got back from OOPSLA (Score:2)
It appears .Net is proprietary "global bytecode" (Score:2)
Re:Why not standardize the BYTECODE? (Score:3)
~wog
This is great. (Score:2)
This is so cool. Code that fulfills the promise of write once/core everywhere.