Java for EGCS 213
Drew writes "Anybody who thinks java is slow should check this out. The company soon to be formerly known as Cygnus released libgcj today. "libgcj" is the runtime library for gcj, the java front end to egcs. Find out more at sourceware.cygnus.com "
Java native compilation is not worth it. (Score:1)
There's been great promises for Java native compilation for years. Yet no one seems to be delivering -- with the exception of Tower Technologies.
The problem with all the native Java compilers seems to be the same. As a Java developer I am forced to give up features of Java should I want to compile them to native binaries (JIT not included). And these are important features I need to give up -- quite frankly, I would find it very unappealing to use Java without things like dynamic class loading or Java Foundation Classes.
So what if you don't need any those "nice" features of Java.. you can use native compilation then, right? Wrong. Unless you're willing to write your whole project from scratch by yourself. Java by its nature has excellent support for componentized programming/design and code reuse. So if I want to use a bean for example, from someone else, I'm forced to go look through their source code -- if it's even available -- to see if they use the features my Java-to-native-binary compiler doesn't do. Not very good.
So there doesn't seem to be alot of competition in Java native compilers. And it's starting to show. IBM already beats Tower's Java native binaries on Linux with their Java Virtual Machine + JIT compiler on OS/2. And others won't be too far behind. All the research, development, and competition is in the Virtual Machine and JIT space, and it shows.
Java native compilation today is not a good solution because of its restrictions. It hasn't been a good solution for the last 2 years it has been promised to bring Java to lighning speed. There doesn't seem to be a lot intentive to push this area to do great things. All the work is done in JVMs. So the only place I can see Java native compilation have use at the moment is the embedded space, where the memory resource pigs, JVM + JIT, cannot be accommodated.
Jay, without an account.
Linux coders are biased against C++, that's why (Score:1)
The fact is, that in the real world, most problems do break easily into an OO framework. I work in a financial instituation, and we deal, not with data or algorithms, but objects. Decent OO analysis of a problem (rare, but it can happen), can lead to a problem being broken down into its logical components, leading to code that it is clean, loosely couple and (this is crucial) easily modifiable. In a well designed system, code should know as little about other parts of the system as possible. This is far easier to achieve using an OO language.
I'm not desperately fond of C++ myself (though for different reasons to the ones you cited), however I *do* think that OO programming was a massive step forward. Unfortunately for OO, a lot of programmers who came across OO, concentrated on the inheritence aspects of it, rather than the componentisation aspects of it. Inheritence is responsible for spaghetti code that makes one long for GOTOs everywhere. If you want to see good examples of OO thinking, read the Design Patterns book
Streaming is a good thing. Not only does it give one some very elegent tools for filtering, but it allows a high degree of abstraction, that simply isn't possible with printf. In fact the way it works, is very similar to the way that the TCP/IP protocol stacks are designed. You can change one layer, without affecting the layer to levels above.
Proper error handling without try and catch is almost impossible. Return values really don't cut it. Fine if you wrote all the code yourself, but what happens when you start using other people's code? What if their code doesn't handle errors properly? What if the best place to deal with an error is several layers down the stack (this might be true with a file exception, for example, as this might require some form of rollback).
Private, protected and public keywords are essential in a large programming environment. They're not enough, mind. What C++ (and Java) really lack are contracts. What you are doing is designing by interface, and in effect saying to other programmers, these are the bits you can rely on, other bits may change. So this gives you flexibility to modify your code, knowing that you won't break other's code, because this is enforced by the language.
It's arguable as to whether C code is faster than C++ code with modern compiler optimisations. A lot of the optimisations that C programmers make in their code, can in fact make the optimiser's job impossible, leading to inefficient code.
There's nothing that one can do in any language, that you can't do in another. Does that mean we should all still be using assembly?
One can do all these things in C, but C++ makes one's job far easier, making one far more productive, and able to concentrate on the things that matter
Cian (who's lost his password)
Why hasn't Sun done this? (Score:1)
-- Dave
any Similar IDE's to Cafe for linux? (Score:1)
-xyster
Linux coders are biased against C++, that's why (Score:1)
C has the nice property that, basically, the computer does what you tell it to do - line for line. (After all, the saying is that C is merely a portable assembler). This makes it much easier to debug for the beginner. If you cannot even quite figure out which function gets called (and in C++, it is not that clear with overloading and polymorphism), you are not being very productive.
So, for hobby programmers (which the Linux community mostly is), there is not much reason to initially go to the trouble of learning C++, or Java. I guess that is much of the reason why C is used as much even though C++/Java are generally believed to be better tools (in that you are free to use what you do not like of them, and C is mostly contained inside both of these languages). And once you are stuck in C, learning another similar, but harder, language is NOT easy.
--
C++ has lots, and lots, of... features (Score:1)
However, C++ does have a whole lot of different things and getting used to them will require some time. Sure, concept by concept, it is probably rather easy to learn, but one has a long way to go before he is reasonably comfortable with the majority of C++.
For a newcomer to programming, I believe all the different concepts will be confusing. C, while simple, is very small and as a programmer you use most of it all the time; therefore you get very used to it and make fewer mistakes.
I am not arguing that C++ is a bad language, only that it takes time to learn and without proper guidance you are likely to get lost.
--
Ah, yes. Recursion. (Score:1)
Yes, I recall people having great difficulties understanding the concepts of recursion when we were taught programming (SML) in first year of University.
Also, pointers seem to be a great problem until you figure out just what they are about. Then they are easy and powerful (though a bit error prone).
I actually quite dislike Java for using pointers almost all the way but never telling programmers about it. I think that is likely to create a bit of confusion. In C(++) you at least know when you are getting into the area.
--
Ah, yes. Recursion. (Score:1)
MyObject a, b;
a.value = 1;
b = a;
a.value = 2;
and suddenly b.value == 2, I feel that a and b are indeed pointers. The actual term might be different, I do not know, but indeed they work rather like pointers. If not, touching a.value should not change the value of b.value
This is why I think that it might be a bit confusing. If you have to say *a you will at least realize that you are dealing with a pointer and there might be other pointers pointing at the same memory. I guess...
Then again, I never did much Java, so perhaps I should just start shutting up
--
No operator overloading?? (Score:1)
I have seen in some commercial toolkits (like e.g. ObjectStore) that every kind of operator (including the comma, makes nice method invocations) is overloaded. This makes code simply ugly!
Why hasn't Sun done this? (Score:1)
JIT compiler drawbacks.. (Score:3)
Linux coders are biased against C++, that's why (Score:1)
Take, for example, a string class in C++. Many beginners will build a string from characters by concatenating each character to the end of the string (thestring += thechar). This resizes the string on every character added, as a new array is created (1 char bigger), the old data is copied over, and the old char array is deleted - all internally and automatically by the string class. Sure, this is really easy, and that's the problem - the beginner doesn't realize how much inefficiency is going on behind his back.
Doing the same thing in C leads to much less temptation to be inefficient. A C programmer would not follow the above example because it'd be a pain to keep resizing your char arrays (keep malloc()'ing new arrays and free()'ing old ones). Therefore, the C programmer would be forced to do use the more efficient method of deciding the array size before hand, then just putting the characters into it.
Sure, this is a fairly trivial example, but there's lots more of similar cases. I'm not saying it's not possible to write great, small, fast, C++ code, it's just that it's a lot easier to write big, bloated, slow code in C++ than it is in C.
So even though C++ is easier in many respects for beginners (the compiler automatically takes care of reference parameters, automatically determines the data types for outputting and inputting to/from the console, etc.), I still think it's a good idea to learn C first, to understand how things really work, and then to learn C++. Of course, most schools don't agree with me. Oh well.
Syntax Highlighting (Score:1)
Linux coders are biased against C++, that's why (Score:1)
Well, in colleges, it really depends...I know of several colleges that start out with C, and several that jump straight into C++. Thanks to the AP board, all high schools now start with C++, since the AP test covers C++ (it switched from Pascal to C++ this year).
Linux coders are biased against C++, that's why (Score:1)
Oh, sure they can go use reserve() or one of the many other ways to optimize things like this. The problem is that you don't have to, and a beginner will typically not do things that they don't need to do to get their program working, if they even know those things exist at all. A C beginner will most certainly do things the correct way, simply because they're forced to - it's easier to do things correctly than to do weird things like resize arrays constantly.
As for which language to use when you're not using classes, it depends largely on personal preference I suppose. Several of C++'s C++-as-a-better-C features are nice (such as being able to declare variables just about anywhere), but I prefer using real arrays (what the computer science books call "C-style arrays") rather than range-checked vector/matrix classes.
PS: Prior experience with C is, if anything, a handicap to learning C++, especially is C is the only language the learner has previously used.
I disagree - knowing what is going on internally is always a good idea. If you know how a vector or a string or some other class works internally (and the internals of classes often are very similar to straight C code), you know more about what things to do to more efficiently use the class.
In fact, having a basic idea of computer internals and assembly language is a good idea, IMHO. Extensive programming in assembly or knowledge of minute details of hardware is not necessary, but having a basic idea of how everything works low-level is a good idea. More knowledge rarely hurts.
Explanations Please? (Score:2)
This could mean that Linux is going to supercede Windows when it comes to Java support.
The problem with Java (Score:1)
But Java's not JUST a bytecode, it's a language and a class library also. Why? Doing "write once, run anywhere" this way is more than the simplest possible solution, which makes it Too Much.
Use the existing C library. (Score:1)
Ummm...yeah.... (Score:1)
Has Cygnus also simplified their C++ compiler to get rid of all that class stuff?
Hello! VM's are what Java is all about! If you get rid of the VM, what's the advantage of Java? Buzzword compliance?
Multiple Inheritance (Score:1)
Not me, but I'm willing to be convinced.
Send me a URL, recommend a book, anything... I'm not a fan of inner classes, probably only because I haven't seen their usefullness.
Please, explain...
Multiple Inheritance (Score:1)
Ok, I was exaggerating a bit, I've actually seen inner classes used twice before in one interesting manner. (Once on the patterns mail list, and later at a client) Essentially, it was used as a sort of inverted proxy pattern.
So you have this sort of doWith operation.
class With
{
public static void doWith(SomethingToBeDoneWith s);
doSomethingInteresting();
try
{
s.doSomethingSpecific();
}
catch (Exception e)
{
}
finally
{
endSomethingInteresting();
}
}
where SomethingToBeDoneWith was implemented with an inner class.
Thanks for the feedback.
alan
The problem with Java (Score:1)
Thank god!
You say this because you have chosen Definition #3 of what the word "Java" means ("a virtual machine") and ignored the other equally true definitions.
Java is also a language. It is a good language. I would like to write programs in it.
Virtual machines are cool. Security models that allow network-distributed code are cool. Serialization and agent-like behavior is also cool.
But these are not what I'm most interested in. There are a lot of people who are most interested in those things, but me, I just want to write a program that will run on some suitable number of architectures. I'm happy distributing binaries for each architecture to do that. Sure, having one binary that ran on everything would be nice, but you know, it's just not a hard requirement.
Today, I program in C.
I think C is a pretty crummy language. I would like to write the same kinds of programs in a better language.
I would like that language to be Java.
It's just that simple, and that's why this is great news.
The reason I like Java is because it's a language that both supports implicit storage management well (meaning, at the language level) and because it provides good tools for programming in an object oriented style.
Note that there is no such thing as an ``object oriented language.'' You can write code that looks like assembler in Java too, if you want. Java is cool because it makes sensible style easy.
Unlike, for example, C++.
C is a fairly crummy language, but the reason is that C is basically a set of macros on top of PDP-10 assembler, and who wants to hack in assembler? That abomination we know as C++ is a set of macros on top of C that try to bring it kicking and screaming into the early 80s, and the end result is, well, object-oriented assembler.
Not to mention that while both K&R C and ANSI C have proven to be extremely portable, C++ has proven to be anything but [mozilla.org].
But the main problem with C++ is that it has poisoned so many young minds.
There is a whole generation of programmers who think that these broken, rusty tools that C++ provides have anything to do with an object-oriented programming style! They don't even think to question that C++ has a difference between ``virtual'' and ``non-virtual'' functions: as if a real language would have any other kind!
When I program in an object-oriented style, I do it in C, because C is a better language for writing object-oriented programs (in fact, any programs) than C++.
If you made it this far without gagging, then probably the C++ worms haven't eaten in to your brain yet, and you should go grab yourself a copy of Structure and Interpretation of Computer Programs [amazon.com], and learn what object oriented programming is actually all about. (If you're interested, you can read a mini-review of it I wrote at mozillazine.org [mozillazine.org].)
Java-the-language is not without its faults, but it's so much better than C or C++ it's not even funny. Yeah, I'd rather use CLOS, but that's just not even remotely practical any more.
No pointers?? (Score:1)
This is true of most (all?) Lisp dialects as well. Nothing new here.
I dont' blame Sun; look what Microsoft did to C++ (Score:1)
What exactly did Microsoft do to C++?
I'm familiar with Sun's arguments that they need to hold tight control over Java because of the threat from big-bad-bully Microsoft. I just think their arguments are nonsense. Believe it or not, competition is a good thing. Sun is locking everyone out of inovating in the Java space, because they see it as being better that nobody be able to do anything new than Microsoft be able to do it first.
I'm no fan of Microsoft, obviously, but this is throwing out the baby with the bathwater.
If Microsoft invents a variant of the Java language that's better than the one Sun invented, more power to them. If it's better, I'll use their dialect instead of Sun's, and so will others, and the state of the art will have been thereby improved.
Would you like it if the FSF had been legally forbidden from extending the ANSI C language as they have?
The Java goal does not allow pollution (Score:1)
Of course you can, you just need to check version numbers. Users and implementors of shared libraries do this all the time. Good programmers provide backward-compatible interfaces when they make improvements, to keep legacy code running.
And Java 1.0 and Java 2.0 are not the same language, you know.
We do. Dramatically so, in the case of C. And yet, the world muddles along, and portable programs still get written.
Linux coders are biased against C++, that's why (Score:2)
This is true of any high-level language, really. This is something we learned well in the Lisp world: the barrier to entry for high-level languages like Lisp is so low, and for low-level languages like C is so high, that by the time a C programmer gets their program to even compile, they've already had to jump through so many hoops that they probably know a fair amount about what's going on.
It's easier for a bad programmer to get something done in a high-level language than it is for them to get something done in a low-level language.
Does that mean low-level languages are better, or that they encourage better programming? No, you just see fewer but better programs, because they take longer to write and exclude people who aren't really good at programming from even participating.
It's a shame when a language gets a reputation for being slow or bloated as a result of people having seen bad programs from bad programmers, whereas assemblers like C get a reputation for being efficient because you have to be a serious guru before you can get anything done at all.
And it's a shame that Java-the-language is going to have to live down the reputation of being slow merely because it's coupled in everyone's minds to Java-the-virtual-machine, which is the (arguably inherently) slow part.
All that said, I think it's easier for novices to write good (and portable) programs in Java than in C++ because Java leaves less land-mines scattered around. With C++, there are just so many parts of the language that you simply must not go near if you want the end result to be portable or efficient. Java is much more straightforward in this respect, by virtue of being significantly less complex.
This is too good to be true. (Score:3)
If you were listening all those times, you would have heard me saying that I love programming in Java, I think it's a great language, and it's too bad that it's just not yet practical to write and deploy real end-user programs in it.
Having a Java front-end for a real native code compiler is a great thing, and an important first step. Once there's a corresponding complete Java runtime library (like the classpath.org [classpath.org] folks are working on) then Java will be on equal footing with C.
But not until.
I'm looking forward to that day, because I really do think Java is a much better language than C or C++. My objections to it have always been that it's just not ready yet. I want to use it, but I can't.
What FUD? You're confusing "FUD" with "facts."
I think it's a damned shame how much Sun screwed this up. Java could have been genuinely useful years ago if they hadn't tried to maintain control so tightly, and hadn't tried to conflate so many completely different things (a language, an enormous class library, a virtual machine, and a security model) under one name.
IDEs for Linux (Score:1)
it does... well, everything. From inside it I can...
0) read Web Tools Review
1) check email
2) autorespond to email
3) compile stuff
4) debug stuff in DDD
5) check stuff out of/into CVS, and
6) play Tetris.
what else would you use a computer for?
it takes some getting used to, however. (XEmacs)
not quite (Score:1)
Note that there is a Generic Java spec [unisa.edu.au] as well as the Pizza effort that add templates to Java. I don't know if this stuff can be hooked into the egcs system easily, but if it is, one of your (and my) two complaints would be gone.
Why hasn't Sun done this? (Score:2)
Lack of dynamically loaded classes may be a proble (Score:2)
community, and as long as careful consideration is
given to these system-dependant binaries, this
still isn't going to be fully acceptable for
all java users. One of the things this can't
do is the dynamic loading of classes, which is
very much necessary for doing anything along
the lines of plugins (Yes, I've programmed a
java plugin routine for a program that's sitting
on the back burner. The language has it all).
I doubt this will be a setback for very long;
I'm sure that someone will discover a way to
still dynamically load code with this compiler
with the help of native functions or such.
However, the VM will still have it's place (and
once Sun and others push the speed up in it,
then Java will provide the serious blow it needs
to deliever to a certain Redmond-based company).
Syntax Highlighting (Score:1)
If you want an IDE with syntax higlighting I recommend that you try XEmacs [xemacs.org] (or GNU Emacs). Hairy syntax highlighting, automatic configurable code layout, RCS/CVS revision control, diff/merge interface, tags searching, compiler interface, debugger interface, it's all there. When you cone to write documentation it's the best tool there is (even Neal Stephenson says so, so this must be true). It's got a vi emulation mode if your fingers are wired to the hjkl keys. M-x 1000 praise-emacs! Flames to alt.religion.emacs.
--
W.A.S.T.E.
The problem with Java (Score:1)
Two Java EGCS projects (Score:1)
If done right, this means:
1) Java-the language will no longer be restricted to JVM, but can produce code for _any_ of the egcs backend.
2) You will be able to use _any_ of the egcs frontends for producing code to the JVM backend.
What Cygnus is doing is simply to create a Java system, without the restrictions of a single backend (virtual) machine or a single frontend language.
This is *partially* good news (Score:1)
To a small degree, this may slow the JVM development pace down since many people will run the native compiled code. I work with varying OS:es and hardware, from OS/2 and NT on regular PC:s and Solaris on Ultra5:s. If I can make an application run on each of those platforms without rewriting the code, thinking of MSB / LSB issues and some other not-so-funny stuff, it would be lovely. This is the issue with Java, besides having a clean and efficient language. If Cygnus had released a JVM with the same performance as IBM:s JDK 1.1.7 for OS/2, I would have cheered and danced naked on the streets.
Big deal (Score:1)
I wish people abstained from posting comments claiming "X it's finally here!" when X is not even in alpha. A better heading would be "X is looking for volunteers to complete it!" or something of that sort.
E
Syntax Highlighting (Score:1)
Explanations Please? (Score:1)
The gnu 2.x compiler (and thus egcs) can use different front ends, until recently only C, C++, Objective C and Fortran 77. These frontends share the same intermediate optimzations and backends/code generators.
egcs has also frontends for chill and java.
A front end does nothing more than translating the source language, here java, into object code. So you need quite a lot of supporting libraries (startup code, Java system libraries, eg. for graphics). That is what libgcj will be.
It is big step, but still have a long way to go. Learning Java means learning the Java language (that is kind of a cut down C++) and becoming aquainted to the large libraries for graphics and other stuff. The latter taking most of the time IMHO.
JIT compiler drawbacks.. (Score:1)
I read some nice argument why JIT compilers are a bad idea, but I don't remember why exactly and where I read it - likely it was here on Slashdot.
JIT compiler drawbacks.. (Score:1)
I know, see my above posting. The question about the JIT came up at my work today and I just hoped to get it answered here, where some Java Slashdotters are likely to show up.
This is *partially* good news (Score:1)
It actually does both, as well as source->bytecode.
This is too good to be true. (Score:1)
On the other hand TowerJ suports dynamically loaded classes. Does the Cygnus compiler?
Has Java Progressed wrt Generic Programming? (Score:2)
Has Java Progressed wrt Generic Programming? (Score:2)
This is too good to be true. (Score:1)
You're asking the wrong question. The question you should be asking is "What language should I learn next?"
To be a great programmer you have to be able to pick the right language for the job. This means knowing C, Bourne Shell, Perl and Makefile, certainly. It probably also means knowing C++, Python, Lex, Yacc. Maybe SQL for certain kinds of applications. Awk, Scheme, Lisp for extra credit. You'll frequently end up using several of these in a single project. This is not an exhaustive list of useful languages. See Jon Bentley's books Programming Pearls and More Programming Pearls as well as Kernighan and Pike's The Practice of Programming for more discussion of these issues.
For example, the project I'm working on at work uses C, C++, SQL, and Bourne shell directly. Also Awk on the side.
Linux coders are biased against C++, that's why (Score:1)
You've completely missed the point of exceptions. In the real world, many bugs are in the end tracked down to poor checking of return values. For programs with significant amounts of external interaction, error-handling code can take up as much as 50 percent of the program.
Exceptions can provide a way to do this in a way that will ensure that all those errors are caught, and can be recovered from at the appropriate level. They're not always appropriate, but they can be extremely valuable.
These are features that are essential for very large projects. They also turn out to be useful for small ones too, particularly if you propose to re-use your code. IMHO if you can't see the point of hiding the implementation of an object from its user while still exposing its interface, you haven't grasped one of the funamentals of object-oriented design.blockquote Anyhow, I haven't seen any really good reasons for prefering one language over the other.
There aren't any. There is no single "better" language. It all depends on the application. For any given application, the "best" language mught be C++. It mught be C. It might be Perl, Awk, Yacc/Lex, Lisp, Python, or something else.
Sure, and therte is nothing that you can do in Perl that you can't do in C, either. It's just more time-consuming to do it in C. The reverse can also be true, too.
Java Products (Score:1)
Of course, OpenSource would be even better.
The problem with Java (Score:2)
Multiple Dispatch explained (Score:1)
No. What it does is use the types of all arguments to a function to determine which version of the function to call, and not just one.
To illustrate with an example: In single-dispatch languages such as Java and C++ (to name the two most relevant to this thread), method calls look like this: obj.foo(arg1, arg2, arg3), where obj is an instance of some class. The version of method foo() that gets invoked depends on what class obj belongs to.
In Dylan, method calls can use the above syntax, but they're really treated as if they use the alternate form foo(obj, arg1, arg2, arg3). Here, nothing is special in particular about the first argument, rather, the types of all arguments to foo() are used to determine which version to run.
What this means is that you can specialize a function based on more than a single argument. In single dispatch languages, you can only specialize functions based on a single type tree. That limitation doesn't apply to multiple dispatch, where function calls are specified by the types of all arguments. In fact, Dylan's singleton types allow you to even specialize functions on particular instances of a type!
The ideal is that Dylan compilers are able to determine the real types of all arguments at compile-time, which would make multiple dispatch calls no more expensive at runtime than a static dispatch call in C. If the types can't be accurately determined by the compiler, then it's usually the same as a dynamic dispatch call in a single dispatch language such as Smalltalk or Objective-C. Of course, this makes Dylan compilers rather difficult to write.
For more information on Dylan, I recommend checking out Gwydion Dylan [gwydiondylan.org], a free software project to create working Dylan tools.
Colin
This is too good to be true. (Score:1)
Not yet. It is planned.
No operator overloading?? (Score:1)
I did. I was pointing out operator overloading is in regular use and is not confusing in that use, so claiming it's always too confusing to be worth it is wrong.
a = a + b; with a.add(b);
You misunderstood. a = a + b; means a = a.add(b);
Oh, I guess mathematical notion is less likely to be misunderstood, eh?
try something a little more difficult where a and b are nontrivial
data structures and
a += b;
is certainly not as clear as
a.append(b); (for lists, arrays, etc...)
a.insert(b); (for trees, maps, etc...)
Anything can be nonclear when abused. Operator notion is not appropriate here.
As for projects, two points:
I never have plans for leaving college. Working on research projects as a professor is my plan.
Most projects in Java are probably Web Applets or similarly small stuff that is programmed by one person.
only when a and b are numbers. when dealing with objects of a higher level of complexity then it can become very ambiguous.
Not of a higher level, of a type where operator notion is unclear. a+b is clearly defined for vectors, matrices, all types of numbers, strings, ect. It's appropriate and clearer to use them here, so they should be available.
Personally I'm of the opinion that features with a valid use shouldn't be removed because of invalid uses. Depend on people knowing when to use them.
FUD (Score:1)
Templates in C++ are primarily a way to provide container classes. It's true that Java can do container classes without templates, but it doesn't do them in a type-safe way, and it's not quite as efficent as true templates are.
No operator overloading?? (Score:2)
Interesting. I've never seen a C programmer confused over operator overloading. Would you argue that C should replace a + b with addi(a,b), addl(a,b), and addd(a,b)?
That may seem strawman, but it's the point. When dealing with mathematical structures on which + is defined (complex, hypercomplex, vectors, etc.) it's clearer to use the mathematical symbol.
it may seem like an inocent easy shortcut when you are the only person working on a small program
It is. It expresses the problem in terms I can understand, and makes it simpler for me to program it.
but what about when you are one of 8 ppl working on a large project?
I don't care. I have plans to avoid those things forever. Many people writing in Java are writing one person programs, and they should be catered to as much as the large projects. Anyway, in a large project you need naming standards and others, so just add no overloading on to the list.
operator overloading is just to ambiguous to rely on.
1. It's much clearer to say a + b (where a & b are complex numbers) than it is to say a.add(b).
2. As someone else pointed out, virtual functions and overloading can make it pretty hard to figure out what a function's from anyway. Translate a + b to a.operator+(b) and look it up like you normally would.
Multiple Inheritance (Score:1)
I'm serious in concept, but joking in tone. Java has it's place, too. ("I sort glass. Don't throw me away.")
--
Kyle R. Rose, MIT LCS
Languages only need .. (Score:1)
So yes, anything programmable can be programmed using GOTO, IF and arithamatic (or just assembly language). But just because it can be done doesn't mean it's a good idea.
will egcs accept both .java and .class as input? (Score:2)
(RTFM)
SourceWare a good replacement for Open Source (Score:2)
and want to call it "viewable source" should
look at the name SourceWare.
Incidentally, Cygnus is a good example of how
to make money from free software.
This is too good to be true. (Score:1)
This is a nice solution for server-side java. However, for client-side java, we're still stuck with slow, JIT compiled (or, worse, interpreted) Java.
Anyone know if this circumvents Java's array bounds checking? I suspect it doesn't. When using a good JIT, this is the biggest impediment to fast Java (at least with my code).
Hey, Java is a great programming language. However, until you can turn of bounds checking, and compile code with a GUI, it will remain slow.
W
Ummm...yeah.... (Score:1)
Yes, it falls down on speed issues. That will change, though.
It's good news... (Score:1)
http://wwwipd.ira.uka.de/~pizza/gj/
Templates save some time typing, but that's about it.
Templates and multiple inheritance can be implemented well. However, using these usually ends up in difficult to read, and thus difficult to maintain, code.
A computer language should be set up to facilitate writing code. If "arbitrary" rules are set up within the language such that the resulting code can be written quicker, and is easier to maintain, then that language is not necessarily inferior.
When it comes down to it, all a language needs are basic boolean and arithmetic operators, jumps (gotos, loops, etc), and conditionals (if/then). I believe this was even logically proven (my computer logic courses are too distant now). Java allows for all these. Thus, literally any program that can be written, can be written in a language that supports these features.
That said, I recommend that this author try programming something non-trivial in Java. I have. I've written about 30,000 lines of Java code, as part of a project that sits at about 120,000 lines of code. Java has made this project go several times faster than it would have had it been developed in C++. Some of this is due to the Java architecture. A lot of it has to do with the rich set of built-in packages. Porting is as simple as copying the post-compiled code from machine to machine (it didn't use to be that way, but Java has improved since then).
All I'm saying is that you shouldn't harsh on Java without giving it a chance. Otherwise, you're simply spreading FUD. This is no different than the Micros~1 weenies saying that Linux sucks, since Linux has no support.
Explanations Please? (Score:1)
Also, I'm not totally sure of this, but I think the frontend just translates the input language into an intermediate language. That's then optimized, and passed to the backend, which generates the object code. That's why gcc can compile to so many different architectures.
Also, saying Java is a "cut down C++" is somewhat misleading. Java does, as first glance, look like C++ with all of the bad stuff taken out. It does have some significant differences though. The semantics are different, and garbage collection leads to a diffrent style of programming. Being able to dynamically load classes is nice too...
Has Java Progressed wrt Generic Programming? (Score:1)
Yes, and that's the problem. There are a lot of situations where a Vector is the appropriate structure to use, but you use an array instead because you don't want to lose type safety (and obfuscate the code with a zillion casts). Proper generic containers would be a lot more useful. I often wish Java had them. (No, don't bother mentioning Pizza/GJ; they're unusable for me because they compile to bytecode, not standard Java, so I can't use my choice of compiler.)
Alan
who has written around 25k lines of Java, and has never used C++.
The Java goal does not allow pollution (Score:1)
--
The problem with operator overloading (Score:1)
The problem with operator overloading is that in long peices of code, it makes it hard to work out what is really going on - you cannot tell whether a + b is just an integer addition or some function call, and then you do not know whether it has the properties you would expect of +.
I remember one peice of C++ code that redefined + to perform some operation with a a side effect. You wouldn't believe how long it took me to find the bugs in that (someone else wrote it, I should stress).
The problem with Java (Score:1)
Has Java Progressed wrt Generic Programming? (Score:1)
I would prefer Java to support generics as well - all that casting makes my fingers ache - but I want them to do it properly. C++ templates have several problems - they do not perform up-front checks on the parameters, and there is no way to constrain the types of the parameters. This makes them a pain to use. There is also no way to use them as proper generic types (ie if T is a template you cannot say x is of type T without giving all the type parameters as well, and even then T does not include T).
I prefer the Java situation (whose worst consequence is sore fingers) to the situation with C++.
Woo hoo! (Score:2)
I just hope that this doesn't lead to java forking. It's already started (CommAPI for instance) and architecture-dependent java variants could really screw up the big opportunity for architecture-independent programming.
Kudos to Cygnus!
Has Java Progressed wrt Generic Programming? (Score:1)
Thanks to some changes that were made in Java 1.1, you can now do generic programming in Java reasonably well. Interested folks should check out the Java Generic Library [javaworld.com], a "port" of the C++ Standard Template Library to Java.
One thing the author of the above article writes is that there is almost no performance penalty in using the C++ STL, but there is a considerable penalty in using the Java equivalent (all those downcasts from Object to whatever class you're using cost).
netbeans on the low end (Score:1)
Because of that, it only really competes with the $100 entry-level IDEs, but in that realm it stacks up very well. It's on par with the base versions of Visual Cafe 3 and JBuilder 2.x. Very nice two-way development, a damn fine form painter, Java 2 support, and so forth. Runs like a charm under Linux, too.
There's a high-end version with all the other bells and whistles supposedly on the way, but last time I checked it was vaporware and behind schedule. At least it looks like they made it easier to obtain the beta JDBC support for now.
It's commercialware, but free for personal noncommercial use AFAIK.
No pointers?? (Score:1)
Have you actually used java? Java has references which for all intents and purposes are pointers, but without all of the potential to be abused.
Maybe lack of pointers limits java's usefulness if you are writing device drivers, but other than that, why do you need pointers?
(I've done plenty of C/C++ and Java, and I have yet to find myself thinking that I could do something better with a pointer than I can with a reference.)
Multiple Inheritance (Score:1)
world. C++ is simply superior for this reason. =)
I found myself wishing that Java had multiple inheritance once... then I thought about the problem a little bit and realized that single inheritance + multiple interfaces was a much cleaner solution.
Plus, in some cases, you can actually do multiple inheritance of sorts... you can have an inner class the extends a class, while the outer class extends a different class. This usually results in better encapsulation... (Am I the only one who things inner classes are the best thing since sliced bread?)
Why hasn't Sun done this? (Score:1)
be done with a compiled version of Java.
Yes it can... how do you think native methods get loaded.
Instead of compiling foo.bar.MyClass to foo/bar/MyClass.class, a native compiler could compile it to foo/bar/MyClass.{so/dll}, and let the runtime link it in as needed vi dlopen()/dlsym() (or whatever dll api the machine you are compiling for supports).
How does it match up with Jikes? (Score:1)
This is *partially* good news (Score:1)
For example, I currently use a command-line network tool that was written in Java just so that it would "run everywhere". At the moment, I run it under the JDK, but if I could compile it to a native binary, I wouldn't need to have the JDK mapped in all the time.
Has Java Progressed wrt Generic Programming? (Score:2)
I haven't kept up with "Java2". Can anyone tell me if Java has improved in this regard?
This is a clear advantage of C++ that Java needs to address.
"Elegance of C++" (Score:2)
How does it match up with Jikes? (Score:1)
--Ivan, weenie NT4 user, Jon Katz hater: bite me!
This is too good to be true. (Score:1)
I can't remember where I came across it but I think it was some guy in france that was doing it.
********************************************
Superstition is a word the ignorant use to describe their ignorance. -Sifu
Symantecs Visual Cafe... (Score:1)
Linux needs not just a Java compiler, but also a good IDE like Visual Cafe..
Syntax Highlighting (Score:1)
Symantecs Visual Cafe... Please release for Linux! (Score:1)
Just do your inital design with placeholder for functions, than use something like Source Navigator (from Cygnus) to look how it looks like in terms of the structure... It draws pretty trees and diagrams for Java pretty well. And when linked to EMACS for an editor with JDE it is grreat. Though a built in editor is good enough.
- just $150 for developers version...
Ha Ha (Score:1)
Huh ... multiple VM s ? (Score:1)
Why are you using multiple VMs when one VM with many threads will suffice ?
Starting up many VMs to handle stuff will consume lots of memory and CPU, don't do that.
TowerJ can do this (Score:1)
java class files to achive dynamic loading.
Very nifty stuff, and very fast java performance (check out the latest reviews on javaworld).
http://www.towerj.com
Oh , I see ! (Score:1)
You're free to solve the problem any way you want but , sheez , it's not that complicated to make the thing just one VM with many threads running.
And you've got no credentials (Score:2)
have any programming experience" without some good proof.
I object to the streams because they exist, not because they are forced on you. They provide some benefits, but they don't do things like set errno, they give you less information on file opening failures than their libc equivalents. The types of errors that you can catch are just fewer and less informative. That's my gripe with them. They're less powerfull. They do have some nice qualities, like easy overloading.
Speaking of which, overloading is a nice feature of C++.
My point, though, was that there are reasons to not like C++, and there are no great reasons that C++ is better than C. It has some niceties (the STL, operator overloading, declaring variables anywhere in a program, etc.), but none of them are necessities by any means.
So simple preference is a valid reason to choose a language when there are no clear significant advantages to either. obj1 = obj2 + obj3 is nicer than add(obj1, obj2, obj3), but not by all that much.
Btw, the word logical was probably a bad choice of words. I was trying to refer to the opposite of OO programming, which I guess might be better termed action oriented? What is a good way to describe a += b instead of a->add(b); (using a silly and never-going-to-be-used example).
Did someone just steel your girlfriend, btw? You sound awfully hot tempered for someone responding to a simple post on language choices that said that C++ is not the one true way.
Linux coders are biased against C++, that's why (Score:3)
And those try{} catch{} blocks just feel way too much like some sort of basic. I want to program, not play a game of baseball.
Part of it is also that most of the C++ OO programming that I've seen has made anything that it could find an object, which is the wrong way to go about things. I like OO programming in C better than in C++, partly, I think, because people are more likely to write the code that does the job most elegantly and not the code that does the job most abstractly/OOedly.
Of course, that has nothing to do with the language, but I have tended to dislike the way that people attack problems to attack them with an OO frame of mind rather than a logical frame of mind. This is just a generalization, btw, and I haven't seen all that much C++ code.
But the major thing about C rather than C++ is that C just doesn't have the "designed by theory" feel to it. Everything in C feels like it's been designed from experience and logic. That's why, I think, that it's been called portable assembly. Assembly tends to be elegant, efficient, and logical. Especially some of the RISC assembly languages.
C has that sort of feel to it. It has a minimalist appeal. C is quite convenient, as long as you're comfortable with computers, and while it has its faults, it doesn't really get in your way to do anything.
C++, by contrast, feels like it was designed with OO theory in mind. It has all sorts of contructs that just don't feel right on a computer. Like the public/protected/private declarations. That just feels like something that should be in a classroom, not a real programming language. Of course, that's a feeling, but it has its validity. public/protected/private isn't part of how a problem gets solved, it isn't part of the code, and it isn't something that helps the compiler figure out what you mean.
On the other hand, classes do offer some convenience for having OO functions inherently know what data they are operating on. But it is just a convenience. It's not much of a hardship to do object->data instead of data.
Anyhow, I haven't seen any really good reasons for prefering one language over the other. I get more of a feeling of leaner, faster code from C, but that might be erroneous, it's possible that if you don't really use certain features of C++, they're not put in there because they theoretically belong in there. I haven't really looked through the various C++ compilers.
But please don't disparage C so much. There's nothing that you can do in C++ that you can't do in C (that isn't syntactical in nature), and setting up your own object model generally means a few extra pointers that would be handled for you in C++. For those who like the feel of C better, there aren't really any compelling reasons to switch to C++.
C==vi, C++==emacs (the kitchen sink) (Score:3)
> If E and Gnome were written in intellegent C++,
> they might actually work.
Just like Netscape?
Oh, and in what sense doesn't E work? I can't remember it crashing on me since the 13.3 days, and I use it exclusively. Gnome is just a massive project that's growing at an incredible rate. To expect a project of gnome's magnitude to go from nothing to perfect in a year by volunteer developers is insane.
I'm not saying that C++ might not be more appropriate for them, but they're doing quite well as they are. So is Linux. And the gimp.
I never meant to imply that C++ isn't good, just that it isn't simply all-around better. And saying that you can compile C with a C++ compiler isn't an argument for using C++, it's not an argument for much of anything than it's fine to invoke g++ instead of gcc on a
Lacking a real clear general superiority, there's no reason to condemn those who like C over C++, or to regard them as inferior. Frankly, while I like C, my favorite language is perl. C feels closer to the CPU, and in that way I like it better, but there's nothing like Perl for elegance of design.
Linux coders are biased against C++, that's why (Score:3)
You're right that I'm a student, and haven't really been a part of large corporate projects. My experience is mostly on the small things that I've written, and on the larger projects that I've looked into by other people (part of why I love open source).
As far as streaming goes, the idea itself probably isn't a bad one, but from your description of it (and my meager experience of it) it's more a syntactical convenience, like perl's default scalar, than a feature that's hard to do in C.
As far as try/catch blocks, my problem isn't really with them, though I'm a bit dubious about your claim that they're much better than error codes, is the way that they're handled. With the standard stream IO objects, especially the file stream objects, they didn't have nearly as many exceptions that can be thrown as they should have, their errors were largely generic. "couldn't open file" type errors, not "too many file descriptors open" type errors. This is more a matter of implementation, though.
But try/catch blocks aren't particularly different than error codes, you flag and error and someone down the road picks up on it. With error codes, you often have the benefit of printf("%s\n", strerror(errno));, which saves a lot of debugging work.
As far as public/private, I've never been able to gather much of a benefit from that feature of the language that isn't something that should be built in anyhow. wouldn't:
#define private public
just get wrid of the language barriers to using private members?
In C, you can stick the private functions in a header file that you don't even distribute, which is more private than giving them out.
But information hiding sounds more like a matter of programmer discipline. You should, having inelligent and responsible programmers, be able to make a header file with
/* These are the general functions, use them */
...
/* These are the private functions which may change at any time without warning, don't use them. */
...
And achieve the same effect. Sure, there's nothing forcing someone to pay attention, but what's forcing someone not to do a #define trick, or just to rewrite the header file (using a local copy), etc.
Anyhow, my point was that not using C++ for everything is not necessarily a sign of incompetance. C++ doesn't offer any tremendous, clear advantages that make C the choice of idiots only. That was my only point. Every supposed benefit of C++ that has been pointed out, I've seen to be a benefit, but not as a major benefit. That is, not as the sort of benefit that you'd be an idiot to ignore. I'm not trying to start a holy war, just defend C as a viable language choice for many applications.
Btw, I wasn't arguing about OO design. That's often the way to go. But you can do OO design reasonably well in C.
It's good to work things out (Score:3)
Oh, and I'm not clueless. I didn't learn too much C++, we don't have the best CS teachers here, but I did learn some C++, enough to have some flavor of the language. I know C, I know perl while not being a master of it, I've done a little java programming, a touch of javascript, x86 and MIPS assembly, bash shell scripting (if that can really be counted as a language), and I'm probably forgetting something that I've tried. I plan to learn more languages, I'm interested in lisp, among others.
Anyhow, I don't mean to disparrage any language, as I said above. I just wanted to point out that there aren't any real grounds for saying that real programmers don't program in C, only throwbacks do. I think that we're essentially agreed.
This is too good to be true. (Score:3)
This means that Java is now a real language, just like Objective-C, Pascal, Fortran, or C. The FUD official stops now.
And I bet this means we'll be getting GTK+ and GNOME and ORBit bindings for Java/gjc soon... yes...
sun worship? (Score:2)
With all due respect, I agree with your second reason but have doubts concerning your first. If If I'm not mistaken, their official line on why they maintained that tight control was twofold: first, they wanted to protect Java from sabotage,as Microsoft tried to pull, and second, that their initial license agreements with vendors made loosening their control legally tricky.
Could they have prevented Microsoft from discrediting Java's "Write once, run anywhere" claims if their control had been any looser? Possibly. Was it feasible for them to give up some ground any faster than they did, or to simply have released the product under a more open license to begin with? Maybe they could have done that, too.
In general, however, I feel that Sun deserves more credit than they've received so far. Vendors such as IBM, IBM/Lotus, Oracle, Apple - in short, pretty much everyone but Microsoft and Compaq/Digital have had enormous input on the class specifications, for example. Some important parts even originated at one of those other companies. And Sun has released preliminary specs for public review and criticism; they've been extremely receptive to outside influence, and I guess the fact that they've been reserving the final word for themselves just doesn't bother me as much as it seems to bother you.
It goes without saying that they're simply acting out of their best business interests; those interests seem quite compatible at the moment with almost everyone but Microsoft. Most of all, they are very compatible with the self-interests of developers. The Java community license is possibly the best compromise between the free and proprietary worlds that I've seen so far.
I realize that many people feel there can be no compromise: the Qt flame wars demonstrated that quite clearly. But for developers who want to make a living developing, without doing so as consultants, scrutinizing the middle ground is absolutely essential.
Java has Multiple Inheritance (Score:2)
What else do you need?
(C++, the PL/I of the 90s
No pointers?? (Score:2)
ROTFL.
The operating systems for Burroughs large systems (B6700, etc), now Unisys A-series, are written in a variant of ALGOL utterly devoid of pointers.
(It does, however, have a predefined array called MEMORY. If you really need that level of access for your systems programming, add that to your JVM.)
Has Java Progressed wrt Generic Programming? (Score:2)
Any language that supports inheritance supports generic programming, if you do it right. You don't need templates for it, either.
I started using C++ back in cfront 1.1 days, before templates or multiple inheritance were part of the language. We just created a bunch of basic classes to inherit from.
It's good news... (Score:2)
In theory I agree, and that's fine for personal projects. In practise, however, I've seen (and occasionally had to maintain) far too much crappy C++ code (and other languages, certainly) written by programmers who weren't enough above average (and remember, 50% of programmers are below average) to use such features appropriately. On anything that needs to be reused, or maintained, its just not worth it. (The ultimate example of this is perhaps APL -- powerful, expressive language, wonderful for writing quick personal and powerful apps (I've even seen an email system written in APL), no fun to maintain.)
Having a programming language enforce what it considers good programming practice results in disasters like Ada, Pascal and Java.
Those "disasters" have proven spectacularly successful in the domain of large project development (well, Pascal less so, but it was designed as a teaching language) precisely because of that enforcement.
Has Java Progressed wrt Generic Programming? (Score:2)
Java2 has a new API that tries to rectify this though. The Collections Framework (or whatever the nom du jour is) provides some generic container classes, complete with algorithms ala STL.
The problem is it is Java still doesn't have templates. All the generic stuff is implemented with standard OO inheritance and polymorphism. That means that the nice compile time checking of C++ doesn't happen in Java; you have to make sure every Object you add to a List is really a Comparible Object or else Sort will choke at runtime.
Plus you can't have lists of anything except Objects. I know, I know, everything is an Object, but that means you can add a Thread to a list of Windows, for example. Unless you create a specialized class derived from List that only works with Windows.
In short, yes it has generic progamming of a sort. But it is still a lot less powerful than templates as implemented by C++.
Has Java Progressed wrt Generic Programming? (Score:2)
My real point is that C++ with templates binds everything at compile-time. If a type won't work with a particular algorithm, or you try to put the wrong type of object into a container, the program won't compile.
Java binds everything at compile time, and throws exceptions if something goes wrong. It will compile, and it might even run 99% of the time.
From a software engineering perspective, the first is much better because it catches that entire class of errors 100% of the time. They can't be caught all the time in the second situation without exhaustive testing.
Small projects that use a Vector here and a List there aren't going to have problems. But large projects that use generic programming exstensively are much better off with the static typing.
The whole argument is really the same as the argument between statically typed languages (C++, Java, Pascal, etc.) and untyped or dynamically typed languages (Lisp, Smalltalk, TCL, etc.), except on a higher level.
Using straight C (Score:2)
Also (with the possible exception of BeOS) many operating systems and their APIs have a decided "C-bias".
Syntax Highlighting (Score:2)