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.
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
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.
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.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
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 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.
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.
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.
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
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
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.
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?
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
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
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
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.
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.
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
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.
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?
As I see it, the big strength of Java is it's huge set of portable libraries. A portable and well designed framework for building GUI's.
The strength of a language (besides the fact that it has to not suck to begin with) is that language's standard lowest-common-denominator libraries.
If you've ever had to build a GUI in C/C++, you know it is not portable. You can write a front-end to your application in several different frameworks -- or try to work with a lowest common denominator framework that runs on your platforms of choice.
Java not only solves this problem, but does it nicely. Pluggable look and feel's. A well designed framework -- better than some of the other frameworks I've used.
But not only a portable GUI toolkit, but portable everything else with it. e.g. Collections/containers/algorithms that aren't the abomination that is STL.
In fact, it seems to me that Java's biggest weakness is execution speed. It has everything else going for it. Type safe. No unhecked runtime errors. RTTI. Garbage collection. Portable object code. And on and on. Given Moore's Law, it seems that Java, or a language like it is destined to become a widely used language.
Can Internet C++ (or C# for that matter) really already have the huge investment that Sun has made in Java? In fact, I find it ironic that Internet C++ and C# seem to be becomming more like Java than Java is like C++.
Or maybe I'm trying to ask, what does it really bring to the table that I don't already have? (Besides being the C++ language which might be useful if I have a huge investment in C++ code.)
The article talks about lots of standard libraries, POSIX, MOTIF, X, etc. This doesn't give me portability. It means I can only run on platforms with those capabilities. (If I read it correctly.) Or do they mean that they are going to bring X, OpenGL, etc. to everywhere. Now that would be cool. And a huge task.
I'll see your senator, and I'll raise you two judges.
I just got back from OOPSLA (Object Oriented Programming Systems Languages and Applications) and didn't see a mention of this. Not that that's surprising, but I'd've thought they'd've at least arranged for a BOF.
Still, one of the smartest things I heard at OOPSLA was David Unger(sp?) of Sun recommending that everyone learn at least one new language a year. His assertion was that everytime you learn a new language you also learn alternate strategies to apply in your other languages.
--
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.
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
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.
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.
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.
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?
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.
That's just bogus. If the information you want can be cleanly generated from the source, why maintain parallel files saying the same thing?
To get an overview of what a Java class does, generate the Javadoc. That's what it's there for. Even if you haven't bothered to write javadoc comments, you'll get a list of methods and fields for each object. To get a list of methods without generating javadoc, use any semi-decent IDE.
Use a semi-decent IDE anyway. It's amazing how much more productive you can become with the right tools. I particularly enjoy stepping through a program, changing the source from within the debugger, and have it integrate my change directly into the still-running code.
As a general rule, if your idea for a class name ends in -able, then you're probably thinking of something better off embodied in an interface.
I've only ever been in very rare cases where I really wanted to use multiple inheritance. Most of the time, instead, I found that when I refactored my code so that it would work with single-inheritance and interfaces, it ended up being far more elegant.
On the other hand, there's no excuse whatsoever for Java's designers having left out enumerated types.
Charles Miller
--
The more I learn about the Internet, the more amazed I am that it works at all.
Slashdot C++. It's the same language, but all the keywords are misspelled.
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.
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.
-- Could you use my software consulting serv
You are an idiot, masquerading as a programmer. If you wish to flame a clueless academic, you should at least make sure you have the wit to do so intelligently.
The const problem is a real problem. I like to be able to say that the method I'm passing an object to promises not to modify the contents of that object. Your mention of 'static' is totally irrelevant in this context. And the author clearly understands 'final' which is why he says there's no real analog to C++s 'const' methods.
Your 'finalize' method example provides absolutely no guarantee about when it will be called. You may run out of file descriptors, or whatever other resource you're using before the GC is run. The GC only deals with memory, so it won't run when you run out of file decsriptors to save you from stupid, needless errors when you open files.
The real answer to his 'no destructor' argument is the 'finally' clause of a try ... catch block, which is just as bad as having to remember to 'delete' things in C++.
As for the reference vs. value semantics of objects vs. primitive types, Java obscures the issue. It's easily as bad as the fuzzy distinction between arrays and pointers in C.
C++ container classes that contain by value do a good job of making it a bit of a pain (and sometimes impossible) to get a pointer to the value they're actually holding. Java, cannot make this a pain.
I personally, would shoot anybody who used 'instanceof' in an OO program in a statically typed language. That just screams 'bad design'. Templates are a far better means of achieving genericity than run-time type checked casting.
Need a Python, C++, Unix, Linux develop
While I agree that the interface idea is an excellent idea, I found, on occasion, that I want mixin interfaces that actually have code and data behind them.
In particular, I have a reference counting class that has a reference count in it. Several classes I have multiply inherit from the reference counting class, and a different data containing class, and this works out well.
This couldn't be done in Java. Of course, Java wouldn't need a reference counting class, but the principle is the same.
Need a Python, C++, Unix, Linux develop
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
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.
First off, you're a sick monkey. Keep it up.
Second, this means Mac OS X supports development in C, C++, Objective C, Java, and soon Internet C++, while C# might be ported just to keep the antitrust types at bay. That's a lot of C, especially for an OS whose headers still feature the pascal keyword in places. Mmmm, irony.
I use Macs for work, Linux for education, and Windows for cardplaying.
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"?
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
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"?
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
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.
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.
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.