Slashdot Mirror
Java To Overtake C/C++ in 2002
jarek writes "ZDNET has an article that talks about latest research data.
It talks about how Java is overtaking C/C++ next year. The article also talks about developers adopting linux and putting linux to use in mission critical tasks." It's evidently taking developers from the C/C++, but also the Visual Basic camps, with strong growth overseas.
Um. AltiVec's C API is presumably coded in assembler. So you can't do really fast DVD in pure C either.
Anyway, you can call C APIs from Java. So, yes you can write a DVD in Java, as much as you can write it in C! All the hardwork is done in assembler anyway...
There's probably nothing that C compilers do that can't be done by a Java VM. Some of the VMs use C backends anyway.
(Not that I'm claiming that current Java VMs are optimising for vector stuff, they may very well not be).
>I'm having trouble imagining a Java tool that could automatically
>vectorize code where Java has no way to express vector operations.
Well, Fortran can optimise vector stuff fairly well. If the VM spots similar structure in a Java program it may be able to implement the same optimisations. I'm sure the devil's in the details, but it's not impossible.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"With JIT compilers becoming faster and faster, and the paradigm shift of user applications from autonomous programs to web applications, Java is becoming more important.
However, C and C++ will remain very important, for example for system programming. A lot of Unices, MacOS and Windows are built on these two languages. Component, object and application frameworks like MFC, KDE, QT are written in them. A very large application base is written in them and it will not be replaced overnight.
I don't think Java will ever completely take over C/C++, simply because the hardware accessibility just isn't in Java and you need it when programming an OS.
But when building a new application, Java is more often than not a better choice than C/C++, simple because it was build with networking in mind.
My overall impression of VB is that language development is geared more toward PHB's who are looking for buzzwords than towards programmers. Case in point: OO inplementation. I remember my excitement when I heard that VB was finally going to implement inheritence, and my disappointment when I learned that by 'inheritence' they meant 'button to copy and rename an existing class'.
My biggest frustration with VB was that I kept running into walls, limits to the language that made it impossible to do what I wanted without some ugly kludges.
Both C and Java are nice languages because they are small and are appropriate for particular tasks, roughly "low-level" and "high-level" applications. As a language, it seems that there is too much in C++ to be able to learn it well, and C++ tries to have it both ways. Garbage collection in particular is very nice to have for "high-level" programming because it removes one large set of "low-level" details to worry about (or at least, worry a lot less about it). Two more messy low-level details missing from Java are include files and make files. I think we can live without them for many programming tasks.
Ever heard of the KVM, it's a small virtual machine held in only 40k used in cellphones and Palms.
Is Java going to replace C/C++? Answering yes to this question is another, more stupid, bold statement. C/C++ has been around longer that any other known popular languages and there's a simple reason for this. It's Reliable, Flexible and it performs well. That's all a developper needs from a language. Can you say the same for Java? This is more questionable than most people think.
People that want to get rid of C/C++ are just frustrated because they can't master the masters' language and people that want to get rid of Java are just frustrated, because some have found uses to a language that is definitely inferior to C/C++.
So in conclusion, Java is fun and all, but it's not going to replace a more flexbile tool and it's not going to pushed aside either because you can't make a kernel out of it.
Java + Webapp = another failing .com ;)
can't write an FPS in java, eh? so what do you call the quake clone done by the team at fullsail? it was shown at quakecon just last week and was received very well from what i've heard. see javagaming.org for more info. - danboo
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Quite a few actually:
. ht ml
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages
Stroustrup's presentation notes can be found here (PDF format). I invite anyone interested in knowing what he actually said to take a look. It certainly doesn't sound much like Java to me.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Well I guess it depends on how you measure "speed". Do you mean perfomance time related to the application itself or do you mean time to market? Which is more expensive for a company - hardware or humans? The human cost is often overlooked when we speak of how "speed is of the essence".
I know plenty of developers that like Java simply because it's easy to program and you can roll out applications relatively quickly when compared to C++. Now I know that statement is opinion and everyone has an opinion, but saying that Java is slow is misinfomed. Given that applications are so network-centric these days, Java can truly shine in a server environment where the resources are plenty.
But to be honest, comparing these two languages is not fair. Here is a good article on why they are apples an oranges
Look at all those OS kernels and low level software. Is there there any way that Linus will throw away his kernel for a Java replacement?
Ok, I hear your arguments. But it is not about choice of language. It's about choice of model.
In C, you're developing in structured programming model. In C++ you're developing for object oriented programming model. C is the best known language in its model. It has easily killed BASIC, PASCAL or any other competitior. And Java is a very strong language in its arena it seems like it will be able to kill C++ in a year (as the article says) and any other competitor (Smalltalk, ObjectPascal) is already out of the way.
But until we change the way this machines operate object oriented model will not dominate. Thus in a few years we may see KDE replaced with Java version. But it's unlikely to see Linux replaced by JOS (http://www.jos.org) in even twice that period.
I don't know about CD-R or DVD (though I suspect most limitations consist of the lack of a hardware speaking interface in Java), but with the Office suite comment, you are refering to the lack of a fast windowing toolkit for Java.
Believe it or not, that's about to change. If you've ever seen IBM VisualAge environment, you should know that's written in Java. The window speed is just as fast as any office suite. I was surprised just how fast it was.
The people who wrote VA work for a company called OTI. The windowing kit they used was something proprietary and closed called JFace, but from what I understand, they are ready to release and open-source it to the public in the next few months, although the website is password protected right now.
Don't sell Java short. it's not system level programming, but it's hardly something to be dismissed as 'too slow'.
I was thinking of how to intentionally fail my drug test... It would make a good memoir story someday.
Not to meantion that python is OO, and being Free Software will probably overtake Java in a couple years anyway. ;=)
When I was able to do my own spam-armoring, you got a chance to email me. Now you can only hope I see your reply.
As for FPS, the next JSDK release (1.4.0) contains an exclusive mode that allows you to disable the windowing system. See the fullscreen exclusive mode API tutorial. There's already a bunch of OpenGL wrapper API's also, with the upcoming OpenGL 1.3, the JVM just may be the application that ships with games rather than DirectX. This is a very good thing as this means games being just as portable as Java, ie. the very same game runs equally on Solaris, Linux, HP and Wintendo. So gamers install JVM's - who cares about Microshaft shafting Java in XP? However idealistic, it's food for thought.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
How many different types of cell phones/pda's can you think of? Many, right?
Wanna write an app for them? which one are you going to pick?
Portability. Write it in Java and all the units with Java suport can run it despite drastically (or not so drastically) different hardware.
$sig=$1 if($brain =~
I use both Java and VB (and other things) and find it odd to hear that you can't find the information you need for VB, because I've always thought that MS's online docs were well-organized and complete. Usually when people complain about them they haven't explored what's available. It's usually possible to get a very specific answer to a given problem, often with sample code.
Try msdn.microsoft.com. Don't mess with their site navigation, just do a full text search.
As for books, quantity is not as important as quality. How many books on VB do you need to read?
VB does make it easy to write horrificly bad code. But in the hands of someone who knows the tool, it also makes it easy to write elegant software. For that matter, I've seen some awful Java code, too.
Obviously you haven't been looking at what has been going on in the realm of "server-side" Java -- J2EE, Enterprise Java Beans (EJB), etc. or you would not say such things.
AltiVec's C API is the highest-level vector API I've used. It has unambiguous and standard C syntax extensions for vector operations. Yet, we still don't have C compilers that can automatically vectorize code. I'm having trouble imagining a Java tool that could automatically vectorize code where Java has no way to express vector operations.
Maybe you could write a Java DVD player that was the equivalent of cat /dev/dvd /dev/hardware-mpeg2-decoder-device, but that's about the extent of what you could do in today's Java.
Processor power is up, and cheap. Architecture isn't standard. Write a VM once for an architecture, then you can run all your pretty PDA Java applications irregardless of what you're running them on. You're suggesting that every portable-item have all of its applications coded specifically for it. Even if the only games in the world were solitaire and nibbles, that's a lot of applications to re-write everytime a new device comes out with a slightly different architecture/instruction-set/whatever.
Oh yeah, and Java is a buzz-word. Makes people happy when they have a buzzword-compliant item. The toys just seem so much COOLER then.
what the hell is a 'junk character', anyway?
Boy, you must be pretty stupid if you can't even program VB. Creating multiple controls is like the easiest thing to do. Create a control, any control. Set its index to 0. Now use load cname(i) and where cname is the name of the control, and i is a number, and it'll create that control.
Not true. Have you ever heard of dynamic optimisation? A dynamic optimizing VM like Hotspot can actually run some code faster than native code, because it tunes the code to actual runtime conditions.
Female Prison Rape in NY
The development of Java and its class libraries is controlled by the Java Community Process, not by Sun.
What I'm saying is allowed is being more specific about what types of class can be used for a type parameter. In C++, all you can do is write template <class T>. Here T can be any type, and you have to jump through hoops somewhat if you want to say "only things supporting MyInterface are allowed". The proposed Java generics seem to have this built in.
But this is the problem. It's not just a convenience mechanism in the context of generics, it's essential. Suppose I want to write a generic summing algorithm, iterating over an array of values and producing values[0] + values[1] + ... + values[n]. I'd like to write something like the following.
Unfortunately, while that works with arrays of int or float, it's no good with arrays of, say, BigInteger. Effectively, because user-defined types can't use the normal notation for addition, I need to have two versions of my "generic" algorithm, one for fundamental types and one for UDTs.
Even then, I run into problems if not all UDTs use the same semantics for their add (or whatever they choose to call it) method. For example, since a BigInteger is immutable, I'd have to write a custom version of my "generic" algorithm to deal with this restriction, since the existing one breaks down in the way it stores and updates total. None of this would happen if UDTs could follow what is, effectively, the normal interface for addition.
Incidentally, this code also provides an example of point 4 (inability to differentiate between value and reference types). As far as I'm aware, the line
isn't valid Java. So, again, my "generic" algorithm breaks down because fundamental types need one style of initialisation, while user-defined reference types need another.
Both of these points come down to the same thing: in Java, you can't write a class that looks like a fundamental type. As long as there has to be a distinction in the syntax used with these types, you can never write completely generic code, which is the obvious goal here.
Aside from the lack of complete generality noted above, without the ability to parameterise on integral values, it's effectively impossible to do compile-time induction via generics. That particular technique is used by high performance math libraries for things like automated loop unrolling, generating matrix code, and so on.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.