Slashdot Mirror
How C# Was Made
prostoalex writes "Bruce Eckel (from the Thinking in C++/Java/Patterns/Enterprise Java fame) and Bill Venners have interviewed programming legend Anders Hejlsberg. After 13 years in Borland and joining Microsoft in 1996, Hejlsberg now leads the development of C# language and talks about the development process, reasons some things exist in C# and some not, as well as future directions."
I believe that was the mandate given Hejlsberg by Gates.
-- You see, there would be these conclusions that you could jump to
There a great interview with The father of C# here too,
Yep, it boggles my mind why people do this crap.
There is a pretty good interview on the .NET show on MSDN with Anders too. It runs about one hour, so get a comfy chair.
It's a scat site. Mod it to hell.
Joel Spolsky published a great article a while back on .Net, his company's strategy for the platform, and why Anders so damn cool. Also, just in case you're curious as to how his last name is pronounced, it's pronounced hells-burg.
iRooster, the Mac OS X a
...right here to save you a click thru the MSDN page.
The Army reading list
Sorry to disagree...
.NET is usable, but Java is something horrific.
Java is the worse crap SUN could have pulled. The whole of it, extending interfaces, illogic class naming, having to call a trillion classes to do something.
C# is much more like Python than Java...
how long until
Microsoft starts trying to tell people that "OO is soo... yeasterday. You want Indigo."
You're referring to Don Box, specifically, right? I don't think it's so much that Don is pooh-pooh'ing OOP in general, it's that he feels that a service-oriented architecture is better suited to the kind of problems we face today than DCOM or CORBA. His point is that trying to use an OOP metaphor for enormous, architecturally sound remote object invocation/data transfer systems is a terribly complex task.
Also, keep in mind that Don wrote *the* book on Microsoft's COM technology; OOP has its place, but CORBA and DCOM are not really the place.
iRooster, the Mac OS X a
They hit the black key to the right of C.
no, not yet. check back.. oh, never.
parent is a troll that calls anything insightful a link to goatse or tubgirl
It's a pretty long document, so it will take a while to read and put the proper spin on the story. Give it another hour or two.
So what exactly did C# to get made?
The owls are not what they seem
so whats the big deal about c# ,huh?
is it really useful for anything at all?
Why does yahoo do this
Unfortunately, I know that many instructors have also been confused into thinking that Microsoft is moving away from OOP. The result? "Oh, we'll only skim over the object-oriented portions of C++ in this class. Most of you will program for Windows, and Windows is moving away from Object-Oriented Programming."
*sigh*
If my answers frighten you, stop asking scary questions.
It's well known that the C# designers paid a lot of attention to Java, but more importantly, it's also quite clear that they also spent a lot of time paying attention to the experience of developing in Java.
So while I might not entirely agree with the uncaught exceptions or the way methods aren't virtual by default, I do think it would be a good idea for Sun to take the lesson from MS, and take what is best about C# and move it into Java.
C#. What's it all about? Is it good or is it whack?
It seems to me that big companies like Sun and Microsoft like pseudo-compiled languages like Java and those in
1) Pseudo-compiled languages are easily decompiled. If a small competitor writes an especially useful program, it is easy to see the logic by just decompiling the source code. In business programming, the business systems logic can be EXTREMELY complicated. It's easier to copy it from a competitor who has proven success. See these links for information about decompilation. Of course, the best methods of decompilation are not made public:
Java Decompilers
A friend wrote this:
"I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity.
"That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."
2) Pseudo-compiled languages are slower. That raises the cost of hardware. Sun makes most of its money from selling hardware. Slower software requires more expensive hardware. Microsoft makes most of its money selling operating systems. The customers most important to Microsoft are not you and I. Microsoft's important customers are the systems builders like Dell and HP. Systems builders want slow software so they can sell more hardware. Microsoft wants slow software so people buy more systems and therefore more operating systems licenses.
Holy fuck!!! This the is fucking gross! And the popups on the goddamned site even got past the pop-up blocker on Mozilla Firebird!
NT
Having used TP and DelpiI was kind of disappointed to see Anders join Microsoft a few years back. But now behold .... Delphi 8 adopts quite nicely to .net and is actually giving Borland a new lease on life and delivering where Kylix couldn't.
Having used both java and delphi I allways missed some sort of generics. I found Anders thoughts to be quite interesting. Question: is it possible to change the java generics-implementation in such a way that it would loose the limitations mentioned (and changing the JVM in the process offcourse)?
Bb is to the left.
I think you missed a couple of fairly critical points in your timeline.
-2. C++ is invented, adding a usable OOP layer onto Java.
-1. Dozens of interpreted, or semi-compiled languages (such as Visual Basic, which preceded Java) exist. Many of them are cross platform.
0. No one writes software for Sun, so they think up a plan to let people write software for Windows, while still allowing it to run on Sun. Java is the obvious result, and is basically the merging of -1 and -2, though Java fanboys will forever imagine that it was a wonderfully unique idea that appeared out of nowhere.
Also
4.5 Microsoft's implementation of Java absolutely stomps Sun's on the Microsoft platform. Microsoft implements additional platform specific extensions, as is allowed under the Java spec, to make it more usable on the Windows platform. Seeing point 0, this really pisses off Sun who yoinks their license back.
Actually, Java supports both checked and unchecked throwables: the latter with the class Error. My programming style is to make throws that I don't expect to be "routinely" caught throw Errors rather than Exceptions. An Error can still be caught, but since you don't expect it, you needn't declare it.
The checked exceptions are still useful for the case where it would probably be a bug not to handle the exception, e.g. "search found no element" or "file not found". The reason for the two kinds of throwables is exactly this: you don't want to declare that every method doing division throws DivideByZero. Unfortunately, the Java library designers don't seem to have gotten it, and so there's a bunch of things like IOException that IMHO should have been Errors.
(Yes, I know, the suit is against IBM. Please don't tell SCO...)
For fucks sake, man! Wake up and smell the marketing bullshit. The most innovative impressive thing about Java was that it was successfully marketed as basically the second coming (more tangibly as the solution to 10 different huge problems), all while just being another platform. Get it? They created their own platform without hardware leverage, OS leverage, app leverage, etc. It's bootstrapping by marketing.
C++ is invented, adding a usable OOP layer onto Java.
... Idiot. Fanboy.
Uh, yeah.
Visual Basic, which preceded Java
You mean "ruby"
they think up a plan to let people write software for Windows, while still allowing it to run on Sun
Java, which was called Oak originally, was created for small and embedded systems, such as set-top boxes.
The status bar foils your plot to get users to the tubgirl pic. Better luck next time. ;)
Oh, mother of...
Preview, damnit, preview!
"C++ is invented, adding a usable OOP layer onto C."
real enumerations, like C#
real attributes and program metadata, like C#
real foreach, like C#
generics, like the next version of C#
Face it, if C# borrows from Java, the next release of Java is a ripoff of C#.
This is my sig.
In many cases, pseudo-compiled languages, or languages that use a VM are a better choice. No worrying about memory management, buffer overflows, etc.
There will always be a place for C and C++ in places where you *NEED* low-level control over things like memory management, or where performance is very critical. But for most applications, this is simply not the case. You want a language that can do all you need it to do, and you don't want to worry about the rest of the details. Java and C#/.Net are the next big thing in commercial programming. But they certainly won't be the last. There will be another language that is better in 10 years from now. But right now it is a good thing that we have two choices, instead of one. Competition is a *good* thing.
Well, pseudo-compiled languages is hardly a "big company" thing. Look at Python for instance. It's all over the place (in the open source world).
I remember when legal used to mean lawful, now it means some kind of loophole. - Leo Kessler
I think the old adage needs to be updated: If you want to eat sausage, obey the laws, and use C#, you should never watch them being made.
...
Another one? But I haven't finished Brockschmidt yet! :)
One line blog. I hear that they're called Twitters now.
> it is easy to see the logic by just
> decompiling the source code.
You mean bytecode, probably.
> the business systems logic can be
> EXTREMELY complicated
If it's that complicated, having a bunch of decompiled source code is not going to be that useful. You're better off programming it yourself so you understand it and can change it when you need to.
> Pseudo-compiled languages are slower.
But not _much_ slower. A $3K dual CPU Linux server can serve up a lot of Tomcat hits. Need more? Buy a load-balancer and a few more servers. Not a big deal.
The Army reading list
4 bats
2 mole eyes
25 spider eggs
6 left arms from virgins
1 ripped of letter from another language
That's the biggest FUD I have seem so far. Your talking about "pseudocompiled" makes me think you don't know how either language really works.
OTOH I agree that both are relative simple to decompile.
The speed will depend of your particular use, but in some cases programs in Java are faster than C programs.
"I think this line is mostly filler"
why trust your development to a language designed to lock you in to Windows? C#, for all its niceities is just a way of getting you to buy more Windows 2003 Server licenses.
Your 4.5 is wrong, and even in a world in which it made sense, it'd still be wrong. Sun's whole marketing mantra around Java was "Write Once. Run Anywhere." Allowing platform-specific extensions would break that, so it's an obvious non-starter. Sun's reaction wasn't correct, but it was an allowable one.
Uh, yeah.
... Idiot. Fanboy.
.NET "borrows" many ideas from Java, but it's absurd to paint Java as an amazing new development that invented these concepts (just as it's equally absurd to claim that Macs invented the GUI, though that's an entirely different debate).
I apologize profusely for that typo, though it was fairly obvious.
You mean "ruby"
Err, no I mean exactly what I said, which is that there was dozens of interpreted or quazi-compiled languages before Java. It's a neat concept and a good implementation, but it certainly wasn't revolutionary.
Java, which was called Oak originally, was created for small and embedded systems, such as set-top boxes.
Obviously I was being a bit facetious given the original flamebait troll. There is no doubt whatsoever that
What's this now? OSNews?
Talk about slow days...
And yet, open source is even EASIER to read, and MS isn't real keen on that. If they're going to do something somewhat unethical, you'd figure they'd like to get comments along with it.
And gee, yes, Pseudo-compiled languages are generally slower, and yet often less prone to memory problems, and more portable, and oh wait, I'm responding to dork conspiracy nut who got modded up to +3 by a bunch of other people who the more and more I read about their anger with MS, the more I think it has a good deal to do with jealousy that they didn't get to apply the screws first and make the big billions.
.NET is usable, but Java is something horrific.
.NET-bashers never get modded down but anyone who dislikes Java goes to karma hell, LOL...
I wonder why
Gonna burn some karma on this...
;) And yes, I am just teasing.
Gandalf: This is C#. Forged by the Dark Lord and his engineers in the fires of Mount Redmond. Taken by him from the hand of evil himself. All who use it are bound to him. Gates needs only this ring to cover all the lands of a second darkness... He is seeking it, seeking it; all his thought is bent on it.
Frodo: Alright, we put it away. We keep it hidden. We never speak of it again... No one knows its here, do they? Do they, Gandalf?
Gandalf: Unfortunately, yes. The power of Gates is far reaching. The innocent would use C# from a desire to do good, but through them, it would wield a power too great and terrible to imagine.
You get the idea...
*-*-*-*-*-*-*-*
"We are Linux. Resistance is measured in Ohms."
I didn't get any pop-ups (I'm running Linux Firebird 0.7), but it did move the entire browser window around. Kinda cool but that should definately not be allowed.
What does homosecuality have to do with scat?
Moron
You just bought a bunch of hardware; you just proved his point.
But thats not necessaraly a bad thing. Its a trade off. Hardware is cheap. Throwing hardware at the problem is very often the cheapest solution.
I'll try to utilize this wonderful slashbot-clickwank in the future. My hats off to you.
When I started at Microsoft in June 2000, at the PDC that month they announced "NGWS" - Next Generation Windows Services, originally internall called "Cool". In fact the first time I saw the source code for the .NET Framework class library all the .cs files were named .cool files.
.NET is the Windows-specific java work that Microsoft was working on that Sun sued them over! When they got sued they just named it C# instead of Java!
Windows Forms was originally WFC (Java AFC extensions). Get it! All
Now does it make sense?
> You just bought a bunch of hardware;
> you just proved his point.
Not really; his point was that I'd buy a $60K E6500, my point was that I'd buy a couple of $3K pizza boxes.
> Throwing hardware at the problem is very
> often the cheapest solution
Yup, and if you can cut your development time down by using Java vs C, everyone's happy.
The Army reading list
I think on many issues, Hejlsberg is missing the point and the reasons he gives aren't necessarily the actual reasons why particular design tradeoffs are good ones.
.NET) may turn out to be the free and open language that Java should have been; time will tell.
But it really doesn't matter. The changes that C# made relative to Java are obvious and proven (e.g., value classes, removal of statically checked exception declarations, declared unsafe code sections). Many of them had made Sun's bug parade. All of them had been in other languages before either Java or C#. In fact, C# is, in many ways, close to Modula-3.
There seems to be another reason for some of the design decisions: patents. Sun has patents on several aspects of the JVM and Java, and if Microsoft wanted to be free of potential future claims by Sun, they had to avoid those in their own competing virtual machine.
Keep in mind that Hejlsberg is also a salesperson for the language anyway. That means that he may not be telling you the real reasons behind design decisions, but the reasons that sell the language well.
In any case, however it came into existence, C# is a somewhat better language than Java, and we should be happy about that: whether you are planning on using C# or not, it raises the bar for what is considered standard in industry. Without C#, Sun probably wouldn't even have made the largely cosmetic changes they made to Java in 1.5, and maybe the continued existence of C# will force them to fix other misfeatures of Java and the JVM in future versions. And C# (but not
Hi! Thanks for the corroboration! Malakai will be by later to give you your tin-foil hat and foil polish, and perform the indoctrination ritual.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
1) Pseudo-compiled languages are easily decompiled.
Um, compiled languages are easily decompiled as well.
http://hte.sf.net is a badass hexeditor/disassembler.
Case in point, I walked through the assembly of iTunes to figure out the AES key that iTunes uses for iTMS. And iTunes was written in C++.
Java took good stuff from C++ in order to make the language easy to adopt. Easy for experienced C++ programmers to start running with.
C# seems to be about salvaging the effort put into J++, which was about fragmenting Java. And likely about that same cause as far as is possible within the bounds possible.
The difference is in the intent.
emt 377 emt 4
But say it was. Who cares? Every language is based to some extent on what came before it. The question is, does it improve on other languages? Does it have a niche that it serves better than other options?
In this case, the answer is yes. Java is horrible kludgy in a lot of ways, and yes, it's horribly slow for large applications (although, small benchmarks can hide it's slowness). And no, I don't want to debate yet again the merits of Java. I think it sucks. If you think otherwise, more power to you. I'm glad it works for you.
Sometimes it's best to just let stupid people be stupid.
Hey, dumbshit, I worked there. A ten-year veteran told me the planning for .NET began in 1996 -- that's when A.H. was hired, anyway. I had read-only access to the source. I'm right.
it's pronounced 'Hile-spare'
(from Copenhagen, Denmark - where Anders went to university)
I'm always wary of giving credit to someone proclaiming the Next Great Thing, when they've spent the last several years as a leading advocate of the Previous Great Thing, then suddenly start finding all these previously overlooked drawbacks in the older technology when the newer one arrives. Don Box seems awfully close to that position right now.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yes, yes, exactly. Might makes right.
Yep it do, dont it.
- George W. Bush.
I know you are. I wasn't poking fun at you. Re-read my reply. I appreciate your posting.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
This guy is a tinfoil hat retard pushing his paranoid agenda supported by a revisionist history. Ignore him as he deserves.
Thanks
most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...).
:-))
Each tiny crappy component, each crappy lib for C# out there on the net is sold, and sometimes for outrageous prices (a month ago seached for a plugin to generate properties from variables - something like getter/setter generator macros, so common in most Java IDEs - found it for 100$ per seat! OMG!). there is no idea of sharing, neither the source nor experience, and this IMHO will be the main cause of C# setback.
And oh, most computer literate people pronouce '#' as 'hash', not 'sharp'
Yes, easily turned into assembly language, but it is much harder to decide what the assembly language is doing than with pseudo-compiled byte code that is a collection of obvious calls to the run-time library.
The truth is - existing software quality sucks. There are a few exceptions, but there are too many poor quality products being shipped everyday sometimes costing millions of dollars. The fault is seldom with the tools or the language of choice.
There are so many parts of the whole software development process that needs to be improved. With the right process, people and management it is possible to make great software regardless of the language.
When automobile engineers argue, do they argue about the quality of their cars, their features and design or do they childishly bicker about which wrench is better?
All your favorite sites in one place!
I don't think J++ was ever really about fragmenting Java, it was rather about using it in the way they wanted to. Obviously, they weren't really concerned by any portability issues but I don't get the impression that they were out to fuck Java up.
Sun's reaction wasn't correct, but it was an allowable one.
And MS reaction was just as allowable - take all the work they did on win32 and COM interop and port it to their on runtime so Sun can go f*ck themselves.
This project is how C# should be.
One thing I've never seen explained in any of the designer interviews on C# or Java is why they both have the redundant 'new' keyword.
Neither language allows you to create objects on the stack, so using new to denote 'on the heap' is completely redundant.
Also, why can't language designers take hints from the *productive* languages as well as the *popular* ones.
I'm not saying that good programming is a speed typing contest, but modern, popular languages require far too many key presses to get stuff done.
C#/Java
Type varName = new Type(args);
Python:
varName = Type(args)
Want static typing? Why not type inference like OCaml?
Damn them.
no not flamebait, and honest opinion from someone who has used the product.
Sheesh, who gave Bill Gates mod points?
The Kruger Dunning explains most post on
C++ is the opposite. In C++, you can do anything you damn well please on a variable of a type parameter type. But then once you instantiate it, it may not work, and you'll get some cryptic error messages. For example, if you have a type parameter T, and variables x and y of type T, and you say x + y, well you had better have an operator+ defined for + of two Ts, or you'll get some cryptic error message. So in a sense, C++ templates are actually untyped, or loosely typed. Whereas C# generics are strongly typed.
// . . .
I disagree with that assessment. Both C# and C++ generics/templates are strongly typed. It's just that the enforcement happens in different places.
In C++, if you try to stick a class into a templated class when that class doesn't have a particular member function defined, the compiler will yell at you, just like Hejlsberg said. But for some reason, this doesn't count as type checking? Yes, template error messages can be strange (and very long) if you're not familiar with them. But that's just a lesson in "know your tools."
To me, "strongly typed" is strict type enforcement at compile time. C++ templates certainly do this.
Constraints, however, are something that I think are a generally good idea. Stroustrup's reasoning for not including them in C++ was that "Requiring the user to provide such information decreases the flexibility of the parameterization facility without easing the implementation or increasing the safety of the facility." (The Design and Evolution of C++, Stroustrup, 343).
He does, however, show an interesting way to get around this using inheritance:
template <class T>
class Comparable {
T& operator=(const T&);
int operator==(const T&, const T&);
int operator<=(const T&, constT&);
int operator<(const T&, const T&);
};
template <class T : Comparable>
class vector {
};
(The D&E of C++, Stroustrup, 344)
This technique is similar to how C# does constraints, class List where T: IComparable. One is supported and enforced by the language, the other is a natural consequence of the languages facilities. In general, I think that constraints are probably a good thing. Having an error message like "Can not instantiate class Y<T> because T does not implement z()" is probably best, and when looking at a class' declaration, it would be nice to see up front what assumptions the templated class makes.
Drop it in the hot java!
But not _much_ slower.
Says the person with the dual CPU server. From the first day of Java, the proselytizers kept telling me to get faster hardware and wait for the next version. I now have hardware 30 times faster, and four major versions later, and Java STILL crawls on my system. Even purely interpreted languages like Python and Ruby are faster!
Don't blame me, I didn't vote for either of them!
Its not pronounced Coctothorpe ?!??!!
I actually think coctothorpe sounds
appropriate for some reason.
There is history before java that matters too; Such as Microsoft had its own processor independant P-Code compiler nearly a decade before java, but kept it private probably as a competitive advantage. This is a cold irony.
Microsoft was worried about java even before it became popular; for the simple reason that if a portable internet language did become popular, it would obviate the need for windows.
Microsoft did not get their hat handed to them when they attempted to co-opt java: seems to have worked nicely.
.NET has a lot of strengths and I think people dismiss them. The problem with .NET is its windows only support. The mono project and dotGnu don't count. They both suck. I tried to get mono to run on freebsd.. although there is a port, i couldn't get the thing to work with apache for anything. .NET is so much easier to do web development with. I may have to return to the evil microsoft realm because even with patching windows everyday it saves me a LOT of time using .NET wheither it is C#, VB.NET whatever.
.NET in OSX and FreeBSD but not a lame open source attempt. No one even ported VB! Come on!
Java is wordy and the Servlet/JSP system sucks. It takes too long to do anything because you are worrying about low level crap. I often forget to do decent data validation because i'm worrying about dum stuff. I actually wrote a message board in C faster than in java simply because i didn't have to screw with tomcat for a year.
A IIS/.NET solution is much quicker than an Apache httpd/Tomcat/JSP/SERVLET/AXIS/insert your favorite web framework here setup.
closed source sucks because of portability, and open source sucks because 2 guys make money off of you coding (like redhat) and another guy writes a book about your work. Its a lose, lose situation.
I'd kill for something like
In your example, I know with complete certainty that I am creating a new "Type" and assigning it to the variable "varName". This is not the case if it used the syntax of Python. How do you know I am not calling a method called "Type"?
Scott
Well, if you're a Java programmer worth your salt, you DON'T propagate every exception class the underlying modules might want to throw. You make your code catch exceptions rising from below and either handle them or massage them into the exception set your module exports. This is much better for the upper-level users because they want to deal only with situations raised by, and meaningful for, the APIs at hand, and they don't have to care about what would brew beneath.
If you don't want to lose exception stack information, as of J2SE 1.4, you can chain an original exception to your higher-level exception, so that everything would be rolled down nicely in a trace printout.
My exception safety is -fno-exceptions.
I guess you've not heard of gcj, TowerJ or the other traditional ahead-of-time compilers for Java, eh?
Java is not necessarily a VM based language - that's not to say that VMs aren't useful in lots of situations. Obfuscators also often work well. Of course, if you're doing server-side code, decompilation isn't an issue at all...
Nice straw man though... ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Got it on. The resulting santorum became known as C#
"Orthodoxy means not thinking--not needing to think. Orthodoxy is unconsciousness." --Eric Blair
Answer: To beat Java.
C# wasn't made to beat Java.
J# is.
Beware: In C++, your friends can see your privates!
That is why you use obsfucation programs. They can decompile all they want, they won't understand anything.
Uh, the fact that you push shit around with your dick?
Moron
Damn, three whole hours--it was 3:34pm when AC posted it here and 6:51pm when Slashdot put it on the site. sssssssssssssssssssssssssssssssspin
You should be much more careful with 'nobody' word.
As my first-hand experience I can say that we use Java for both server and client side for corporate software and yes, it's downloadable application. Excellent solution if you ask me, trivial to update, secure, portable and very nice environment for developers too.
Server-side makes no difference for commercial products. The competitor merely buys a copy.
The compilers are not true compilers, as far as I know. They compile to byte code.
Just so you know, disassemble != decompile. It's not so easy to decompile assembly back into C/C++, so make a relevant comparison.
13. And even with all the vitriolic hate for MSFT and its evil business practices it was the Open Source Community which eventually drove SUNW out of business.
You got modded down by the old-timer assembly-hackers who thrive on goto ;)
It boggles my mind that some people *do* crap. But we gotta tolerate those homos. Excellent lobbying and SIG power, for sure.
AIUI, the major reason many of the big names in C++ don't like language-supported constraints on type parameters is that just having "derives from this base class" isn't a sufficiently general condition for good support of generic programming.
C++ enforces any necessary interfaces at compile-time, by checking whether the instantiation of a function template can be interpreted properly with the functions available. Requiring every class that supports == to derive from EqualityComparable is just a cumbersome extra for no benefit in a generic, C++ based world, where there are more ways to define and implement interfaces than just inheritance. If it doesn't support ==, the function template will fail to compile at the point of instantiation anyway. (OK, strictly speaking export messes up the compile-time/link-time distinction slightly, but the basic point is still valid.)
Incidentally, it is possible to use template wizardry in C++ to enforce various plausible constraints on type parameters if you really want to restrict them more than their usage within the function template does anyway, perhaps to guard against a possible misinterpretation of the template code in some cases. It's relatively straightforward to do this, and requires little more code than the formal constraints used by some of the other languages under discussion.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
What you say is certainly true up to a point: the highest level code in a particular subsystem, right behind its interface, should indeed define any exceptions it's going to allow out of the subsystem as part of that interface. If there is language-level support for enforcing that definition, it probably makes sense to use it.
However, within the subsystem itself, you often don't want to be translating exceptions at every layer. To do so defeats one of the major advantages of exceptions: you can throw an exception up through several layers at once to a handler, and intervening layers don't have to care unless they're taking some action to handle (or part-handle) the particular exception you threw. In that environment, you could easily wind up with many possible exceptions being thrown from different contexts, but handled in a small number of places. Even with inhertiance and catching groups of related exceptions at once to keep the complexity down, having to give a full specification for everything would soon become unwieldy.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
but in some cases programs in Java are faster than C programs
And which cases are that ? from the moment a Java program uses casts (that is, every Java program), it's by definition slower than the equivalent C/C++ program). A Java cast is like the operator 'dynamic_cast' in C++. Imagine a C++ program full of dynamic casts!!!
I don't think languages play any role. What is important is portability and the ready-to-use libraries. For example, I know many programmers who use C++ and QT who are as productive as the Java ones. I wrote the last couple of days a 5000 kloc program in Qt, with various forms etc.
You know what is missing from Java ? a decent callback mechanism. The observer-listener classes just don't cut it. I've seen many times for programmers to implement dispatch tables and choosing dynamically which method to call. On the contrary, C# has delegates...a much better mechanism. Of course, nothing beats Qt's signals and slots: it's the ultimate way to write reliable component software.
Another point I would like to make is that it's funny that it took them 4 years to design C#. That's a lot of time, don't you think ? any competent C++ programmer will tell you C++ deficiencies right away. Why did it took them 4 years ? I have tried to design my own language as a pet exercise and it took me 1 week from C++ to C#.
In this way I can avoid handling most exceptions when I don't really know how. Certain APIs constrains the exceptions you may throw (for example EJBException only), in which case I have to do some chaining. Catching exceptions without doing anything, or with only a stacktrace, seriously hampers debugging, so I never do that.
I think C#'s approach, where every method implicitly "throws Exception", is practical in most cases. Catching exceptions when I do not really want to is both cumbersome and dirty, and declaring "throws Exception" in every method looks a bit funny.
I wonder how he dealt with the political climate that surrounded this. I mean, first J++, a dead-end language that would be used to corner Java programmers into Microsoft's plans, then C#, the next step in "embrace and extend."
- rabs
Quoting from the GCJ web site: "Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications."
Anything with a runtime library like GCJ's is easily decompiled. That's because the code largely consists of calls to the library.
Another thing: I understand that people who visit Slashdot sometimes have less than the normal social sophistication. But it is possible to learn. The first step in learning is to avoid attacking the other person when you disagree.
I have expressed a reasonable opinion, I think. However, in this thread I've been called a "dork conspiracy nut" and you said, "You obviously know nothing about the subject", when you obviously didn't visit the GCJ web site and read the second paragraph.
There is a VERY important issue here: The business logic of even something as simple as an e-commerce web site is very, very complex. There nothing difficult about it, but it is detailed and complex. The underlying issue is that it is extremely easy to discover all the steps by de-compiling a business application. There's no complex math. There's no complicated understanding required. It is much easier to de-compile than to invent all the steps yourself.
Microsoft's license agreement for its compilers specifically prevents its customers from competing with Microsoft. How's that for an anti-trust violation? Big companies are VERY aware of this issue. They cripple the competition any way they can; that's their mentally disturbed idea of how to live their lives. There's no conspiracy; that's just the way they do business.
I'm taking my time to give my opinion because giving it could make a difference. We should all realize that C# is just another distraction from working to get the language that we all really need. C# has nice features, but someone should express some ideas that show that the success is very limited. The designer of C# is just a cog in the adversarial business machine.
J++ really is .NET Version 0.9, and it is pretty slick -- it does everything Visual Basic does, but you are using Java. Never succeeded in the market: VB types weren't interested and Java types didn't want to be polluted by it.
I think the sticking point was that if Microsoft walled off its J++ Windows-specific extensions in the microsoft.com.whatever JAR files, everything would have been cool. But Microsoft was accused of monkeying with the System.lang.java stuff and some other hacks that broke Java as crossplatform -- stuff reminiscent of Windows 3.1 checking to see if it was being launched from DR-DOS and the like. Was there also some non-JNI compatible native hookup as well?
Knowing Microsoft, they were up to their old tricks, and J++ as a Visual Basic clone wasn't what the fight was about. Heck, SWT is not portable Java in the way SUN defines it, but apart from SUN's moaning and groaning about it, SWT is perfectly conformant with what you are allowed to do with Java and be square with the license agreements.
I think Microsoft got off better in the popular press (SUN wanted Microsoft to implement Java, Microsoft implemented Java and even improved it (!), and now SUN is complaining -- what is the matter with those SUN dudes?). But I believe that Microsoft was really f-ing with SUN and SUN had a leg to stand on.
Where SUN was stupid is that they told the world that Java was about breaking Microsoft dominance before they were really in a position to rule the world, and what were they thinking that they could be in partnership with Microsoft in bringing Java to Windows without Microsoft trying to ream them just like everyone else? But the ideas that SUN is a bunch of crybabies who can't decide if they want Microsoft to put Java on Windows or not is more Microsoft having better PR than the reality on the ground.
SUN is for real a "victim of a crime", and going consensually into that hotel room didn't make what happened next less of a crime, but people are saying what were they thinking when they entered that hotel room.
His point is that trying to use an OOP metaphor for enormous, architecturally sound remote object invocation/data transfer systems is a terribly complex task.
Toss OO for such. Procedural with database transactions will be simpler. There is no objective evidence that it is worse or scales less.
His arguments regarding scalability and versionability are specious and basicall amount to "some coders misuse the feature". Checked exceptions should only be thrown when the exception should be caught. Thrown an unchecked exception if it doesn't matter it gets caught.
Hejlsberg talks, in the distributed objects section, about the importance of letting coders choose whether use distributed objects (by forcing the code to be distributed or not, but not both as in Java). But he won't let us choose whether to use checked exceptions since C# doesn't support them at all. Methinks he's marketing C# rather than explaining it. Can't he just say "we hope to catch Java's level of feature maturity soon"? I'd give his arguments more credence if he did.
from the moment a Java program uses casts (that is, every Java program), it's by definition slower than the equivalent C/C++ program)
May be you mean that a cast in cast is slower that a cast in C??
Don't let reality disturb you but just with a little googling you can find some article with facts about Java speed and how could it be faster than C.
Imagine a C++ program full of dynamic casts!!!
I can't. I also can't imagine a Java program full of casts. Most I have seen or written have only a few casts.
I know many programmers who use C++ and QT who are as productive as the Java ones.
A programmer could be productive in any language. When talking about language productivity I usually assume it's refered to a general case, in some context. Example: I believe most programmers are more productive in Java for database enterprise apps than in Oracle PRO/C (Yuck!). Also the Java database programs are more portable and independent of the DB.
any competent C++ programmer will tell you C++ deficiencies right away
Not always. Some C++ programmer have their C++ hats down to the waist making them virtually (:-) blind to other languages features. By example take STL, which many believe is an end in itself when it should be a means.
"I think this line is mostly filler"
Compiling down to native assembler ops (like C/C++ is) really mangles your code. Even very basic optimizations will result in drastically different source. Hell, Java bytecode to Java decompilation sometimes has no resemblance.
"Hot lesbian witches! It's fucking genius!"
Last month, Mr. Spolsky noted he had acquired a more nuanced point of view about when to develop in C#. Still, as your link notes, he thought it was the thing to do in April aught-two.
Goddamn you are a fuckwit. GCJ can compile to native machine code you idiot (it uses the gcc backend as it is merely a frontend just like the cp frontend).
libgcj is compiled to machine code but has the capability to interpret bytecode in the case that you want to use bytecode class files.
Using gcj and libgcj it is possible to compile a completely native machine code application.
Anyway this is not a matter of opinion, it is an issue of fact. Your opinions have no bearing on the actual capabilities of gcj.
You obviously don't have the background to understand what gcj is.
Now we only need for Anders to write an article explaining why Spolsky is such a jackass...
Linus uses goto within the kernel. And C# only allows goto as a means of explicitly marking switch-case statement fall through. Nothing else.
All stole from smalltalk and c, its c's syntax with smalltalk's concepts.. Java: smalltalk in the form of c++, with parts of object hiearchy located in libraries, with the added problem of deprecation of object classes which keeps developers on their toes. C++: like java only compileable, and just as indecisive about the structure.. c: a form of assembly that evolved into higher forms of expression through clever syntax.. Smalltalk: higher concept and form of design, based on objects and the development of applciations by the usage and inheritance of object classes, but to share applications, due to the dependence on underlying object classes, one must deliver all underlying objects that the application depends on, resulting in usually copying the entire smalltalk system (this is like, if we wanted to get a copy of Emacs, we need to get Lisp as well, or if we want IE we need Windows as well). C#: who knows, looks like its massively dependent on another architecture, that being .NET .. The grand being that programs will be based on disparate objects across the world, or alternatively all at Microsoft where they can suck the wallets of everyone dynamically: I'm sorry, you can't use MSWord today, the text object was deprecated last night, to use Word you will have to upgrade, that will cost you 250,000 dollars..
Of course this is a pipe dream for Bill Gates..
But.. Eventually it will be true..
PS- Javascript is not a Java language, it was a name stollen by Netscape to attribute value ro their browser language. I would expect that C# stole C in the name to attribute glory to it from the C world.. Microsoft is forever changign the language and stealing names, this is what they are good at.
Just say no to license servers!!
That's what enemas are for.
most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...)
.NET components. .NET and C# are two entirely different things. There is a lot of open source C# software out there (check go-mono.com).
.NET APIs implemented, and, additionally already has a complete set of open source toolkits and libraries, with APIs that, unlike the Java stuff, are already familiar to existing open source programmers.
It is true that there is more open source server-side web stuff for Java than there is for C#. But, against that, you have to hold that C# actually has a full-featured, high-performance, compatible open source implementation. Also, you can get a full-featured, open-source, widely-used GUI toolkit for C#, namely Gtk#.
And all that open source Java stuff doesn't really matter as long as Sun owns key parts of the platform (e.g., the Swing implementation). Yes, you can exchange open source Java libraries all you want, but Sun has ultimate control.
Each tiny crappy component, each crappy lib for C# out there on the net is sold,
No, it isn't. You are thinking
What you should really be asking if you are interested in open source is: if I only use open source tools, how do the two software platforms compare? And if you only use open source tools, Java looks like a pretty sad platform: you can choose between Kaffe, orp, and gcj as runtimes, but none of them are anywhere near complete and most open source Java libraries don't run on them. You can't even get a working open source Swing implementation. In comparison, C# is much further along: Mono has a lot of the
I remember the scores of Chicken Littles that came out of the woodwork when Anders got 'fished' from Borland. Regardless, under the hands of Chuck J and others, it still went along swimmingly.
It's actually pretty interesting the ties between some parts of Borland and Microsoft's .NET team. (I was at BorCon a couple of years back when Anders did a keynote speech, and did demonstrations of ASP.NET... using Delphi 7's .NET Preview Compiler to very good effect.) They've had to face a number of the same challenges. .NET actually has to approach the Windows API in the same manner as many decent class libraries have (glad to see that the .NET framework is miles away from the spaghetti vomitus of MFC, likely in part an Anders influence). Borland had to work around the idiosyncracies of the Windows rich-text APIs in making their TRichText control. Such experiences are valuable. In return, Borland gets some excellent heads-ups on the technology.
I've had a chance to use Delphi 8/for .NET, and I must say that Danny Thorpe, Corbin Dunn et al have done a marvellous job in making porting to .NET easy. Compared to porting to Kylix/CLX (which 'everyone wanted', but nobody would pay for - *laugh*), porting to .NET was a breeze. I even ported DUnit across while I was at it :)
As to missing generics, I, too, missed some sort of generics. I loved Ada's model for generics, loathed the way most C++ compilers handled templates (more specifically at the time, how they handled errors and tracing :), although I got good mileage out of them.
I have an implementation of Rossen Assenov's generics for Delphi (using a trick similar to that in C++ before the 2.1 standard) here on my web page. A few limitations (which you can get around if you're not averse to 2-layer-deep includes :), but works like an absolute charm, and it does still work in Delphi for .NET (though you will have to ensure you aren't using pointers in your list classes if you want to be managed-code compliant :).
Binary geeks can count to 1,023 on their fingers
You apparently view software systems as being composed of "upper-level users" and "what is beneath". That's a very procedural world-view. In a procedural world-view, Java's exception handling makes sense.
But for object-oriented programming styles, things don't work that way. In an object-oriented style, when we have method P calling method Q calling method R, then method P may know exactly what exceptions method R may throw, but method Q may be from a completely different library and should not have to know or care about exceptions that propagate from R to P.
Declared exceptions in Java are a testament to procedural thinking; they show that a lot of Java programmers pay lip service to OOP but still just program like they were writing FORTRAN programs.
Obfuscation does nothing but keep casual viewers out. Sooner or later the code must be executed. A record of the execution can be decompiled, such as with an in-circuit emulator or software CPU emulator. In cases where there is a lot of business logic, such as in an e-commerce web site, it is extremely valuable to see how a successful competitor solved all the tricky, quirky problems of making e-commerce easy for visitors.
Wasn't it just done by covering one of the holes and blowing down the tube?
Have you ever designed a moderately complex system?
On the scale of individual classes, yes, I be as OOP-minded as the next guy. But dealing with hundreds of classes requires separating functionally different parts of your program to subsystems, with reduced and well-defined coupling between them. This hasn't changed since the days of procedural programming. Except, with careful use of new tricks like exceptions (pun intended), you can define it better.
My exception safety is -fno-exceptions.
In your example, the error conditions that may cause method Q to fail should be part of Q's contract. Whether it is implemented in terms of P or not, it still has certain failure modes that may need to be handled differently by its caller. This is part of what you need to know to call that method correctly. Whether or not Q is implemented in terms of P is irrelevant. What matters is that Q's INTERFACE needs to be able to report certain kinds of exceptions.
Go read the post by aziraphale a couple of ones above this one. He lays it out pretty well. (I'd give him mod points if I could.)
In general, you shouldn't be propagating implementation-specific exceptions to your callers unless they are guaranteed to be essentially indistinguishable "failure" reports (and thus OK to make unchecked). The only exceptions you should be propagating in a checked fashion are interface-specific ones that explain what is happening in terms of the interface, not in terms of how the interface is implemented. It is perfectly reasonable to make those exceptions checked exceptions.
If I create a getTheWidget() method, it is quite reasonable to have it throw a WidgetNotAvailableException. I shouldn't be having it throw a FileNotFoundException that the caller is expected to know about and trap (and thus treat differently from other runtime exceptions that might also be thrown). If the widget is truly not available because a file could not be found, and I can't treat this as a fatal the-program-is-over kind of exception, then the right thing to do is throw a WidgetNotAvailableException. (There might be a FileNotFoundException wrapped inside, for use in debugging. JDK 1.4 and up provides a standard way to do this.) That way, the caller does not need to know the specifics of WHY the widget was not available. It only needs to know that this was the case, so it can handle that case differently than, say, WidgetIsDamagedException.
Unfortunately, I have met relatively few Java programmers who are aware of this design choice in the language, and misuse of exceptions is fairly rampant. I wish Sun would publish more how-to articles on this kind of design issue.
I agree completely. Well said. Not enough Java programmers (or C++ programmers, for that matter) understand this.
My property macro for VS.NET is located here:6 1153.aspx#61172 :)
http://weblogs.asp.net/cnagel/archive/2004/01/21/
I tried to paste it here, but the filters won't let me
Never underestimate the relief of true separation of Religion and State.
If you remember what happened a while ago, the story goes: Microsoft was facing competition from Borland, so they hired away all their lead developers to break the company's neck.
It almost worked.
PS: Don't use anything that has a '#' in it and isn't music!
C# sucks so bad dude its like VB.
I love Java and Linux
I have to agree with the parent. IT's Sunday here now, and I spent the better half of Saturday night trying to hack this IBM Host on Demand 4 Java client (5250 emulator, through ssl) to connect to my remote system. couldn't get it to go for a number of reasons:
1) it's a very old app (our corporate offices won't upgrade) so it highlights the changes in the language over the years that haven't been compatible- so you try old JREs and whatnot to no avail, due to most modern browsers not handling THOSE right
2) once I finally got it running, it didn't want to connect to an SSL socket- i think it's a deeper error than not just connecting, like it couldn't decode some of its messages that it got FROm the socket.
Once i saw this, i started using a debug library to get at the HTTPS stream and holy crap this thing is just simple terminal emulation over an arbitrary SSL port.
five minutes later i've got stunnel fwd'ing it to a local port, and tn5250 connecting to that.
I freaking hate java.
"We have a wiki now on the internal web with the issues list, resolutions for them, and so on."
So MS does use open source projects! In supporting the development of their own closed source product! Ha! Open Source wins!
What time is it/will be over there? Check with my iPhone app!
These are sweet days.
This is my sig.
The parent is the most wacko conspiracy theory I've read on Slashdot in about 2 years. Please someone, mod it "Funny"...
Amazing magic tricks
I found this particular statement from Anders insightful. Just because he and his peers are not aware of CORBA systems scaling to geo-scale, they assume it can't. Although anders and his co-workers are experts in language design and building compilers, they are obvious detached from the world of application development. The requirements of application development are seldom as clear cut as designing a language.
Most of the top 20 financial firms use CORBA and other ORB drivers to handle geo-scale applications. I believe anders needs to get out into application development and spend about 10 years in the field. Once he does, he will realize CORBA is there for a reason. The simplistic examples and views of anders definitely provides insight into many of .NET's short coming with handling complex processes. Doing distributed objects is because large institutions have to integrate with numerous systems. Handling that in a transactional manner isn't appropriate in a stateless Webservice or simple SOAP. what you really want is data + behavior. Just the values isn't enough to know what else to do in case a process fails.
I can't help but feel microsoft and .NET have taken a huge step back in terms of getting into enterprise backend applications. Trying to update data in multiple database isn't easy and never will be. Forcing webservices on these types of applications if foolish and doomed to failure.
Perhaps the original author should have said / trivially /easy to decompile.
,yeah, there are C (& C++ )decompilers, but whats the logic going to look like after /optimizing/? Working out that the compiler unrolled an inner loop from the assembler can be SO much fun. And can look less like the original than, say , an interative VS recursive imp.
/is/ probably doable just ADD in junk to the logic, ... / etc
And thats decompile not disassemble. In other words getting back the C++
with only withspace changes (indenting) and no comments -- but, actually, it sounds like they lose variable names, etc. I think some old basics and maybe applescript would decompile and give you the same names, ( bigfunc not func10234. )
Anyway, if they want to steal the logic, then
If it takes them to do a K-MAP to work out how the other guy did it, then they just did as much work to steal it from the other guy as do it-- or nearly...
Then again obfuscation
loads of crap look like
if ( ( VERSION + YEAR ) / 2000.0 2.0 )
g= JUNKVariable1 * 1000 +
else
g= REALformula
REPEAT ADINiFINITUM
if they'll never get the real names back then that should munge things a bit.
I wonder if he knows Jerry Pournelle?
Windows Forms was originally WFC (Java AFC extensions). Get it! All .NET is the Windows-specific java work that Microsoft was working on that Sun sued them over! When they got sued they just named it C# instead of Java!
.NET is far more than Windows specific Java work now and to discount it as such demonstrates a clear lack of understanding.
That's how it started, but not how it finished.
I'm guessing that you don't work for Microsoft anymore right?
You're being intellectually disingeuous, and engaging in doublethink.
After hearing the same freaking 'X is better than Y' argument over and over I have to comment on how pointless it really is. Each language has its own strengths and weaknesses. While lower level languages such as assembly are great for system programming, could you imagine writing complex user applications in pure asm? *shivers*. Perhaps we should quit arguing over which language is better and master the language we choose to develop in. Just my opinion.
There are people besides Gates who might disagree with your opinion of goto. Read what Steve McConell has to say in his -balanced- portrait of goto: http://www.stevemcconnell.com/ccgoto.htm
Notice that one of goto's defenders (for appropriate circumstances) is none other than Don Knuth.
I generally avoid goto like the plauge... but sometimes it's the right tool for the job.
Since a lot of projects need a GUI, how does c# performs on this? Since windows.form is missing from Mono, C# seems pretty useless in this respect. Of course, GTK# exists but then you'll have to rewrite your app anyway.. Java seems a better platform for cross-platform GUI stuff to me. Or are there alternative toolkits available??
History matters..
May be you mean that a cast in cast is slower that a cast in C??
Of course it is.
Don't let reality disturb you
You are ignorant of how casts work in Java. That's a problem with most people that haven't worked with C++ dynamic casts. It's ok though, since the new bunch of languages target audience is just like you.
I can't. I also can't imagine a Java program full of casts. Most I have seen or written have only a few casts
How come you didn't use collections then ? What kind of application does not use collections ? only the type of applications that contain forms and widgets connected to databases. But from the moment your application contains a data model, there are collections in there, which means lots of casts.
A programmer could be productive in any language
I said exactly that. : I don't think languages play any role
Not always.
Reduntant comment. Nothing someone says is the absolute truth.
Some C++ programmer have their C++ hats down to the waist
Well, most programmers that have gone through the pain of going deep into programming languages and C++ (and they are not simple users of the language, because their company said so), have good knowledge of the deficiencies of the language. But they also know ways to solve the problems, using tools the language provides. Which is not the case with any other language.
My colleagues are always asking me how do I manage to write C++ apps without memory leaks. They don't understand it, but, even if they know C++, they have never really got into the language. They deal with it superficially. But there are some really simple rules to follow:
Anything that can be on the stack must be on the stack. For example, there is no point allocating Point classes, since they are only gonna be used for assignment.
Heap-allocated objects that are referenced by more than one position are reference counted. There are plenty of smart pointer classes around, and it is really easy to construct one, if there is none available.
Heap-allocated objects most certainly have an 'owner', which deletes them when no longer needed.
By using stack-allocated objects, RAII is possible. I don't have to explicitely close a file...I simply declare it somewhere, and it closes itself upon the function returning. This is very important, yet overlooked.
By example take STL, which many believe is an end in itself when it should be a means
Do you know any other language that the 'sort' algorithm is defined once and it is valid for all types of collections, and the algorithm does not go through a virtual interface ? there is none, except C++. If this does not tell you something, then nothing will.
About that article at the link you posted:
the overhead of Java compared to C is probably about the same magnitude as that of C relative to Fortran
It is just fud. There are numeric libraries around, like blitz++ which is just as fast as fortran for all known cases. I haven't seen any Java app that confirms this for C.
There are arguments that Java may overtake C shortly; in fact this is already happening on Linux (with respect to gcc)
Instead of replying to the abolve, the article gives the answer itself:
Intel they found that the Java performance was very reasonable compared to C (e.g, 20% slower)
Java was faster than at least one C compiler (KAI compiler on Linux)
the performance gap is small enough to be of little or no concern to programmers
Even if I was telling jokes, I wouldn't put out the above really lame arguments. 20% not being slow enough ? a fluid dynamics simulation which takes 5 working days to complete in C/Fortran, it will take 6 days with Java!!! repeat the above test N times, and you have N days of delay...and the 20% is
Glock27, thanks for your reply. Of course I know that people generally think of server code as safe. But all it takes is for one of thousands of Amazon employees to provide a copy or a back door from one of maybe hundreds of servers, and the security is compromised. We spend a lot of time thinking about security, and it is easy to lose sight of the fact that "social engineering" is simple in many cases. Remember that the code for doing analysis of nuclear explosions from Los Alamos was available freely on the Internet for years, even though Los Alamos was supposedly secure, and the secrets were extremely valuable.
Also, there are many examples of cases where the code is available in byte code format. Commercial products provide everything, of course.
You are right, I don't know enough about GCJ. This is the issue: How is the binary formatted? Does GCJ bind the entire run-time library routines into the binary as one contiguous code block? Or, does GCJ sort through the library and build the library routines into the binary interspersed with the code? The first case provides a binary that is easy to de-compile. The second is far more secure, but still provides a machine method of de-compilation.
The problem is with the way that calls to the library are formatted in languages originally meant to be interpreted. It is easy to look for the structure of the calls, and once found, it is especially easy to see what the calls are doing. Those who don't do disassembly or de-compilation may not realize how easy it is.
In many programs, having the list of calls and their parameters would still not be valuable, because it is difficult to understand how the programmer has structured the program. However, most people don't realize that many of the most valuable programs merely contain business rules. These are VERY complex for a programmer to discover on his own, and very easy to copy.
Do you know enough about the structure of the GCJ binary to provide some advice on this matter?
which means lots of casts.
/. from Fortran programmers that C/C++ couldn't do a lot of useful optimizations than Fortran can do.
What I mean is that I doubt very much that casts is the only or principal problem in Java performance.
My colleagues are always asking me how do I manage to write C++ apps without memory leaks. They don't understand it, but, even if they know C++, they have never really got into the language.
That's one important drawback on C++, very few really understand it.
There are numeric libraries around, like blitz++ which is just as fast as fortran for all known cases.
I have read in
I have never claimed Java is good on numerical intensive applications, like the fluid simulation you point. But it may getting a little nearer.
The Osnew benchmark isn't a good one, except that it shows problems with Java implementation of trig functions. Those problems could be easily corrected by Sun if they even care.
In any case I think that we need more recent and well designed benchmarks, rather than theories on how it should be faster/slower than don't show in practice.
"I think this line is mostly filler"
Generics in Ada could do this even before C++. I think Eiffel, Haskell, and ML can too.
I doubt this; copying collectors that move objects without double indirection have been well understood for years. Just store a pointer to the object's new address at its old address after it's been moved, and update other pointers to the object as they're scanned.
Depends on your design style. People working on generational collectors have observed that most peer objects have about the same lifetime, and it's quite rare for old objects to contain pointers to new objects. And note that free() overhead is proportional to the number of dead objects, while GC overhead is proportional to the number of live objects, so each is faster in different circumstances.
I would believe you, except for the fact that companies are often hotbeds of compressed evil ;-)
Generics in Ada could do this even before C++. I think Eiffel, Haskell, and ML can too
Ada generics is specification of Ada95, not Ada83...at around 1996, C++'s templates were almost stable.
Haskell and ML are interpreted languages. They never got out of the academic environment. They have certain advantages, but their interpreted nature and their difficulty to develop reusable libraries have been a major drawback. In the ML I've used, all interesting libraries were coded in C, and used by ML.
Eiffel is a fine programming language. I don't know why it hasn't caught on. Eiffel engineers don't know either (and this is a famous joke amongst them).
Just store a pointer to the object's new address at its old address after it's been moved, and update other pointers to the object as they're scanned
Sun's documentation:
Java 2 SDK for Solaris exact garbage collection uses direct pointers for objects, rather than handles. Using direct pointers decrease memory consumption, speed allocation, and increase system performance by eliminating one level of indirection in accessing objects
Here is another link about Java using double indirection:http://h18012.www1.hp.com/java/perform ance/FastVM.html
There is certainly double indirection in there, as it is evident from the above links. And although Java code itself may not use double indirection, native calls do. That means that everytime the JVM calls some native method (most probably coded in C), it passes a handle to the object, not a C pointer.
Depends on your design style
No, it does not. Even value classes like Integer that are to used as keys as maps and hashtables are like that. And each time you want to do a lookup in a map/hashtable, you need to create a new object. What a waste of resources!!! Java 1.5 with generics will solve this, of course.
What I mean is that I doubt very much that casts is the only or principal problem in Java performance
You didn't say that. You explicitely said that you have never seen a java app with lots of casts. Don't try to change what you've said.
Of course there are other problems in Java. The lack of RAII is a good example.
That's one important drawback on C++, very few really understand it
And why is it a drawback ? if I write apps without memory leaks, everyone can. I am a fairly average person. And manual memory management gives better performance to those who need it. For example, one of the apps I participated in was an environment emulator for a weapon system that included lots of binary data exchanged between the weapon system and the radar consoles/processing units. I wrote it in such a way that memory was recycled efficiently. I couldn't done it with Java.
I have read in /. from Fortran programmers that C/C++ couldn't do a lot of useful optimizations than Fortran can do.
Fortran uses static tables. If you use static tables in C, without pointer aliases, the result is exactly the same.
I have never claimed Java is good on numerical intensive applications
But the article you posted did. In fact, Java is good in numerical computation, because, in the end, there are not many different ways to add/subtract/multiply/divide numbers. Java sucks in other things, like collections, for example.
Eventually, Java will be equal to C++. Two programs that compile exactly to the same native code and use exactly the same algorithms will have the same speed. And, for whatever trick Java may throw in, C++ can throw another one: there are very good garbage collectors for C++, as there are for Java.
You didn't say that. You explicitely said that you have never seen a java app with lots of casts. Don't try to change what you've said.
:-) Seriously, this may require a redesign depending of how resources are managed.
What I did say was "can't imagine a Java program full of casts" meaning casts on every line or near that. If I wasn't clear I apologize but I'm not changing things here.
About RAII, yes it's not applicable to Java or other GC languages. But if you can write a C++ program without memory leaks you will have no problem closing every resource
And why is it a drawback?
Because if there are less people trained to do a thing you have to search harder/pay more/train more before things get done. OTOH Java have this problem also, just there is a difference in the class of knowledge usually found on each language.
On your example I agree with you on that there are apps that are better (or easier, or even could only be) implemented in the other language (be Java, C++ or basic). I'm just not ruling out that someone else could make an implementation that works good enough to satisfy the requirements in language X (where X could be Java).
fortran
I'm not a Fortran programmer, if you say so, let it be.
Java is good in numerical computation
I don't understand what is your point here. You first seemed to support the idea that Java was to slow to do this, now the opossite. Or where just mentioning the article? I'm a little lost here.
Eventually, Java will be equal to C++
I think that Java will always be slower (even a little) than C++. But I remember when most programs were made in assembler and C was the slow new language. C winned in the because it was easier (that subjetive concept) to write programs in, rather that because of it's speed.
there are very good garbage collectors for C++
While automatic GC is possible in C++ I don't found the concept appealing. C++ just wasn't designed for this.
"I think this line is mostly filler"
can't imagine a Java program full of casts
If you can't imagine it, you haven't seen it, either.
If you haven't seen a Java app with lots of casts, it means the app didn't use collections. Which means it was a trivial app.
it's not applicable to Java or other GC languages
D can do it.
But if you can write a C++ program without memory leaks you will have no problem closing every resource
I don't have to close anything. RAII takes care of that.
Because if there are less people trained to do a thing you have to search harder/pay more/train more before things get done
But if people aren't trained, how are they gonna learn ? it's a chicken and egg problem.
I don't understand what is your point here. You first seemed to support the idea that Java was to slow to do this, now the opossite. Or where just mentioning the article? I'm a little lost here
I never said that Java is slow in numerical computations. I said that the article(s) you posted had flaws in it(them)...these "flaws" are deliberate, in my opinion, from people that never gave a dime understanding C++ and how they can be productive with it. For example, they did not compare the top Java version 1.4.2 against a top C++ compiler such as the Intel one. It's unfair, it's biased.
I also said that Java is generally slower than C++, mostly because of the way collections/iterators work, no value objects and because of the GC.
I think that Java will always be slower (even a little) than C++.
Well, the difference will be so small, as to be negligible. Eventually, the language and the JVM will improve so much as to reach the state of a statically compiled language.
But I remember when most programs were made in assembler and C was the slow new language. C winned in the because it was easier (that subjetive concept) to write programs in, rather that because of it's speed.
Nope. The jump from assembly to C gave you a 10x boost in productivity, while the jump from C++ to Java gives you 0.1x boost. In reality, it gives you nothing, if the libraries you use are well written(Qt for example).
Have you worked with Qt ? it is the best library ever written. Don't let others fool you: it gives you the full power of C++ and Java!!! you don't even have to manage memory. It has a wonderful signals and slots mechanism, and plenty of classes for everything. And a program you write under Windows runs as-is in Linux/Mac/Solaris/Unix. No, I don't work for Trolltech, but I am so much impressed with it, I can't stop talking about it. Something made in Java is usually done faster and better in Qt.
Of course, Java has its own good points. But its not all that is cranked up to be. For example, you may have not to delete things, but you sure have to make pointers null. IF you don't, memory is not released. I have seen this numerous times, and it is the Java memory leak problem (leak, in the sense that it is never freed).
The jump from assembly to C gave you a 10x boost in productivity, while the jump from C++ to Java gives you 0.1x boost. In reality, it gives you nothing, if the libraries you use are well written(Qt for example). Have you worked with Qt ? it is the best library ever written
I differe here, because I think library support is one of Java strengths, and one in which I find a boost in productivity.
I haven't used Qt, so I checked in teh feature list and it seems impresive, covering DB, XML, networking and graphics. I just would like to point that is not part of the standard, and I understand that you have to pay a licence for commercial closed source apps. I just mentioned it because other people think is free, not because I'm against it.
Java has an even more functionality in is standard libs.
Java makes it very very easy to reuse third party, and there are lots of excelent ones, like those from Jakarta. Because the base types are standard, portable ABI and no need to recompile your program (no #include nonsense) you can just use without adapting or recompiling as many C/C++ libs. You don't have problems linking libs compiled from different compilers or platforms (for example: linking in C/C++ from two different compilers won't work because of different runtime libs, or C++ name decoring). So you have a lot of functionality in libs that can be reused as is that helps productivity a lot.
"I think this line is mostly filler"
I differe here, because I think library support is one of Java strengths, and one in which I find a boost in productivity
I just would like to point that is not part of the standard
Don't confuse the language with libraries. When we talk about the language, we mean the syntax, the semantic rules, etc.
I understand that you have to pay a licence for commercial closed source apps
It has nothing to do with the language though. Trolltech is a small company, they are not Sun. They have to earn something for their outstanding work.
If you personally can't afford to buy the toolkit, then you are not making something for commercial use, are you ? in that case, you can use the open source Qt licence. if, on the other hand, you have a company and want to make a commercial product, it pays to buy the Qt library. It's not that expensive.
But price has nothing to do with productivity. It's another issue alltogether.
Because the base types are standard, portable ABI and no need to recompile your program (no #include nonsense)
Java is a compiled language. You have to compile it before the program runs. There is even a javac tool which produces the bytecode output. It's the bytecode that it is dynamically translated, not Java itself.
Why is include nonsense ? it may slow down compilation, but only for those compilers that don't support pre-compiled headers. If you use pre-compiled headers, #include = import.
you can just use without adapting or recompiling as many C/C++ libs
You recompile once, for your machine. After that, you don't recompile anything any more. You may consider the compilation as an installation step. After all, C++ is a statically compiled language. Compiling for a specific CPU gives you the advantage of using optimizations specific for that CPU.
You don't have problems linking libs compiled from different compilers or platforms (for example: linking in C/C++ from two different compilers won't work because of different runtime libs, or C++ name decoring).
But the C++ standard does not define an ABI. And it's actually right not to!!! Imagine having to use binary libraries compiled on a 486 and used in a shiny new P4!!! all those optimizations will be gone! C++ is about source code compatibility between platforms.
I am not saying that Java is flawed in the compilation area. It isn't. But C++ is not flawed either. They are different because they were born out of different needs. C++ was born static, because, at the time that it was born, dynamic recompilation was impossible. But it does not hurt development of stand-alone applications.
You're making disingenuous accusations to discount a valid argument.
Ada 83 did have generics. Dispatch was always static until Ada 95 added tagged types.
Every current JVM design I'm aware of uses direct pointers to access objects, only storing an object's "forwarding address" while the GC is running (so that all direct pointers to an object can be updated). Certainly it's possible to move objects without using handles. JNI's extra layer of indirection isn't there to enable moving objects, but to prevent native code from knowing anything about how this JVM implements objects, and it doesn't affect GC performance at all (as part of the JVM, the GC code doesn't have to limit itself to using JNI to access fields).
Using hashmaps is a design choice, and this only raises locality issues if a map and its keys and values don't have the same lifetime.