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.
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.
Ciao
----
FB
There are technical problems as well, but I'll leave those to others.
Bruce
Bruce Perens.
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.
I think Internet C++ is as useful as GCC is, with the difference, that the compiled code is NOT native. So what's the advantage then?
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
Smalltalk!
I'm a huge Java fan, but I've always felt Smalltalks 100 % OO-ness and it syntax is a good
thing.
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
I woundn't get ratty about spelling when you use 'there' in place of 'their'.
> It looks like some of it may have been auto-generated
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.
Hmmm - on second thoughts - maybe you weren't being sarcastic. Apologies if so. Need more caffeine to jump-start the brain.
thought of EVERYTHING being passed by reference Primitive types are passed by value.
I don't think the guy was being sarcastic. He sounded pretty sincere to me. But I can't be sure...
The only reason all cover-ups appear to fail is that you never hear about the ones that succeed.
I never thought that I would say this, but the speed of Java is nowadays just fine. Especially IBM JDK 1.3 for Linux is _really_ fast. I know that this is not a meaningful benchmark, but here is one thing I tried:
class Test {
public static void main(String[] args) {
long t=System.currentTimeMillis();
int j=0;
for(int i=0;i100000000;i++)
j+=i;
t=System.currentTimeMillis()-t;
System.out.println(t+" "+j);
}
}
Runs in 610ms on my AMD K6-2 350 with 196MB with the IBM JRE 1.3 for Linux.
#include
void main() {
long int t=clock();
for(int i=0;i100000000;i++)
j+=i;
t=clock()-t;
printf("%d %d\n",(int)t,j);
}
This runs in 601ms when compiled with gcc -O2 on the same machine.
So the performance for calculation stuff is just as good as C++. Even the instanceof operator is really fast. But there definitely are some performance problems with Java.
There needs to be some way to have by-value classes to efficiently implement things like complex numbers and vectors.
The swing GUI is painfully slow. People just do not accept a GUI where they can actually see things being drawn on top of each other.
So instead of inventing new VM Languages, somebody should fix the (few) problems with java. Unfortunately, only Sun is in a position to do so.
Just my 0.02 Euro, Mr.Wrong
It's not vapour. It exists, it runs, and people are developing for it, today.
.NET runtime, just like the other .NET products.
Furthermore, C# has been (or will be) submitted to ECMA.
Finally, C# doesn't have its own runtime. It uses the
My opinions are my own, and do not necessarily represent those of my employer.
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.
To me that means with Java I'm able to create energy out of nothing. An input of 100% gets me an output of 150% ? Now that's really a good one.
Oh, and an X display? Bah. If you're looking for remote displays choose something designed for thin clients.
Bah humbug!
--Giving to trolls for the benefit of us all
IBM apparently have a source to native, or bytecode to native compiler, that is now part of the VisualAge for Java dobury. I don't know much about it there is a reference here on alphaworks. Goto "Technologies" -> "Java" -> "High Performance Compiler for Java".
Well the JVM obviously is such a beast. In fact, aside from support for any language, you are almost describing Java. Granted, compiling a pointer based language to Java bytecode is a non-trivial problem, but it should be possible. I read here that the Microsoft.NET platform aims to be exactly what you describe, with a bytecode that is coupled to C#, but is designed to be easy to target from other languages. With those two VM's, another would be redundant, even if it did have a cleaner and more portable design. In the end, I don't think any standardization efforts will be tremendously successful. If the whole world could agree on what bytecode was best, we wouldn't have to target different architectures for processors, either.
If you are modding me down because you disagree with me, use the "Flamebait" category, not the "Troll" one.
Even though Eiffel is not widely used, there are important principles that can be learned from it. Learning Eiffel is not a waste of time.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
He who writes the code should decide what to with errors, and where.
"C is the language that believes that the programmer knows what he wants and deserves to get it, good and hard."
-- H.L. Menken, paraphrased
"The Greens lynched a hacker in Chicago. Last month, but I think the body's still hanging from the old Water Tower."
Surely that's one of the reasons why it could succeed?
You UNIX bastards think you have won,
But VMS and ASS400 still make bill-ions
I don't like C/C++ as a language too, just that, when you have to know these to make a living today (and probably the next 5 years too), you don't have a choice.
I am completely for the idea of writing everything in a nice scripting language (my current favorite: Ruby, previously covered by Slashdot, with the exception for the OS, drivers, and games.
Back to Ruby: it has evolved to version 1.6.2, and has basically ALL characteristics of a nice programming language that I want. Some of them are:
try {... try {... } except {... } } finally {... }
WHY are there 2 block levels when you really need only 1? Ruby is beautiful in this aspect: begin
Check it out.
I second that. IMO, STL is one of the best libraries I've ever seen. It is a wonderful example of what Java can't do, and C++ can.
------
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?
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.
--
All I know is in there "Vision for the new internet" they used the pronoun "kewlest" and that can't ever be good.
-K www.wackyboy.com
Actually there was a day a few weeks ago when they stayed the same.
Pete
Hogswash! One of my main dislikes about C and C++ was that header files could float around like dead fish at the top of a pond. Which contains what function prototypes and what definitions? Theres only so much a filename can tell you, and if you've got a large project you have to search for ages to find the right info. Javadoc does this all for you, you know exactly what a class does and why it does it.
.
As for using multiple inheritance, read this and see why its not a good idea before you slag something off you dont understand.
~matt~
0
o
><>
"So there he is, risen from the dead. Like that fella, E. T." - Father Ted Crilly
In the latest IEEE Computer (Oct 2000) there is a comprehensive article comparing C, C++, Java, Perl, Python, Rexx and TCL. The results are different than in the link that you provide.
The abstract for the article can be found here. You need to be a member to get the whole article.
Anyway, the findings that could be of interest here are "...the C and C++ programs run only about twice as fast as Java. The script programs tend to be faster than the Java programs." and "The typical script program consumes about twice as much memory as does a C or C++ program. Java programs consume three to four times as much memory as C or C++ programs."The only issue I have with the research is that only one OS platform was used, a Sun Ultra II. I would like to see the executions performed on a few more systems, at least a Linux/BSD system and a Windows Box. While this might not affect the non-Java languages much, Java is heavily influenced by the JVM in use. It is wide known that (other than the IBM JVM on linux) the windows JVMs tend to be the fastest available.
OTOH, the testing approach looks good and more work should be done to validate and extend the research. The Internet C++ guys should use the same tools to get a good performance comparison.
gwonkAll this talk about languages that matter and no mention of FORTRAN. Maybe it's FORTRAN that needs a facelift; and given that there a lot of investment in FORTRAN code in the scientific community we could as well have Internet FORTRAN --- Just for the record
"Fighting terrorists with millitary might is like killing a mosquitor on your Dad's forehead with a rifle."
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.
Shut up and eat your vegetables!!!
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
-Michael
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.
Interesting concept. I noticed that when you have seveal Java apps running, even big machines start bending under the weight of several JVM.
Anyway, I'd really like to skip the WM for apps I don't need to have portable binaries.
As for the libraries - what sort of list are you talking about? The Java Collections framework (standard in 1.2 and above, availiable as library for 1.1.x) provides most of the collections you'd need.
Yes, and I use most of them quite often. But IMO they imposes a quite lengthy notation stile, which could be shortened without loosing elegance if the language itself supported high-leve data structures (not as libraries,albeit standard ones). If you'd look at lists or ash in Perl, or at lists/tuples/dictionaries in python, you would know what I mean : same functions, but with a more compact notation style.
there are other GUI toolkits (like bonobo(sp?)
The only bonobo I know of is the component-model being developed with gnome ... there are others?
another poster said that you can get a lot of the benefits of generic programming through use of interfaces
That was me (I talked a lot today ;-). Nice that we agree on something (more that that actually : I like Java - mostly the language itself, but I'm also comfortable with the libraries ).
Ciao
----
FB
Doom is jumpy? (Score:3, Funny)
> If Doom is jumpy on any kind of modern system then you know that this is one inefficient port.
I'd say that sounded pretty serious to me...
And, I forgot.
While basically everybody else's Exception handling is a last resort. There's something from BASIC a language can learn from:
ON ERROR GOTO Haha... --- trap an exception
Haha:
RESUME NEXT --- GIMME this construct!
With Ruby, you can do that too.
Why dont we just all agree on one computer platform to use? If we all had the same computer, all this talk wouldnt be necessary at all.
:)
.
Lets all throw away macs, pcs and sparcs and do all our coding on a commodore 64
ahh.. I miss the old days..
~matt~
0
o
><>
"So there he is, risen from the dead. Like that fella, E. T." - Father Ted Crilly
Erm, C, C++, different languages. Hahaha!!!
If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
Why dont we just all agree on one computer platform to use? If we all had the same computer, all this talk wouldnt be necessary at all.
:)
.
Lets all throw away macs, pcs and sparcs and do all our coding on a commodore 64
ahh.. I miss the old days..
~matt~
0
o
><>
"So there he is, risen from the dead. Like that fella, E. T." - Father Ted Crilly
Well... that's why emacs has the handy little alt-/ completion. To do the typing for you
Of course, I did work with one guy who did all his Java typing in Python. Very fast, productive and low-bug guy.
I suspect you have an out of date idea of the C++ language. Java has nothing to match the power of C++ templates (generic programming). It doesn't even allow the definition of new type names, as even C does.
....funny?
- Spryguy
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
It's possible in theory since the Just-In-Time (JIT) can do optimizations at run-time when it can have useful information available that simply isn't there when static compilation is used.
It's much more feasible to predict the paths of execution at runtime than at (static) compile time.
I am running WinNT 4.0 on a PII 366 Mobile processor (work machine) with 224MB and it simply flies. Just be sure and give it *lots* of memory and Java is perfectly happy. :)
BTW: I am using Xalan & Xerces for XML processing and the speed seems really good under Java.
Later...
KangarooBox - We make IT simple!
Of course, at this point, it won't do much for you. As a proof that it can do more than LX, Mozart contains a Java to Java translator that can serve as a pretty-printer and be used to implement all sorts of Java extensions. LX parses and does some basic semantics analysis, but nothing very serious yet.
Getting rid of the C legacy enables tons of things. Such as optimizing on modern processors :-)
-- Did you try Tao3D? http://tao3d.sourceforge.net
The other one being Perl
Memory leaks ARE a problem, even in properly designed software. Loads of library calls return pointers to memory areas that is YOUR responsibility.
Yes, if you are irresponsible, the memory leaks are a problem.
Of cource C++ is much more powerful than Java, but so is perl when processing large textfiles. It's all about choosing the right tool for the job.
You miss the point. The C/C++ are the most powerful languages because you can control everything. No run-time checks ala Basic get in your way, no auto-zeroing of newly created variables, etc. You are responsible, you get the speed. Do you know what language was used to write Java or Perl? It was neither Pascal nor assembly nor Java. It was written in that obscure language that is considered "dirty" by those who dont understand it at all (Java crowd). Remember, power != ease of use.
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.
I'm old enough to remember when discussions on Slashdot were well informed.
There's a good possibility that I'm the instructor being referred to. Before you call me a clueless academic, let me give you some of my creds:
:-).
- I've been programming for twenty years.
- Almost all of my work experience (including all of the last five years) has been in industry, doing hands-on programming.
- I built the NewsTracker service for Excite.
- I wrote about half of the microcode for the MasPar MP-1 series of massively-parallel computers.
- I'm willing to use my real name when posting my opinions, and not hide behind a pseudonym
In my opinion, Java may be fine for applets, but it is utterly unsuitable for large software projects. I'm going to write up a comprehensive critique of Java sometime within the next few months, but for the moment, let me toss off a few problems that immediately come to mind:
- No real analog to const. The "final" keyword only prevents assignment. It does not prevent modification of the object referenced. I consider "const" correctness an important part of good program design, as it helps you catch many errors at compile time, and also acts as documentation for your code.
- In a similar vein, no notion of a "const" method. In fact, you can have a "final" method, but its meaning bears absolutely no relation to the use of "final" when applied to variables.
- No reliable destructors, so you cannot use the "resource acquisition is a constructor and resource release is a destructor" idiom that is so useful in C++. This idiom is useful because it allows you to remove opportunities for error from your program (you can't forget to release a resource).
- Java is a "police state" language, meaning that its designers have decided that they are smarter than everyone else, so they will dictate the programming style everyone has to use. For example, all functions must be class members, all exceptions that may be thrown (except for RuntimeException and Error) have to be declared with a throws clause, etc. There are good arguments against many of these decisions, in at least some circumstances.
The designers of C++, on the other hand, were a bit more humble. They left the language amenable to a variety of programming styles. This has allowed people to experiment to find out what really works, rather than being forced to accept some doctrine handed down from on high.
- The reference semantics combined with "by-value" syntax for objects cause a lot of confusion for beginners. The fact that you *only* have reference semantics for objects causes design problems. For example, there is a real conceptual and design difference between a container of objects and a container of references to objects, but Java mixes the two ideas together. This results in situations where code outside of an associative container class (like a set) can screw up the associative container by modifying the state of objects contained in that container.
- The lack of templates means that one loses some of the power of typechecking, and one has to resort to some pretty clumsy and awkward means of dealing with container classes. For example, in C++, I can have an associative array mapping keys of type K to values of type V, for any types K and V, through the use of templates. The analog in Java is a container that maps Object to Object. The problem here is that I have to do widening
conversions that weaken typing. Strong typing is important because it is an extremely useful tool for catching errors very early -- at compile time
-- instead of at run time, when they are harder to deal with. With Java I can no longer guarantee that all my keys have one type, and all my values
have one type. When I retrieve values, I have to do narrowing conversions, which may result in a run-time type error that I should have been able to catch at compile time. And what if I want to put values of a primitive type in a generic container? Then I have to resort to the truly
hideous kludge of using these wrapper classes to turn them into objects.
- The vast gulf in behavior and syntax between primitive types and object types is a nasty misfeature of the language that throws up barriers to writing generic code.
Yes, references in Java are a lot like pointers in C/C++. The thing is, it's not too useful to think in these terms because all object references are passed by value.
right on! I agree with most everything this dude said
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.
Just out of pure interest you aught to read this comparison of different languages
.
Ps, the stooopid mistake that guy made with the by reference and by value mix up just goes to show there are people who know squat out there. God save us all.
~matt~
0
o
><>
"So there he is, risen from the dead. Like that fella, E. T." - Father Ted Crilly
Is this language made by the same people who started LinuxOne?
___
___
If you think big enough, you'll never have to do it.
It could be done, but it isn't a simple problem. The two languages support a few fundamentally different features that would be difficult to make work together. Garbage collection (Java) and multiple inheritance (C++) come immediately to mind. I don't know Eiffel or Ada, but I'm guessing that they both have a limited ability to manipulate pointers directly, because that's another difficult thing to do with Java bytecode. Anyway, kudos to whoever does it; it would be a very useful thing to have.
If you are modding me down because you disagree with me, use the "Flamebait" category, not the "Troll" one.
In my job, which currently involves both C++ and Java, I don't miss much what Java took away from C++. I don't miss much templates : generic programming can be carried out with well-conceived interface classes : it is less easy and you have to write more code, but it is also IMO more readable than templates, and more safe. And last time I used templates (admittedly, 1 year ago ), I was annoyed by the fact that most errors only shown up when I instantiated a template.
Not that I like everithing of Java, and that I wouldn't like some more feature. And not that I dislike all of C++. It is just that in my expierience the compromise 'power vs easiness' made by Java is more appealing that the one made by C++.
Ciao
----
FB
If the author can get some sound finacial backing, this could very well do what everyone predicted Java would do. Which is making the choice of software by Operating system, all but over.
But even further is that when software is released it's available for all platforms, not just one.
Java was supposed to do that, and it could have, but for the various reasons it didn't.
This project has it where Java doesn't, it's not a new language, it's pure C/C++, which means it has a much better chance of being accepted and used, but only if they get the backing.
I hope they do. It could start a trend with all the other languages we know and love having a Internet sibling
Actually, there is already a processor design to do just that by (who else?) Sun. The processor is called MAJC (Microprocessor Architecture for Java Computing):
http://www.sun.com/microelectronics/MAJC/
So, let's see ... any langauge that requires the pre-existence of some OS feature isn't a real language, by the implied tautology. That seems to rule out everything but machine code.
Java is the blue pill
Choose the red pill
I don't think Java's problem is so much execution speed now that we have HotSpot -- it's the *lack* of libraries. Apps are getting much more connected to different APIs, and with Java you have to make a JNI wrapper for each API you want to support. The world speaks in C, C++ and COM, unfortunately. Of course, Java has other problems, like Sun...
... Applesoft?! Yeah, game developers will flock to this platform...
... complain about cracks in their cube. Anyway, the format of the binary code is inconsequential... the libraries, as you say, are the thing. And things like OpenGL drivers are notoriously dissimilar across platforms, so there goes yer portability.
I digress.. this guy says his VM has a speed advantage without needing a JIT?! A speed advantage over what
So what's the point of portability nowadays anyway? Seriously? Commercial software will be developed for Windows, open-source software will be eventually ported to Linux no matter what platform it starts on, and Mac users will
I too have a vision of a big box with a funnel on top, and I just throw in any number of different CPUs when I want to add horsepower. But thanks to our current chip & OS monopoly, we have no economic need for such a device.
And if you follow ISE's announcements, you will find out that they are working hard to get more and more of Eiffel into Eiffel #.
In the light of that C# only looks like a crippled Eiffel# to me (;
Python is an interpreted language.
The reason there is so much noise about Java, python et al is because there is a glut of 3rd rate programmers with trade school diplomas that are too fucking stupid to understand a real language like C++. That's fine. Most software being written today (and yesterday and tomorrow, for that matter) is suitable for data processing programmers. You're all COBOL monkees or UNIX admins remade.
Java is a nice language. Python is a nice language. Perl is a nice language. But no one is writing commercial grade shrink wrap software in those languages.
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).
I'm old enough to remember when discussions on Slashdot were well informed.
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
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
This is not a new language. Internet C++ is a misnomer. This is a virtual machine for C and C++ that links to the GNU C library. Think of it as a c/c++ interpreter.
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!!!)
--
Sometimes it's best to just let stupid people be stupid.
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
-Michael
Looking at the industry, it appears that there already is a standard "bytecode" that almost every platform can run:
x86 code.
There are a couple issues that this brings up (that I can imagine).
.o files into a meta-language byte-code (that isnt' assembly). So unless the common byte-code IS assembly, you're back at step 2.
,etc. I seperate the last category because unless you take special steps, the interpreter reads from the raw source code. (Yes, Python and Scheme can be compiled, but they're really just token representations).
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
-Michael
ANSI and ISO are standards bodies. So is ECMA. ECMA may be better known for standardizing the language formerly known as Java(TM)Script into EcmaScript.
Will I retire or break 10K?
>Collections/containers/algorithms that aren't the abomination that is STL.
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.)
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.
the big strength of java is not only in its large set of libraries. The real power of java is that it's got C++-like syntax but with garbage collection. Never having to worry about memory deallocation is a big deal and it helps in rapid application development.
-S
Unless the RTL uses a stack for registers (like Java(TM) bytecode does), the different number of registers on different architectures will trip you up when you try to run the RTL through a code generator.
Will I retire or break 10K?
That must have been a typo. He meant MFC I guess.
____________________
Ni!
I think that Internt C++ is not about byte code. It is more like WINE for running win32 on linux. Otherwise they would see the same problems with performance that Java sees. Also, java compiled with TowerJ gives incredible performance, easily comparable with optimized C++.
Looks just as hard to maintain and unreadable as regular C++. Great!
There's no such thing as universal bytecode. Every system is a set of compromises. For instance, the Java bytecode system involves things like identifier scoping, integer sizes, FP formats, package scoping, exception handling, etc. Smart it up and you've got something impossibly complex. Dumb it down and you've got, well, a RISC instruction set.
... we can make a reasonably full-featured socket library, sure ... but everyone wants their own tweaked widget library, that's why there's 1,000 different ones out there.
:)
Also, not every language would translate to a bytecode format... a language where data = code, like LISP, would be very unhappy trapped in bytecode.
And don't tell me about standard libraries
We still can't agree on how big an integer should be -- don't expect a universal instruction set anytime soon
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.;) )
Environmentalists are their own worst enemy. ~tricklenews.com
Isn't this what the .NET initiative by Microsoft is trying to do?
interview with Bjarne Stroustrup in IEEE's computer magazine
UNIX and C were a hoax!
Well, I have a grasp of Eiffel, and as I understand, the first versions of Eiffel didn't compile to byte code (and most still don't). Eiffel compiled to C++ code, then used gcc or another C++ compiler to compile into native binaries. The C++ code that was compiled from Eiffel did have automatic garbage collection built in as a result of being generated. As long as you aren't too concerned with "tweaking" things to make them very efficient (or efficient at all ;). Eiffel's solution was inelegant, but functional. Lately, small-eiffel has added byte code support (but continues to have multiple inheritance). So I guess this begs the question: We have STL, we can build standard C++ libraries for a windowing toolkit that will run across platforms (QT and GTK are two solutions that spring to mind), why don't we use a standardized, portable C++ as the spec to compile to when building these new ultra-high level languages? With a little bit of work, it wouldn't be too hard to make the C++ step of the compilations utterly transparent. For that matter, it wouldn't be much of a technical hurdle to build a Java -> C++ -> Native Code compiler as a way to test the viability of this concept. Either way, I don't think building a new VM is the solution. Give me the Java VM or no VM at all!
Gah
Better? In what way? You'll probably say, "Lisp is elegant, beautiful, and advanced."
But you won't say, "Lisp is useful."
I don't make the rules. I just make fun of them.
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) ???
Ignore the "p2p is theft" trolls, they're just uninformed
Lisp kills brain cells.
:)
It's one of the few langauges you can walk away from to get a soda, come back, and have no idea what you were doing...
I like you, Stuart. You're not like everyone else, here, at Slashdot.
And a 1.8 MB .h file:
.c file is actually remarkably, er, compact, in that all of the actual code is macros. I tend to actually rather like macros more than is considered healthy in C (much less C++, but there are things that templates just can't do, or at least couldn't a few years ago), and I'm a big fan of metaprogramming, but this is seriously over the top even by my standards.
$ 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
Actually, "Standard C++" has three of the above. MSVC does not support return type covariance or design by contract.
-- Too lazy to get a lower UID.
Try programming an operating system in anything besides C or a derivative. It's not going to happen unless your willing to handcode assembly language.
Try Oberon. C isn't the only game in town. Usable, commercial OSs have been written in all sorts of strange languages, including LISP, PL/1, and ALGOL68.
I'm willing to put up with C's funky syntax and radical lack of safety when I am working "on the metal" or when I need the absolute maximum speed. Any other time, it's a pain in the arse.
Also, the number of applications that really need the speed is a *lot* smaller than most people think. I've seen major programming efforts for things like Web applications burn a vast amount of programmer time doing CGI scripts in C/C++ instead of Perl because "it has to be fast". Difference to the user turns out to be unmeasurable, due to Net and database delays.
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
I looked at Ruby as well, but I have to admit, one of the things I like about Python is the fact that it comes with tons of really usefull modules in the default install. I'm sure I'm going to learn Ruby eventually, but for now I want to finish learning Python well. By the way, why is it no one ever writes compilers for these languages? Unless I'm mistaken, there's no reason you couldn't...
-lx
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.
You mean like x86? Sure it's not ideal, but how much more standardized can you get?
-- Virtual Windows Project
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.
Now we're calling a stack machine simulator "technology". Boy, that's pushing things.
Is anyone or any business really gonna back C# ?
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
It's been attempted. Look for UNCOL and then look for ANDF and then download the Tendra C compiler and go for it.
In the form of the new Amiga. It uses Tao's Elate technology, which is exactly what you ask for: a portable cpu/assembly abstraction, with no more language bias than any other cpu (i.e. C mostly) coupled with a nice lightweight OS providing all common functionality. Comes with a very clean assembler, gcc, and a very fast Java JIT. It has already been ported to god knows how many architectures and is (albeit a bit "raw") available now.
This is, however, just my interpretation of the original comment. I have no idea whether it has any connection to reality, as I don't know anything of substance about C# or .NET beyond the basic concept.
I actually got it to complie (sort of) on Mac OS X, only 60 build errors, most of them because of header issues. I'll keep working....
Damn sheep....
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
'final' means 'the last', not 'the latest'...
I know X and opengl are not problems for the windows platform and opengl not a problem for the mac platform, but any other platform then those they could use software opengl or mesa3d. OpenGL should be ONE of the most portable graphics APIs available, so I don't think its much of a problem. Xlib and Motif is probably not as portable, but I know they are on a number of ports like windows.
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.
Seastead this.
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.
:)
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.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
?- Speed (yes, those JIT's still suck)
- No multiple inheritance
- Templates
- Every other cool feature Java thought was too hard to use
- It doesn't have STL
People make the argument that multiple inheritance is "too complicated" and "confusing". I think this is a cop out and lack of experience with a good thing should not be validation that it is not a nice feature. When I try to use interfaces as the alternative it seems really hackish. I want this to be a Thread. Ooops. Sorry. I already have a superclass. Make it Runnable and construct a Thread with it... (ugh)
You think you can make more generic, flexible libraries with Java? Think again. Templates can do so much more and with TYPE SAFETY! It is too great for words. Just count how many times you have to cast in Java. This is a major design flaw.
Operator overloading, default parameters,... This kind of stuff just makes me get warm fuzzies inside. While not strictly necessary, it makes for better looking, cleaner code.
STL is so much more a a superior library than the java.util Collections stuff it's not even funny. Java Iterators do one thing and only one. Go through the elements in a forward direction. STL iterators do so much more, and you don't even have to care if your using a pointer or a class to do it!
I could go on and on, but I've got work to do. Why don't you get your information straight before you start saying how much Java is better.
Just how many dialets of C++ are they going to create? The more dialets out there, the less portable this language is going to become. Sure there are shared libraries, and all, but why do we need yet another C language?
Throw in something that does CSP-style concurrency. Occam, Limbo or Alef.
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.
"Nice, easy applications that can talk over a network" are the cutting edge.
where there's fish, there's cats
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.
--
Java and C# try to provide both portability and security. This seems to only provide the former. The problem with C/C++ is that as soon as you allow pointer arithmatic, you can't guarantee anything.
But no one is writing commercial grade shrink wrap software in those languages.
Guess you have not looked at Oracle's products yet. All of their tools in 8i are written using Java. Including their DB assistant, OEM Consol, Net 8 Assistant, Installer, and help system.
Last time I checked Oracle is a put the CD in and install the software type product (shrink wrapped). They put a VM on their CD and the installer uses it. Thus they dictate their Java environment. When Oracle installs, it installs the compatible VM with it. This is how you accomplish shrink-wrapped products with Java. You dictate your environment so that the moron user doesn't have to configure a path to the JVM.
Crack |
I do believe I know what I'm talking about.
I'm sure the STL is the best thing to happen to C++. (Which is really sad.)
I don't know how you use collections in Java, but the idea is the same -- to let you focus on the logic of your program. It is unclear to me in what manner you find collections are getting in your way?
As for performance, it all depends on what you need. I'll sacrifice execution speed in order to be able to work at a much higher level of abstraction. It improves development time greatly. Computers are getting faster and cheaper every day.
When I really need speed, like in a tight inner loop calculating the Mandelbrot set, raytracing, RC5, etc., then I'll write in C/C++ and hook it together with a Java front end. Since the C/C++ code doesn't need any network code, GUI code, file access code, etc. because it is pure computation, it only needs the standard C/C++ libraries and thus is about as portable as the rest of the system with Java. Even the very mechanism used to mate the Java and C/C++ code is portable.
As for your remark about STL making writing C++ really simple (ignoring the other issues of RTTI, GC, and a safe language) maybe you don't require a very high level of abstraction. Or in complex programs, you don't mind doing all the extra bookkeeping yourself. (lengthening development) The original purpose of high level languages and compilers is to make the computer do more of the bookkeeping (vs. writing in assembler). Just having GC removes a tremendous burden.
I find STL to be just the opposite. It makes writing C++ programs difficult. Just try to make sense of compilation errors involving STL. That doesn't strike me as simple.
About 35 years ago, the hot debate was whether to write in a high level language or use assembler. The arguments on both sides were about the same as today. There was a very real difference in execution time -- and on slow computers this difference is highly noticed. Guess which approach won out? As computers got faster, the difference in execution time diminished to the point where everybody takes it for granted that they should write in a high level language. (I'm focusing here on a higher level of abstraction vs. programming closer to the machine which always results in faster execution -- for programs not complex enough or that can afford the development effort to not need the abstraction mechanisms.)
Maybe I don't know what I'm talking about. But to me, I seem to have found a pretty good environment to write in. Not perfect. Use what gets the job done. If you find C++ to be useful and can work with it well, then great. I know I can crank out lots of stuff in Java, network code, gui's, etc. quickly and never get a core dump, which I find to be important.
I'll see your senator, and I'll raise you two judges.
As computers got faster, the difference in execution time diminished to the point where everybody takes it for granted that they should write in a high level language.
Go read comp.lang.asm.x86 for a while. Not everyone takes it for granted that they should write in a high level language. That said, I agree with you. I think those "I'm going to write an MS Word clone in 100% x86 assembly" guys are kooks. As far as I'm concerned, assembly is only for the inner loop of a realtime system, certain device drivers and certain bits of platform-specific OS code.
At the same time, I think there are a few features about Java that make it less efficient than it needs to be. The whole "all object are on the heap" thing is really difficult for the JVM to optimize away, and impossible in most cases. The lack of generics plus the fact that the basic types aren't Objects makes containers exceedingly inefficient for things like integers, doubles, etc. The whole "magical Array class" nonsense is just a blatant hack to get around this a bit.
Despite that, I still think comes out ahead of C and C++ in most of the situations I have to deal with. If I didn't care about execution speed at all, I'd probably use Python for everything. (Python is pretty quick for some things. It really depends upon what you're doing, as with all things.)
About 2 years ago, people said Java would do pretty much the same thing... but it flopped.
Uh.... You're joking, right?
C# is doomed because it is proprietary.
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?
Try to hack my 31337 firewall!
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
I agree with you.
There are aspects of STL that are good and are not present in Java.
Even ignoring STL completely, there are other good features (templates, typedefs, etc.) in C++ that Java is missing. It was not my intent to suggest otherwise. To not discriminate, there are also other languages with some nice features that aren't present in Java.
I didn't mean to start a language war. Sorry.
I was only criticizing the original article on Internet C++. I don't think that C++ doesn't have a right to exist, or doesn't have uses, etc. I was only criticizing Internet C++ as having the disadvantages of the JVM while not having the huge set of advantages of Java. Not to mention Java's momentum (Sun's investment).
Originally, I said something like: Java has everything going for it except execution speed. Internet C++ has this weakness of Java, yet does not come with all the other advantages of Java. So why should I use it?
Some other posters here have made some excellent criticisms of Internet C++ as well. My favorite was the one about combining the worst weaknesses of several languages/development tools but not providing the strengths of any of them.
I'll see your senator, and I'll raise you two judges.
and even the instructor takes every chance he gets to point out how java is inferior to C++
Translation: "I had to change my course materials thanks to this. The bastards are going to pay."
It tries to help you too much.
Riiiiiiiiight. We should be toggling everything in from the front panel, isn't that so?
but the way it handles runtime errors (or, more specifically, FORCES you to handle them) is pathetic
How about you try working on a project with a lot of other people sometime? This is a feature, not a bug.
It's not so bad...
class Color
{
private Color() {}
public Color Red = new Color();
public Color Blue = new Color();
public Color Magenta = new Color();
}
(The constructor is private so that you cannot create a Color except in the class itself--no extending the enum after it's declared).
Now you've got Color.Red, Color.Blue,
Ev-er-y JVM's different...
You run into all _sorts_ of fun stuff when your in-memory data structures get huge!
But I do like Java!
Blar.
> About 4 years ago, we attempted, unsuccessfully,
> to port a popular 3D game to Java.
Well, duh!
Anybody forming *ANY* opinions about Java (particularly about Java and 3D) based on what there was available four years ago isn't paying attention to what there is now.
Personally, I'm more excited about the VM that's going to be in an upcoming release of Guile. Guile is one of the most robust Scheme implementations out there, and thanks to this VM, it will soon be one of the fastest as well. :)
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
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.
What actual tests? Cite your sources. Also I'd like to see a comparison of programmer productivity in LISP, Java, C, and C++, if available. The simple fact is that LISP is not intuitive to most programmers (and that can be said of most functional languages). Most companies don't even touch them. Most of the functional language use I've personally seen has been by academians and researchers.
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.
Another completely unsupported statement. What benchmarks? What tasks? Just off the top of my head, I can think of several easy examples where this is false. Take anything with bit-fiddling... say, a UUEncoder. I guarantee you that the Java version will be slower (even with a JIT), and use more memory.
The OS argument I agree with, although I will say that C is good for writing small code, which is arguably an advantage here. However, I believe many daemons are written in C that don't need to be... and this could improve security.
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.
Once again - bzzzt. It is a language which gives you extreme control over what you want your program to do. If you are experienced, you learn how to write good code. Someone inexperienced using Java can write incredibly bad code also. The learning curve isn't as steep, and the punishment not as severe (i.e. you don't crash), but that's all. But it's not a substitute for programming experience.
I write C++ for a living, on a fairly experienced team at a game company. In the past year I've only had to track down one memory leak, and I can't recall any mysterious "data corruption". The advantages of C++ completely outweigh the disadvantages for what I'm doing. Even setting aside performance concerns.
Hmm, isn't that what M$ did with C# and the .Net runtime? I know they submitted C# to ECMA but I'm not so sure about the Common Runtime.
PCXL Forever!!!!
So is part of that submission the .NET bytecode format, or just the language? The language means nothing if they can just change the bytecode underneath at will and destroy external compiler projects.
.NET bytecode on the fly to Java bytecode? Ignoring for the moment weither or not that is even possible, if they do not have to conform to a standard for the .NET bytecode then they can just change the format slightly in the next release to break my classloader.
For instance, what if I wrote a classloader for Java that reformed the
I ask not to be abvasive, but because I really have no idea what they are doing with this issue and I think it's a pretty important.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Everything in java is passed by value.
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.
Thanks again.
I watch the sea.
I saw it on TV.
No, Thursday's out. How about never - is never good for you?
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.
Crud. Make that static public Color Red, ...
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".
Never heard of javadoc, huh?
java is cool, but your logic is off.
if you code your java like you should, it will be slower than c. think about it, java encourages object granularity and abstraction, these come at a cost. this will also cost you much more memory to store the meta data a jvm keeps at the class and object level.
on to the benchmarks... the two tests a jvm did win were tight looped calculations (one involving recursion which the c compiler does not optimize for). given that x86 processors have seperate cache for data and for code, in a tight loop, a jit will not be re-interpreted and will actually just call the compiled function which in a tight loop is not likely to have even left the cache. hardly, a condition that would be seen in the real world except maybe by a codec and those often get rewritten in assembler to gain access to simd instructions.
for that particular bench, had c++ been invited to the show, a template could have computed the fibonacci series at compile time, thus blowing them all away!
you should also note that intel'c C compiler was not used, and i've seen other benchmarks where it blow away most of the other C compilers by 10-20%.
jim
Please let C++ die already. It is a bad way to do good things. IMHO
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.
--- -- - -
Give me LIBERTY, or give me a check.
2 more projects trying to solve that problem:
. uci.edu/juice/intro.html+juice+and+pascal& hl=en
http://www.cminusminus.org/
http://www.google.com/search?q=cache:caesar.ics
jim
I should preview before submitting. :(
--- -- - -
Give me LIBERTY, or give me a check.
>> No real analog to const. The "final" keyword
>> only prevents assignment. It does not prevent
>> modification of the object referenced. [...]
>
> Why is this a problem? If you absolutely need
> a static class, use a static class.
This is a complete non sequitur. Do you have any idea of what const means in C++? I am not talking about whether objects of a nested class have access to the instance variables of the enclosing class, so static classes vs. inner classes have no bearing on the discussion. I am talking about being able to write declarations like this:
void foo(C const & x)
or
void bar(...) const
meaning that foo takes a reference parameter of type C, and is guaranteed not to modify the state of x, and that the method call z.bar(...) does not modify the state of z.
> As for docs, that's why there is that
> wonderful thing called JavaDocs that half
> the C++ industry has been trying to emulate.
Again, you completely miss the point or never tried to understand it. I have found, from many years of practical experience, that many errors arise from not being sure whether or not a method might modify the state of an object passed by reference. Javadoc doesn't help you if the person writing the code forgets to put in the necessary comments. But if you develop the reflex habit of always declaring methods to be const when they don't change the state of their object, and always making reference parameters be const if the method doesn't change the state of the parameter, then it is immediately clear what method calls have the potential to change the state of the objects on which they operate.
>> In a similar vein, no notion of a "const"
>> method. In fact, you can have a "final"
>> method, but its meaning bears absolutely no
>> relation to the use of "final" when applied to
>> variables.
>
> This is because you misunderstand the final
> keyword. In general, final means that the item
> cannot be overridden by an extending class.
> It produces a similar function with variables.
On the contrary, I understand exactly what final means. The use of "final" in
void foo() final
means what you say, but the use of "final" in
final int N = 37;
(which may appear in a method body) means something completely unrelated to the first use of "final" -- that you cannot change the value of N.
>> This results in situations [in Java] where code
>> outside of an associative container class
>> (like a set) can screw up the associative
>> container by modifying the state of objects
>> contained in that container.
>
> Huh? If you've got the object, you've got the
> object. You are free to modify it.
THAT'S THE PROBLEM! If you retrieve an object from a set, there are now references to the object within the set and in your code. If you modify the state of that object in your code, you've
can screw up the set, as its code depends on the states of the objects it contains not changing. The set container has no way of protecting itself from this kind of monkey-wrenching. If Java had an analog to const the implementation of a set container could partially protect itself by returning only const references to the objects it contains.
> in an Object container just by keeping a
> pointer to it. You aren't protecting yourself
> from didly.
In C++ you can protect yourself, because a set object stores *copies* of the objects inserted into it, and when you iterate over the elements of the set you can only get *const* references to the elements.
>> No reliable destructors, so you cannot use
>> the "resource acquisition is a constructor
>> and resource release is a destructor" idiom
>
> [Gives an example using finalize()]
> Damn! That looks like the resource will be
> closed just before the class is garbage
> collected!
You didn't read what I wrote, and you don't seem to know the very language you are promoting. Java does *NOT* guarantee that any particular unused object will *ever* be garbage-collected, so there is no guarantee that finalize() will ever be called! (It reclaims storage when it has to, but makes no guarantees beyond this.) Furthermore, even if the object is eventually garbage-collected, there is no way of knowing when that will happen. For many kinds of resources, it is not sufficient to know that the resource will be released at some indefinite point in the far future; you want it released as soon as you are done with it! A mutex is an example of just such a resource, and it was one of the examples; didn't you pay attention to what you read?
>> [Comments about templates in C++ and strong
>> typing.]
>
> You don't seem to realize that this is a
> double edged sword. If you enforce a type at
> all times, you can have no genericity.
It's clear from this comment that you have no clue as to how C++ templates work. The beauty of templates is that they give you both type-safety AND genericity at the same time. I have yet to see any other library that is as generic and flexible as the C++ Standard Template Library, and the STL does this without giving up efficiency in the process!
> You know, it's this type of acedemia that gets
> companies stuck with unmaintainable, buggy,
> non-customizable software.
This is ludicrous. You've never seen a line of code I've written, yet you're willing to call it "unmaintainable, buggy, and non-customizable." I spend a considerable amount of time worrying about maintainability and flexibility in my code, and I have always had very low error rates in my code. Here are some clues as to the quality of my work:
- My boss at MasPar described me as "one of the
most productive and accurate programmers I have
known."
- My NewsTracker daemon at Excite underwent a
significant change in architecture with nary a
hiccup. (It's called proper modularization.)
- My rearchitecture of one part of the C++
libraries used at Excite helped jumpstart
a couple of stalled projects (hint: I took
unmaintainable, non-customizable code and made
it maintainable and customizable).
- TenFold paid me six figures a year to work on
their core libraries.
- Every place I've worked for has been sorry to
see me go.
Enums aren't needed in Java.
As are not templates, typedefs, operator overloading, etc. Right?
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.
Ack, flamebait. oh well.
.
I myself am using java in commercial applications. So your point falls over, and I dismiss your bait offhand as a cocky over reaction trying to ruffle feathers.
Now please foad. Thankyou.
~matt~
0
o
><>
"So there he is, risen from the dead. Like that fella, E. T." - Father Ted Crilly
Sun has NOT comitted to parameterized types for JDK 1.4. I see this as a serious step backward in their progress toward polishing Java.
-
Just because it works, doesn't mean it isn't broken.
Slashdot C++. It's the same language, but all the keywords are misspelled.
Why Java, just improve C++ and declare it C++ cfront 5.0, but uh, oh, Sun would not control the process, and so the way the split in mindshare went. Fuck'em, once stable I'd use IC++
_If2(_sCz11d2,4562,s32,s32){{if((GETDATAMEM_s32((( GETCODEMEM_s32(R_PC+2))+R_PC)))<( GETD ATAMEM_s32(((GETCODEMEM_s32(R_PC+6))+R_PC)))){R_PC =((GETCODEMEM_s32(R_PC+10))+R_PC);}else R_PC+=14;};;}_If2E;
This hardly counts as open source. Try harder, guys.
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.
Why doesn't someone write a C++ compiler that writes out to Java bytecode? That would be a much more useful solution. It's already been done with Ada and Eiffel. Or has someone done it already?
LS
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
IIRC
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.
Now before you moderate me, let me ask you this... So Doom was ported to Internet C++ and Tetris too.. So what ? Until or unless you have major corporations and developer communities take interest in the language, porting games to that particular language is not gonna help. I havent read the features for this Internet C++ yet, so I could be just jerking off here. Anyway my two cents..
Rapid Nirvana
No it's not, as quoted from here: The code scheduling technique was developed for static compilation, and therefore the compilation time was not a major consideration. Even with the simple list scheduling technique for the basic block range, it is necessary to construct a dependence DAG. The worst-case running time is O(n2), where n is the number of machine instructions in the basic block.6 In the IBM JIT compiler, we have implemented a different way of scheduling code within a basic block, running in C * n, where C is the size of the lookahead to be scheduled, in view of the compilation time constraint. Some of the optimizations CAN be quicker at runtime than statically compiled native code optimizations. A JIT, by definition, does not mean a degradation in performance.
WE DONT NEED THIS! we have many of these kinds languages that are much more capable then this. I just dont get it. wow it can do doom and tetris. impressive (notice the dry sarcasim in my voice) cant u people come up with new ideas instead of copying java and doing a crappy job at it??? jeff
on your signiture put "no m$" i want to see how many ppl agree with me
-- Could you use my software consulting serv
nobody needs it!
i dont like the sentence on the InternetC++ Website: ..."
"You can have the real thing. Why program in proprietary languages, such as Java and C-Sharp that are incompatible derivatives of C++?"
who says or feels mindful enough that java is an incompatible derivate of c++? that guys which comes whith cheap marketing like "... you can have the real thing
does that people even know whats the difference between java, c# and c++ or even that derivative internetc++?
i keep believing in java. there are too much "things" coming (and also leaving) the time. java stays!
RelWorp
As someone starting to get serious about programming (moving on from scripting languages like TCL, PHP, etc) I've been looking around at languages deciding what to learn. Something that I found that looks sort of neat is Eiffel. It's a statically typed, dynamically bound, object oriented language with multiple inheritance and all of that jazz. It does pre/post conditions and throws exceptions when conditions are not met. Although it doesnt have a very large following, I thought that it looked neat. It has unix based compilers, is fairly open source (smalleiffel a compiler is under the GPL) and, it's apparently used for MS's evil .NET stuff in some sense. It can compile to java. God this sounds like an ad - I just thought that I'd share - after all this article is really just an ad for internet c++.
It's great to hav cross-platform programming languages, but can we PLEASE have a language that isn't based on C? At all? I for one, hate C++ - I hate languages that are similar to C++, and I don't know many people who like it all that much. How much longer are people going to keep using a primitive language just because it's what they're used to?
I'd like to see some innovation in actual language design sometime - Python and Haskell are a good start.
-lx
Why would we want a standardized language? I thought that greatest thing about the opensource movement was the diversity of programs and languages. I certainly don't want one all encompassing language to be the standard. Everyone has their own taste. It reminds me of microsoft making everything the microsoft way and everything was their way or it didn't work. I am sorry, but I like diversity in languages.
The anti-salmon
Runtime Optimization is the Next Step ... on the fly and
Act accordingly ...
The Future of the Java VM is to make Runtime Optimization,
to Collect Statistics on Object Access, Memory Usage
For Example, pre-allocate memory on a low Level thread (like the Garbage collector) That memory will be available for Heavy Objects
Python is (sort of) bytecode-compiled. You can release the bytecode only and keep your source to yourself if you like -- it's easy to reverse-engineer, but as a commercial software developer you can use licensing against that (or, at least, you can keep yourself delusioned that you can).
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.
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.
What for? This is an "open-source" project, in the sense of "Open VMS". I'm fairly damned certain it won't open in the sense that any of us would recognize.
Slashdot is jumping the shark. I'm just driving the boat.
"JPython, for instance, is Python that compiles to Java bytecode. I don't think there's any reason this concept couldn't spread to other languages."
Because other languages have different object models which can not be translated into Java bytecodes without a huge hit in execution speed.
The JVM constrains what type of language you can compile from and still hope for reasonable execution speed. Languages with a great deal of reflection (e.g., Smalltalk, Common Lisp) are pretty much screwed.
You need a better VM if you really want cross-language capability. The JVM won't do it.
I don't understand how they're going to be any faster than Java/C# when they also have the baggage of a VM.
Anyone know if there's a basis for the speed claim?
When it absolutely positively has to be there.
Something "new and innovative" is actually done right!
--------
Life is a race condition: your success or failure depends on whether you get the work done on time.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
"On a side note, which is better: C++ or Lisp?"
Oh, that's easy - Lisp is much better, especially Common Lisp.
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.)
Between C# and Java most of the developer mindshare for cross-platform server applications has been staked out. This language has to have a whole lot more going for it than simply being Open Source. It is battling incredible odds against entrenched languages/platforms, powerful companies with tons of research and development staff(Sun, MSFT, IBM, etc), several thousand developers, and the natural inertia that keeps people from trying anything new.
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 development goes, being Open Source does not automatically imply mindshare.
PS: What the heck do they mean by the New Internet? Sounds like a rehash of every major Sun, MSFT, etc launch of the past few months/years.
Second Law of Blissful Ignorance
Personally, I won't be using it.
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#?
I gots ta ding a ding dang my dang a long ling long
Collections/containers/algorithms that aren't the abomination that is STL.
Why is STL an abomination? I've never heard anything negative about it before, and never had any problems using it.
--
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
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.
Ignore the "p2p is theft" trolls, they're just uninformed
I had the same idea quite some time ago.
I've worked a little with EiC 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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
And if ECMA publishes C# as a standard, you're going to have to find a new reason why it is doomed.
If Doom is jumpy on any kind of modern system then you know that this is one inefficient port.
Try looking at ACE.
The ADAPTIVE Communication Environment (ACE(TM))
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
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
Indeed Baldricks definition of Irony is certainly better than Alannis Morrisette's.
It isn't just the net that is to blame, maybe I'm mistaken but generally the term seems to be accepted in the US as meaning coincidental.
Orv.
Jim Thompson is also known by the handle "kzinti" on Slashdot.
- --------------------------------
Note: The opinions expressed in this editorial are those of the author and not necessarily those of 32BitsOnline.
-----------------------------------------------
A dialog in two parts.
Dorothy is sitting in front of her PC, staring at the screen when her friend Kordell drops by to visit.
K: Hello, Dorothy.
D: Hi, Kordell.
K: Say, you look pretty bummed. Hacking some more nasty perl?
D: No... I've just been reading Slashdot.
K: Slashdot? That Internet site where you geeks and techheads hang out to talk about computer stuff?
D: We talk about more than that, but yeah, that's the place: www.slashdot.org.
K: Hey, I heard someone at the computer lab today talking about a huge brouhaha over there. What happened?
D: You remember Jon Katz's Hellmouth series last year?
K: About the Littleton shootings?
D: It wasn't about the shootings themselves, but about what happened around the country afterward. He spoke of how fears of "trenchcoat mafias" ignited irrational fears. That geeks and goths and other "misfits" became the subject of much unwanted attention just because they weren't popular or athletic, and about the difficulties of being a teen who just doesn't fit it. Jon Katz wrote some Slashdot articles about what was happening, and he got a ton of e-mail from people all over the country experiencing similar persecution.
K: Sure, I remember -- you made me read those articles . . . but that was last year.
D: Right, well, the Slashdot guys took Katz's articles and many of the Hellmouth posts and compiled them all into a new book called Voices from the Hellmouth. They announced it Thursday -- the anniversary of Littleton.
K: So what's the problem?
D: Well, it's about the posts they published... they published them anonymously and without the permission of the posters.
K: Anonymously?
D: They stripped the posters' names off the posts when they compiled them -- but what I'm upset about is that the posts were published without permission.
K: You mean that they didn't ask author's permission to republish their posts?
D: That's right.
Kordell makes some extremely rude noises.
K: So what? Slashdot's a public forum. Anything anyone says there is in the public domain. Slashdot can take the posts, publish all the books they want to, and nobody can say anything.
D: Not exactly. Just making statements in public doesn't make them public domain. Remember that Pumpkins concert last year? They performed in public, but that doesn't make the performance public domain. If we'd recorded it and sold the MP3 on the 'net, their lawyers would have been all over us.
K: But people used to record Grateful Dead concerts...
D: Because the Dead gave them permission to. They voluntarily gave up some of their copyrights to encourage people to spread their music.
K: And they probably gave up lots of record sales in the process. I bet their label loved that... So people are upset because Slashdot is going to get rich off their posts? I guess I can understand that.
D: Slashdot is going to donate all the proceeds to charity. No one is going to get rich.
K: Then what are the whiners complaining about? Their work is going to support charity; they should be glad.
D: What happens to the money isn't the issue. It's irrelevant.
K: How is it irrelevant? No one's getting rich off their work... so why should they care?
D: Look, Kordell, what if I took that old beater of yours, drove it down to the Salvation Army, and donated it to them.
Kordell laughs.
K: You wouldn't get much for it!
D: So it would be OK with you, then? The money would be going to charity, so you wouldn't mind that I didn't *ask* first?
K: OK, I see your point. I'd be pissed. My old car isn't the same as a bunch of Slashdot posts, though; it's an entirely different issue. I mean, doesn't the subject matter count for anything?
D: You mean of Hellmouth?
K: Exactly! I read most of those articles. There were some deeply profound and compelling stories there... life-altering and life-defining experiences. The kind of stories that should be shared and retold.
D: Actually, I agree with you... they *are* stories that should be shared and retold.
K: Then what's the problem?
D: I also think Jon Katz's last book is a story that should be retold too. But if I scanned it into my PC and redistributed the scans on the Internet, how long do you think it would be before I heard from Katz's lawyers? Or his publisher's lawyers?
K: But Katz owns the copyright to his books.
D: And the Slashdot posters don't own copyright to their comments?
K: No. Not if you post to a public forum like Slashdot. That puts the comments into the public domain.
D: That's funny, because Slashdot doesn't seem to agree with you.
K: Now you've really lost me. Isn't it Slashdot that's taking all the heat for republishing without permission?
D: Yes, but... well, have you ever read the fine print on the bottom of a Slashdot page?
K: You know I don't read Slashdot, and you know *nobody* reads the fine print.
D: Well, some people do. Here, let me show you what I mean...
Dorothy brings up www.slashdot.org in her browser and scrolls to the very bottom of the page. She points to a line of text.
D: Can you read that?
K: "All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest Copyright 1997-2000 Andover.Net."
D: So now tell me... what is Slashdot's position on ownership of posted comments?
K: Well, according to this, the poster owns their comments.
D: Then, O Enlightened One, how can Slashdot claim that they are justified in republishing posted comments without the permission of the owner?
K: Maybe their concept of ownership doesn't extend to copyright?
Dorothy snorts in exasperated contempt.
D: Well if "ownership" doesn't mean copyright, then what could it possibly mean? I mean, what's left?
K: Maybe it's just a liability disclaimer. You know, so that if someone posts something incredibly insulting to the President or the Pope, Slashdot can just point to the disclaimer and say "We don't own that comment -- the poster does."
D: That would be hugely disingenuous on their part. And, if it ever got out that that's what they meant by ownership, it would alienate most of their readers.
K: It's no worse than what many web sites do.
D: But Slashdot isn't just any web site; they portray themselves as being different -- "News for Nerds" and all that.
K: I'm not sure I follow you.
D: It's like this: Slashdot often champions the cause of the Little Guy, especially against the Government or Big Corporation. It's part of their identity. When a large corporation's lawyers try to take away the web site of some little nonprofit or Mom-and-Pop, Slashdot publicizes the conflict.
K: You mean like the Etoy fiasco last year?
D: Exactly. When etoys.com sued etoy.org and tried to take their domain name, Slashdot published several articles. Likewise, when Colgate/Palmolive went after ajax.org, and Archie Comics went after veronica.org. There were others too...
K: And Slashdot always takes the side of the little guy? They use their editorial voice to assert this position?
D: What "editorial voice"? This is *Slashdot* we're talking about. But yeah, their editors say things like "Nice to see the little guys win one..." or "Perhaps we can help Veronica..." And one time Rob Malda said "I'm willing to buy one of those Rios just to make a statement against the RIAA goobers...."
K: So it's not just domain-name disputes where they side with the little guy?
D: Oh no, there are much bigger battles being fought like mp3/Napster/Gnutella vs. the RIAA, the DeCSS vs. the MPAA, Linux vs. Microsoft, and Echelon vs... well, most *everybody*.
K: OK, I see the pattern, but what does all that have to do ownership of posted comments?
D: It sets up certain expectations. People expect them to behave differently than all those big organizations they constantly criticize. People expect them to behave, well, *better*.
K: That's stretching things a bit, don't you think?
D: I have one more example. You remember GeoCities?
K: Yeah, they were bought out by Yahoo last year.
D: Yup, and when Yahoo bought them out, Yahoo's lawyers tried to change the terms of service under which people could post their pages. Yahoo tried to claim that they *owned* anything posted to their site, regardless of who created the content.
K: Stop right there. A blind man could see where you're going with this.
D: Right. But there's a peculiar irony here... Yahoo eventually capitulated and changed their terms of service. When Slashdot posted a story announcing the change, they quoted the guy who submitted the story to summarize Yahoo's new position. He said: "So while they don't own your web page, they can still do whatever they want to with it."
K: Whoa. And Slashdot's position is "You own your comment, but we can still do whatever we want to with it."
D: Seems to be. Eerie, huh?
K: Yeah, but so what? I still don't see how that's going to hurt Slashdot. So they've given people ownership of their postings, then disregarded that onership? I still doubt you could build much of a legal case out of that.
D: Look, you're just not getting it. This is not a legal issue; it's a moral issue. It's not a question of whether it was *legal* for Slashdot to repost all those comments, it's a question of whether it was right for them to do so.
K: Oh come on, you can't convince me that all those geeks care about a question of morals.
D: That's exactly what I've been trying to tell you. They do care, many of them. Go read the posts. They care about whether it's right for some big corporation to take away baby Veronica's web site. They care about whether it's right for the MPAA to quash the DeCSS software. They care about whether it's right for the NSA to eavesdrop on their e-mail.
K: And you think they'll care about whether it's right for Slashdot to do what they've done with user comments?
D: I do. Furthermore, I think many Slashdot posters are going to feel at least somewhat betrayed. Slashdot has always tried to take the high ground... and yet now they're behaving like another Yahoo.
K: How many of *your* posts did they appropriate?
D: Of mine? Well... none.
K: *None*? Then why all your bitching and moaning?
D: Because I've made posts on lots of other topics at Slashdot. I made those posts under the promise of Slashdot's copyright notice - that my posts belonged to me. But maybe some day Slashdot will decide that one of those other topics is at the center of another moral imperative that requires them to publish my posts in another book... without my permission.
K: Would it really harm you if they did?
D: Not in the sense that it would cost me money, but there's more at stake here than money. What about my reputation? What if I don't approve of their moral imperative? My right to decide how my words are used, what reputation I earn, and what causes I'm associated with is *very* important to me.
K: OK, OK... So you and a few others have created an uproar. Has Slashdot responded?
D: Jon Katz and Rob Malda posted a long and rather eloquent defense of the book. They made great points about the significance of the Hellmouth stories, about what Jon Katz called their "moral imperative". But the essence of their argument was that their cause was so important that it didn't matter whether they acquired the permission of the posters. They barely addressed the issue of posting without permission, and where they did, the gist of their statement was that seeking permission was too inconvenient, so they wouldn't do it.
K: And that's what you're pissed off about?
D: What I'm pissed about is the implication that by raising questions about ownerships and permissions, I and people like me are trying to prevent the publication of the book. In doing so, Jon Katz compared us to the "journalists, administrators, and parents" who have tried to silence the Hellmouth posters.
K: But aren't you trying to do just that? If the Slashdot people have to stop publication while they try to track down all the Hellmount posters, it *would* effectively shut down the book. Perhaps indefinitely.
D: I don't want to stop the book, or even to delay it. Let them publish. But, at the same time, they should acknowledge that they violated their own copyright policy, and that they made a mistake in doing so. Not in the sense that it was wrong to publish the Hellmouth articles, but that it was wrong to ignore their copyright promises to their users. And more importantly, they should define for future reference *exactly* what it means that a person "owns" their comments. They should write down that policy in detail, and they should stick by their policy.
K: And you feel strongly about that?
D: This is Stuff That Matters.
Dr. Dobbs has as an article about C-Sharp in comparison against C++ and Java. Has some sample code too.
For years I've been waiting for someone to make Java run as fast as C++. This does exactly the opposite: it makes C++ run as slow as Java. Great, now the worst things about C++ (goofy syntax, poor object orientation) is thoughtfully combined with the worst thing about Java (horribly slow, incompatible VMs).
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
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.
you know it
"Smart companies save money by deploying MySQL instead of Oracle." - slashdot post
From what I can gather of the nebulous .Net architecture, MS essentially has developed bindings for most major languages (or plans to), unfortunately, its proprietary, its vapor, and it will likely suck in any case.
You could go over the docs, download SmallEiffel, and crank out some code, but the fact that you are highly unlikely to use it in a useful manner.
The mindshare for Eiffel is miniscule to nonexistant, and its opportunity to make an impact on the language scene came and went many years ago.
Basically, its a dead language.
Java being "a user's nightmare speed wise" is a oft repeated myth. Server stuff (which the language is predominately used for now) is quite quick. The latest IBM VM is as fast and sometimes faster than C++, not to mention infinitely more maintainable. Plus, the Just-in-time compilers really zoom. The only area Java really lags speedwise is in the GUI, something that seems to be getting considerable attention at Sun. I find it difficult to believe Internet C++ will go anywhere. C++'s syntax is clumsy and pointers lead to truly hellish large coding projects.
After the recent post about the amiga DE, a multiplatform SDK than uses a VM and platform independent machine code, I was a bit concerned that there would be no open alternative.
This is so cool. Code that fulfills the promise of write once/core everywhere.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.