Java for EGCS
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 "
This is not a Just-In-Time compiler. The goal of the project is to produce a complete development tool set for compiling Java to native code just like you compile C to native code. I'm guessing Cygnus probably plans to market this to the embedded systems market as well as to the free software community.
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 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.
Frankly, C++ has its drawbacks too, like being more complex and further removed from the computer. C++ has a different feel to it. Bloated and Anal come to mind, but that's probably just partially from the way that it was tought to me. Possibly the other part is that I don't really trust any language that has those awful stream object. cin & cout are pathetic compared to their equivalents of printf and scanf.
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++.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I responded to the logical part in another post, but let me address that here, too. I didn't mean that OO programing wasn't logical, I was just trying to refer to the other paradigm of programing that isn't OO. Maybe it's action oriented programming? I used the silly example of a += b; rather than a->add(b); That was what I meant. I respect C++, btw, I didn't mean to imply otherwise. I just didn't phrase it well.
.c file. C++ seems like a good language, but it's not clearly better than C++.
:-)
> 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.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Thanks for the kind and informative reply.
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.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I wasn't trying to disparrage C++. It's a good language, and has benefits over straight C. My argument was just that if someone likes C better, they're not an idiot for using it over C++, even if C++ had some benefits. It's quite possible that the benefits aren't significant enough to outweigh personal preference or personal circumstance. Essentially that there's no one true language. I never meant to disparrage C++ as something inferior to C.
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.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
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...
--jon. Postel is dead. May we all mourn his, and our, loss.