Slashdot Mirror
Does C# Measure Up?
An anonymous reader queries: "Windows::Developer is offering a detailed, quantitative examination [free login required] of C#'s performance versus Java, C, C++ and D. 'Overall the results were surprising, although perhaps unexciting, in showing that C# (and to a less extent Java) is, to a good degree, on a par in efficiency terms with its older and (presumed to be) more efficient counterparts C and C++ at least as far as the basic language features compared in this analysis are concerned,' writes the author, Matthew Wilson. I'm only an amateur coder, and confess to not understanding most of the two-part article. I'd love to hear how true programmers view his results, which are too wide-ranging to summarize easily here. How about it Slashdot, as this special edition asks, 'Can C# keep up with compiled languages like C, C++, and D or byte-code based Java?'"
While we're on the topic of C#, rnd() queries: "It's been a while now, since Mono and DotGnu have begun eroding the market power of Microsoft by creating open source implementations of C# and the Common Language Runtime. Over the weekend I loaded Mono and did some informal benchmarking of object creation, intensive message passing, massive iteration, etc., and the results show that Mono is about 90% as fast as Microsoft's implementation after a very short time. I now want to switch my .NET development over to Linux/Mono exclusively, but I want to first settle on a free alternative to Visual Studio .NET 2003. Any suggestions?"
C# is higher pitch than C but less so than D.
--
There's a D? What's next? Eb? Technology is moving at an incredible rate, indeed!
Hotspot is really good about compiling bytecodes down to the native machine language. That code is real honest to goodness native code, and will execute at approximately C++ speed.
Why use anything else?
- David
How about Eclipse?
I referred this question to a colleague of mine, and I have enclosed his findings below for your perusal. http://web.ask.com/web?q=%27Can+C%23+keep+up+with+ compiled+languages+like+C%2C+C%2B%2B%2C+and+D+or+b yte-code+based+Java%3F&o=0&qsrc=0
Actually VB apps tend to run just fine through Wine, or at least a few little projects I've done in VB have worked for me...
(a) That's not the only problem;
(b) VB isn't the topic; and
(c) That isn't even true.
Wow, none out of three!
D flat, damn it.
Raed it. Ingroe it. Bncehmrak aynawy.
I'm assuming you're asking for an IDE alternative to Visual Studio .Net. Take a look at SharpDevelop. According to its authors, it's open source under the GPL. I've given it a try on my old P2 300, and it's not bad at all IMO. It takes a little longer to load, but it has solid functionality and tons of features on an interface that looks very familiar to that of Visual Studio .Net
This really makes sense if you understand how JITs work, and understand the nature of the benchmarks. These benchmarks are mostly microbenchmarks that test a particular operation in a tight loop. JITs can compile this loop once and run it directly on the CPU afterwords. This doesn't extrapolate well to situations where the JIT gets involved more often in the benchmark.
A deep unwavering belief is a sure sign you're missing something...
Are you sure about that? Granted, that's VB.NET, and not VB pre-.NET, but it's still VB. It's also still under development, but the work is being done.
I now want to switch my .NET development over to Linux/Mono exclusively, but I want to first settle on a free alternative to Visual Studio .NET 2003. Any suggestions?
:-D
VI.
C,D, I feel bad for the F Programmer.
Mono is a bit faster than Java, for some benchmark?
Well, why didn't you say so before?!
That way we could have avoided all that tedious discussion about IP infringements, functionality etc. in yesterday's Mono debate. Clearly some dude's performance figure should override all other considerations when choosing a platform.
Hahaha...
Yeah, some day I'll be able to stop myself from doing that. *hangs head in shame*
> Overall the results were surprising, although perhaps unexciting, in showing that C# (and to a less extent Java) is, to a good degree, on a par in efficiency terms with its older and (presumed to be) more efficient counterparts C and C++ at least as far as the basic language features compared in this analysis are concerned
Could we have a few more weasel-words in that sentence, please?
Sheesh, evil *and* a jerk. -- Jade
Java has received alot of attention over the last 7 or 8 years or so. It's a great idea in theory, but it falls way short in practice. It does remain viable for a few select uses, though: small widgets, servlets and web app servers. Pretty much other than that, using Java will mean excessive memory usage and slow performance.
Garbage collection in Java is not guranteed. It's what I call Union. It'll clean up when it god damn well feels like it. In the meantime, the system slows to a crawl.
Graphics in Java are abysmally slow. Even basic UIs lack the speed and responsiveness of GUIs written in C, C++ or similar languages.
Java was supposed to be: Write once, run anywhere, but what it is in reality is: Write once, debug everywhere... over and over and over. Or perhaps more appropriately it is" Write once, run screaming.
I've worked in a variety of Java development projects in the past and not once has it ever risen to the task to show itself as a worthy choice and/or a mature language. Instead it has invariably wasted companies time and money. Primarily because they failed to realize that Java is a small task tool, not suitable for major applications or those requiring performance.
I know a lot of engineers like Java because it makes life easier for them by doing things for them, but those things it does it does very poorly.
I'm sure I'll be marked as flamebait or troll by some Java loving mod, but what I've stated are facts and experiences from real life Java development. The results are in and frankly... Java sucks! Stick with C and C++ for most development, there's a reason they are the standard: they work.
This is just one way to slice the pie.
Languages are appropriate for different uses. I use C while kernel hacking. I use C++ for its template abstractions. I use PHP for web pages, Perl for command-line scripting. I use bash/tcsh for boot-scripts. I respect VB as an accessible language, but I have no use for a single-platform language.
What language you use depends on your application. Comparing C, C++, and C# is like comparing a wrench and a screw driver. And concluding they can both be used as a hammer.
C# is good because it competes with java and therefore will make SUN competitive.
Whats really needed is a FAST language that can be run on all computers so the software developers don't have to develop different code for each OS so applications don't need porting and speed and memory consumption wont be noticed by the user like they do with java. Something that can also be run on all handhelds with speed.
Java will never be able to do that.
C# was Delphi b (best flat sign I could do)
My other sig is extremely clever...
- C# fares rather well.
- ... but almost never as well as native C and C++ implementations done "smartly".
- Java suffers from runtime-based overhead, with the advantage of a well-tested set of runtimes for various platforms. Unfortunately, due to the Java implementation of client-side runtime libraries, programming in Java is still "write once, test everywhere. curse. port everywhere" for real applications.
And most importantly, as a game programmer, I'm going to pay attention to the relative performance the author received from the Intel-branded compiler, written to the metal of the Pentium IV with streaming SIMD instructions. -andyOK lets get a few things settled.
Given: two identical applications; A, written in low level language like machine assembly, C, or C++; B, written in high level language like Java, Python, VB, hgluahalguha.
If the application is high in CPU burn (lets call it X), like oh, for (i = 0; i
If the application is copying a very large file using basic read/write system calls and large enough buffers (lets call this Y), A and B will have very similar performance.
If the application is printing hello world, they will have similar performance, although the startup costs for B may be higher, and A will probably finish executing faster.
MOST applications written today are written to solve for Y. The code that most programmers write today is NOT the CPU intensive portion. Usually the CPU intensive portion is in the library called by the programmer: rendering a box, moving things around on a storage device, making something appear on a network.
In these cases, a high or low level language makes no freaking difference on execution speed. However, your choice WILL make a huge difference on time to develop, maintainability, resultant bugginess, SECURITY, etc.
OF COURSE THERE ARE EXCEPTIONS. Maybe you're writing a routine that needs to draw lines fast, or move bytes through a network filter at 100MB/sec, or you're compressing a file, whatever. In these cases you tend to write the performance critical code in a more low level language so you have greater control over the physical machine. Sometimes you write the entire application in the low level language.
Many high level languages provide mechanisms for calling low-level code when it's necessary for performance. It's often pretty easy.
The performance argument is a red herring.
Someone's set up slashdot:slashdot
...my life. It's been mostly C/C++ but also a good amount of assember and VB. Maybe someone here can answer one of the questions that keeps poping up when I write anything. My question is, why do we always end up creating libraries/classes that contain other code we will never use? What I would like is a compile environment where each function or object that I use is individually addressable, without having to pull in other "stuff" I don't need in my specific app. Is that so hard? Why doesn't the OS manage code better than pulling in a whole library? If I use only strcat() for example, why do I need to load in the entire C string library?
.NET and Suns Java take the cake by making you load an entire "run-time" engine. This consists of vast numbers of "ready-to-go" objects that make your simple "Hello World!" app into an 11 Meg progam. Java can't even share the "run-time" between apps very well!
The problem gets even worse with C++ and objects. Huge numbers of member functions and public variables that will never be used. Microsoft's
Is there a program out there that can tell the efficiency of the operating system environment, apps and OS, by how many functions "aren't" getting used in a normal day by a user? I'm going to go out on a limb here and suggest that most RAM isn't being utilized by apps.
What I would like is an extremely efficient programming environment that compiles my six line x++ program down to a few hundred bytes total...that's in-memory while running. I want to use my RAM for data and number crunching, not unusable code.
+1-1
I don't know if anyone has done any formal study on the complexity of development tools over time - but the fact is that programming tools are getting "lower" over time.
When I started out in this business, a language like C was a high level programming language. It did a lot for the programmer, especially compared to assembler and FORTRAN.
Everything we did every day was to save memory and CPU cycles. Can we squeeze a date field into 8 bits? You bet we'd try! And we did! Heck, we could ignore weekends and holidays. Phew!
At the same time, databases were heirarchical. The databases were very close to the machine, so they were darn fast. As long as you didn't do any unexpected queries (like "sort by first name"), everything was blazing fast and tight.
Then came the higher level systems. Ouch, they sucked! We were the very first customer to run DB2 in production (quiz- you know which one?) Anyhow, it sucked rocks compared to the heirarchical databases - they were just optimized for speed! Why would anyone ever want a relational database?
But over years we came to see the light. With faster and faster machines, the number of cycles was less important. With bigger memory and disk, storage was less important. And it was butt-easy to use these tools. Easier and MUCH more maintainable.
So yeah, Java and C# are going to use more memory and more cycles than plain old C (if using the languages as expected). But for most tasks, that isn't the whole story.
The whole story is that Java and C# result in less expensive programs. And those programs should run fast enough. Yeah, not in EVERY case. But in most cases.
Performance comparisons be damned.
I recommend that any programmers out there try using it before discounting it. It might be especially interesting for those C++ programmers out there who don't like Java for one reason or another.
When i first heard about C# i thought "Why is M$ making it's own language in the first place?" Then I thought i'd give it a try and I pretty much said "if there is nothing extrordinary about this lanugage then it's pretty much useless. C# would have to be something really great to replace C++ or Objective-C for me.
So i dove into C# and found nothing extrordinary about it. If nothing else it looked like a confusing mix of C++, Java & basic. Well i've been wrong before so i asked my teachers after a meeting with industry bussinesses and their opinion was that "most developers don't want to learn another language just to learn another language that does not offer great benifets." They further said that it most peoples opinion they asked about C#/.NET it has had the exact oposite effect that M$ thought it'd have.
I'd hate to say it but this is clearly M$ making it's own version of something JUST to have it's own version of it. Wake up people!
Microsoft has sought protection for a "programming language and compiler system capable of generating object code that performs comparably or better than C."
"Java will never be able to do that."
Says who? Computers are getting faster and faster. Java applications on my machine (AthlonXP 2200) appear to run just as fast as any native application. I'm sure some benchmark could tell the difference, but I can't.
You wouldn't run a java database server at this point, but as computers keep getting faster... the performance hit will become less and less of an issue.
- It's not the Macs I hate. It's Digg users. -
God..so typical for this site. Hardly any of you answered his question - most just throw out the 'java' answer..which isn't any sort of answer for client apps - it blows on the client - no one would use an app written in java if there were an alternative product written in anything else (god even VB).
But, sorry dude, I can't help answer your questions as I am a windows coder and just lurk here for the interesting news and to laugh at the linux elitists.
Yeah right, like anyone on Slashdot knows two things about writing code or anything else valuable.
troll on! w0ot kewl dood
I've been using it exclusively for almost two years now and it's really the best language out there, at least as far as Windows programming goes.
http://www.ddj.com/articles/1991/9110/
-rick
These tests are very trivial. Basic string tests are one thing but they are very different from the complex performance implications of larger scale software.
A good indicator is the game industry. Game developers are notorious early adopters and tend to care little and even hold contempt for backward compatibility. But they also require performance. There are plenty of Java puzzle games but any major game with fancy graphics that you find on a store shelf is C or C++ (with various graphic specific languages and custom game scripting type languages).
If you start seeing competitive cutting edge 3D engines written in Java, then you will know the performance difference has become moot.
There are plenty of non-game examples but that is the easiest to see.
Java and C# are great languages. Eclipse is awesome. But the performance, of Java at least, still isn't there; even with native code compilers.
...be smart enough to "know" what sub-functions each function you are using needs to be loaded. If strcat() only uses 3 sub-functions, then those should only be loaded for "it". And, if those functions are already loaded "somewhere in memory", the OS shouldn't load them again, and again, and again, as so often happens these days.
I'm saying that the compiler/OS should be smart enough to "itemize" your entire application in terms of absolute functions/variables needed at compile and run-time.
Where is that capability? Why aren't compilers smarter?
-1+1
Ah well, .NET still is pretty nice.
C# is to C/C++ like what C/C++ were to assembly. Yes, Assembly is faster then C/C++, but most of the time it's not worth the trouble. Likewise, for a lot of programming that people do today, squeezing out every last processor cycle isn't always worth it! C# offers some very convienent features compared to C/C++, yet at a minor, (and sometimes no,) performence hit.
Simply put, the language you use depends on the intended use of your application. If you're writing a number-crunching app for a single CPU type, then there's no reason to use C#. Likewise, if you're writing an application that needs to be developed quickly and be highly reliable, yet doesn't need to save each CPU cycle, then C# may be a better choice.
Personally, I think C# is great for Windows GUI programming where there is a lot of user interaction.
No matter what you say, C is *always* faster. You *cannot* write a loop in C#, and claim that it will run faster than a comprable loop in C. For one, the interpreter for Java or C# is very likely written in C itself.
Does the speed matter? Does anyone care? No. Well, not for a vast majority of applications. Most of the time the I/O speed is the bottle-neck, not the "code" speed. So if you write a word processor, or some database app in C#, or C++, or C, or Java, more often than not, their 'apparent speed' will be comprable to each other.
A better question to ask is: Would you do numerical analysis, or number crunching/factoring algorithms in Java or C#? Would you even do them in C? (or would you go for Fortran or distributed Haskell?)
"If anything can go wrong, it will." - Murphy
I write stuff that chugs through hundreds of megabytes of binary in real time data and nothing comes even close to C (and assembly if portability isn't an issue). I love STL and C++ in general (and use it a lot) but they are a murder when the highest performance is required. Don't even get me started with Java (haven't tried C# yet). Yes, it is still way much slower even with JIT (and yes the IBM VM is what I'm talking about).
And, if those functions are already loaded "somewhere in memory", the OS shouldn't load them again, and again, and again, as so often happens these days.
If the functions are in a shared library, they shouldn't be. Each library (including, for example, the C runtime) is loaded once into memory and every process uses the same code. If you modify that code in memory, Windows makes an individual copy of the page for the modifying process. I couldn't tell you exactly what the overhead is used for, but the OS isn't loading 20 copies of strcpy or whatever as long as each executable is dynamically linked.
C# has recieved the majority of attention but has everyone forgotten that their are other .NET enabled languages. It's perfectly acceptable to use C++ and all of it's features and familiarity to produce .NET executables.
If fact it's probably the most likely migration path for existing applications.
I did that. He seems to be Australian.
It all depends on what you are trying to accomplish. I know a half dozen or so languages and use the one that gets the job done. I do however find myself reaching for python most of the time. It has reasonable speed, very maintainable and is one of the most productive languages in existance.
One of my issues with java, qt, gtk, wx windows etc is the layout crap. It always seems someone is ramming their super duper ultra cool widget layout engine down my throat.
Screw that crap, I want X,Y positioning and let me handle the darn layout specifics. In this reguard only borland has ever gotten layout working correctly.
Got Code?
I've heard they tried Pascal in the beginning.
Guess why they moved to C and C++...
Now, they want to change the world. Yeah, right...
You know, any time people talk about languages like Java and C# they always are quick to point out how it's "as fast as C or C++" and they have a pacel of tests to prove it. Similarly, C++ folks say "it's as fast as assembly" - some even go so far as to claim it's faster due to better optimizations.
Now I believe in science and tests and so forth, and I'm sure there's some validity to these claims, but why is it every java program *seems* to run like molasses and every C++ emulator is lucky to get half the speed of the equivalent assembly version?
Somehow I don't think people are being complete honest here. As video card buyers have known for years, something can get great results on carefully chooses benchmarks but still have crappy real world performance.
Too bad Limbo is too deeply tied to Inferno. It's unfortunate. From looking at how it's been designed it seems that Dennis Ritchie still hasn't lost his touch as an exceptional language designer. The Dis virtual machine that goes with it is supposedly designed to make a JIT simpler and more efficient, and well, according to Vita Nuova it gets something like 50% to 75% of the performance of compiled C/C++ code, which, if the article and Vita Nuova's benchmarks are accurate, totally blows C# and Java out of the water performance-wise. Now if only Vita Nuova would care to make it half as platform-neutral as Java... But hey, who cares, I'm already trying to do that. :)
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software.
There are plenty of dinosaurian programmers like myself who remember hacking away on small machines. Save a byte by referencing a constant stored as an opcode in the instruction stream? Excellent! SLR R1,R1 is 60ns faster than SL R1,R1? Excellent! Decrease the size of the PDP-8 bootstrap loader by one word? Excellent! (Flipping those toggle switches took a lot of time.)
In 'the old days' hardware was expensive and programmers were cheap. Hard problems were solved by incredible brainpower from great engineers. As a result, by the early 70's software had made huge advances over the punchcard/paper-tape era, and we had learned a lot about how to build quality systems.
But there was a magic moment when the curves crossed between the cost of programming time versus the cost of hardware. Suddenly, it became easier to solve a problem by adding iron rather than by thinking harder. And so we slid backwards down the slope.
As far as I'm concerned, hardly anything significant has happened in software architecture or praxis for a few decades. Sure, we have a bunch of fancy new widgets, and the common man's programming paradigm has changed. And the Open Source movement finally has given substance and a PHB-understandable framework to what Unix, LISP, Smalltalk, and other hacker communities used to do behind the scenes.
But most of today's 'new' language, compiler, data management, operating system, and other computer science paradigms had their fundamental elements invented back in the 60's and 70's. We're finally RE-discovering many great concepts of the past. But it seems we've totally forgotten the importance of efficient, defect-free code, and the methods that might be used to create it.
This is not to say that only great systems were built in 'the good old days' -- those days weren't that good, and there was plenty of crap. But the really bright folks figured out how to do things RIGHT; and yet they wound up being ignored, because 'doing it right' became less important than 'letting Bruce the part-time lifeguard do it over the weekend in Visual Basic.'
So while I totally agree with your rant, and I've made a hundred similar rants of my own, the fact is we probably won't see fundamental improvements in software platforms until subatomic physics finally provides a wall against which hardware advances can bounce. As long as the answer to every performance/capacity complaint is "wait six months" there's no incentive to invest the man-centuries it will take to revamp our software environments. We probably need to build intelligent software that can optimize itself, because WE NEVER WILL.
</rant>
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
Well the writer is clearly from a magazine called "windows::developer", so obviously a pro-Microsoft bias will be likely.
Having said that, the same argument could be made for any article: Pro-Java? Clearly someone from the Sun\IBM camp. Pro-Pascal? Come on you Borland employees, quit trying to trick us!
Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.
Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).
...in terms of a whole "shared library". I don't want shared libraries as much as I would like individually shared "functions/classes". You are right that if app A loads library A, and app B uses some function in library A, the OS should'nt re-load the same library A. But what if app A doesn't use but 1 function in library A? And, app B only uses 1 other function from library A? Now we've got two apps loaded that are using a library that may have 50 or more shared functions that aren't being used!
-1-1
Related to this, I've read (sorry no references, search google) that Managed C++ code will run faster than comparable C# code due to the experience in C++ compiler optimizations. So if you want to write C++ and have the benefits of .Net, perhaps you should look into Managed C++.
I do a lot of ASP3.0/SQL2k and some utility development on Win32, taking a stab at .NET. It would be nice to move over to Mono.
Anyway, I've done a bit of poking around and ran across SharpDevelop - AKA #develop . It's open source a la GPL and looks a lot like Visual Studio, and compiles C# and VB.NET; has C# => VB.NET code conversion; does projects or files; has syntaxing for the whole MS shebang. It's a .97 - this build was released Friday 9/12/2K3, officially in beta, and you can get the binaries here, go snag the source here, and get the MS.NET1.1SDK here.
To those folks who hiss and moan about the whole GNOME/.NET/Mono thing, take a gander at the rationale before playing jump to conclusions (mp3).
SharpWT - AKA #WT is a .NET port of Java SWT on both Windows/.NET and Linux/Mono platforms. So...you can develop your .NET apps to run on both Win32 and Linux with pretty much the same GUI. Neat, eh?
Anyway, intrepid Windows Developer, if you can pry yourself away from the MSDN Library for a few minutes, you might find there's something to this Mono business.
The hammer has been found to be a better tool that a screwdriver, while the saw fell somewhere in the middle.
I personally always use a hammer...
SCO sucks. End of story.
There you go.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
I've been coding for a million years: 6502 machine code all the way up to a recent foray into C#, and almost everything in between. Here's my take, for what it's worth. And, it's your chance to mod me down for pontificating!
.NET, to which C# is bolted, is pretty good as well. And the IDE is very nice. So, all-in-all, I think that C# is a good choice for Windows development. The web forms stuff seems interesting, but I have a feeling that using it would be something that I'd end up regretting - there's bound to be nasty gotchas that won't show up until late in the project.
Delphi is the best all-around language ever for producing Windows apps. The Delphi programmer has control over everything if they want it, but they don't need to muck around with nasty details unless they need to. It encourages clean coding. Performance is superb. And the IDE is excellent. The Delphi package (language plus IDE) has been the path of least resistance to getting an app done for the past six or seven years.
Prior to Delphi, the way to go was VB with C DLLs. Do the UI in VB, do the internals as C DLLs. VB was great for abstracting nasty stuff, but it often overabstracted, and performance was ungood. Writing companion DLLs in C boosted flexibility and performance.
Generally speaking, C is basically not much beyond portable assembly language. If a reasonable alternative is available, and it usually is, using C for anything beyond embedded systems or super resource-critical applications is probably not a good idea, as the code tends to be dangerous and obsfuscated. And keeping track of pointers is just nutty.
C++ is a nightmare. In theory it's object oriented, but all of the code that I've seen is a total mess, more like C using the C++ libraries. Ugh.
Java is almost good: it is pretty safe, and encourages good habits. But I find it clumsy - like it was designed by academics rather than practical developers. Lack of enumerated types, for example, is insane, and encourages unsafe programming. It's also a pig, which doesn't matter so much for a lot of things these days - we usually have lots of CPU cycles to spare. For doing GUI apps, Swing is a weird joke - a pig's pig - which should be forgotten immediately. And the Java IDEs have only recently become usable for command-line stuff, but they suck as bad as Swing for GUI development.
Now C#. Having toyed with C# for an app recently, I'm quite impressed. It's sort of like the best of Java with some of Delphi's goodness added. It's ALMOST as good as Delphi - which makes sense, since the same fellow (Anders Hejlsbeg) was key in developing both of these languages. And
I am in the process of coding a data collection server application in Java which collects data from remote devices that dail up over a phone line. The application must interface with the serial port at a low level, send email, generate XLS files, send faxes, create charts, and, of course, communicate with a DBMS. It also has a significant GUI component as well. Oh yes, this application must be able to run both on Linux and Windows (2000 or XP).
I have been developing on Linux. All in all, to date I've coded around 30,000 lines of code. Because of the high level of portability of the APIs, I had to change all of about a dozen lines of code to get it up and running on Windows. That's one dozen out of 30,000. There's now way you could even come close to that using C or C++, regardless of how cross-platform the library developers say their libraries are.
As far as performance, Java may have been slow three of four years ago, but the last several versions of the JDK and the HotSpot JVM have seen a steady and rapid improvement in performance and stability. SWING, although it has improved, may still be a bit slow, but computational code written in Java is only slightly slower than in C++. Even current versions of SWING, although arbuably slower than native GUIs like GTK+ or QT, are fast enough so as to not be noticable on any machine faster than 800MHz or so.
Most people who say Java is unstable or slow are remembering their experience from the JDK 1.1 days. The current JDK 1.4 bears little resemblance to that in terms of performance and maturity.
And this is where the .NET Framework shines, because the CLR is a generic virtual machine to which any number of languages can be compiled. Currently there are C#, C++, VB, and even Java (under the moniker J#). There has been talk of writing a Python compiler and even possibly a Perl compiler. So you can choose your language of choice, and your resulting binaries or objects will fully interoperate with the other .NET languages and class libraries.
And as far as this article is concerned, I think the interesting point is not that they're comparing apples to oranges, but just that the performance numbers for CLR-compiled C# aren't so horrible that they should scare off the majority of developers.
Any benchmark that shows interpreted or bytecode languages to be on par or better than compiled languages must be understating the optimizations possible with compiled languages.
Troll, maybe. Flamebait, perhaps. But, how can a post that replies the question asked in the article title be offtopic?
Yes, there is a D language. As far as I know it's still academic, but it does exist.
... from evangelical believers, who, not unlike Microphants, seem to think Java is right for everything!
When it does something poorly, it's as if we're supposed to believe that it's supposed to... not efficient... not supposed to be, machines are fast now... etc.
I agree with you... server side java makes a lot of sense. But are their Java advocates that just want to use Java where it makes sense?
-pyrrho
BASIC.
;-)
Not any of that wimpy namby pamby visual, object oriented stuffage. The big meaty pain in the arse line code BASIC.
Basic BASIC
Yeah now that is coding! 500 lines of code to watch 2 blobs on a see-saw, now that's living! Woohoo!
:-( --- argh. Despair, I owe again.
But that has nothing to do with C#, which, clearly, comes from musical notation. C# is the same note as Db, or D-flat. After C# comes D, and after D comes Eb, or E-flat.
... most server-side apps are bottlenecked by either internet bandwidth, or database access speed. Java is just fast enough that the cost of bytecode-interpretation and JVM semantics-preservation can be covered up with big beefy servers.
Riddle me this: if Java rocks on the server, why are there no industrial-strength databases in native Java? You would think Oracle would be thrilled to write once and deploy everywhere...
To a Lisp hacker, XML is S-expressions in drag.
Possibly true for pure VB, but major VB apps aren't. In order to do a lot of things that aren't intrinsic to the language, you end up calling C/C++ or Windows API functions to get the job done. That tends to blow compatibility with non-Windows runtime environments (hell, it tends to blow compatibility with Windows environments.)
The higher the technology, the sharper that two-edged sword.
Actually, FWIW, I created a very responsive Swing application that found the energy eigenvalues and the corresponding eigenstates inside of a quantum well.
I should say, it was very responsive on my ultra-modern K6-II 450Mhz 160MB monster laptop. I didn't really notice much of a lag at all in interactivity. I found it very useful.
Couple that with the fact that it ran great on my boss's Windoze box, and all was good in Javaland.
--
Given enough personal experience, all stereotypes are shallow.
I really can't believe this thread. Why do people always come up with this worn out line whenever someone suggests that C++ templates are an advantage? And how come so many people have done so in replying to the same post? All but the first are (-1, Redundant), and the first is (-1, Ill-informed).
OK, please, read this carefully, for I shall write it only once (in this thread):
Java's generics are not even close to the power of C++ templates. They are glorified macros to fix a bug in the type system that should never have been there.
C++ templates were at that level around a decade ago. Today, they're used not only to create generic containers (for which they are, no doubt, very useful) but also, via metaprogramming techniques, as the tool underlying most of the really powerful developments in C++ for the past few years: expression templates, high performance maths libraries, etc.
If you didn't already know that, please read it again and understand it before proceeding.
Java's generics don't even come close to the same power. They're a cheap knock-off, aimed at just one of the uses of C++ templates, which fixes a glaring flaw in the previous Java language. For that, they serve their purpose well, but please don't pretend they're anything more.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If one language is twice faster than some other language in certain situation, it does not garauntee that the first language is always a better choice than the latter one.
Consider if a plain C/C++ based text editor starts up in 200ms while Java/C# based one starts up 400ms. Who cares for that extra 200ms? But on the same time, If it took 2 month/2 expert C/C++ programmer for the first text editor while it took only 1 month/1 average Java/C# programmer, it makes huge difference if you're project admin for that text editor project.
I don't mean speed is not important, or C/C++ development cost too much money. But what really matters is not the relative performance between languages, but acceptable performance for that particular project and customer's need. Who cares if a server daemon took up 30 secs to load if you only restart them once or twice a year? If all that matters is raw performance, we would all develop kernel module in plain C to handle HTTP request and write HTML response directly to build a personal homepage and write an assembly program to directly contact mysql daemon with tcp socket to retrieve the new messages on guestbook.
... compared to the code-generating power of lisp macros.
To a Lisp hacker, XML is S-expressions in drag.
A 3D engine is doing a lot of math. C code that just does math is already portable across platforms, and usually across compilers too.
You're never going to see cutting edge 3d engines written in Java, or any other interpreted, scripted, or bytecode language, because those languages lose their typical advantages in this case.
The rest of the game, however, can greatly benefit from high-level languages, because it simplifies game object creation and handling. Do you really want to be managing memory when you could be writing the interface?
If, however, you write code that does a bunch of computation etc, you will see difference. C will outperform C++, C# and Java.
Engineering is the art of compromise.
Give it a rest. We all know C and C++ are faster than JAVA and C#. The only reasons why IT chooses either one is because of the time it takes to get the app to Production.
If C or C++ application didn't take as long to develop, then we would all be writing our code in either one.
According to IBM, it's not what's underneath but how "Productive" you are.
Microsoft have had a .Net version of Quake II mentioned on their developer pages for some time now. It's a port to Visual C++ .Net 2003, using the CLR.
Has anyone tried this? It's presumably managed C++ rather than C#, but it should give a fair indication of the performance you'd get from C# if it's using the same run-time framework. If they can get comparable performance in a FPS using the .NET run-time, it might be worth looking at for games development after all...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
only write in A and E.
Breaking the law breaking the law!
This
share portability in common. I can write an app in C, and run it on my server, laptop, palmtop, ancient SunServer, or even a Windows machine. The same goes for Java and C++.
.NET. Mono is a good start, but not enough to make my code reliably portable.
.NET is to make the platform compatibility promised by NT 4 available without opening the source.
If I use C#, I'm effectively locked into
C# has all the speed of Java with all the portability of X86 assembly linked to Windows libraries. Microsoft's BS patents will help ensure that the portability problems aren't corrected.
The real purpose behind
You can't judge a book by the way it wears its hair.
Anonymous Brave Guy, you're my hero.
Actually, in practice, no it's not and yes you can.
What you're ignoring is the "late optimisation" effect of virtual-machine and intermediate language execution models. The installer or run-time can take intermediate code and convert it to native code, just as a C compiler would, but with full knowledge of the environment in which that code is going to run. That allows for specific optimisations based on the execution environment that are rarely, if ever, practical for C-based programs. (How many C programs ship with different optimised executables for each Pentium and Athlon series processor, for example?)
You seem to be writing as someone who knows how things are supposed to work, who has a certain mindset and isn't prepared to look outside it. So-called just-in-time compilers actually have a lot of potential. They aren't, in general, as fast as something like C or C++ yet. However, in theory they could actually be faster once they've matured and caught up, because they can do all the same low-level optimisation tricks as a C or C++ compiler, with more knowledge of the target environment to get the best out of them.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Hah! Writing anything in c or c++ is a total waste of time. Instead of getting good coders, you get these hot shit young-uns who think they know everything.
Dammit, machine language is the only real language - put some hair on yer chest, boy (or gal)!
http://www.icsharpcode.net/
It's still rough around the edges (some parser bugs in the syntax checker) but the team is very responsive to bug reports and suggestions. It's got real potential. And it's GPL, so get in there and help them out!
ERROR 144 - REBOOT ?
Programmer cycles are much more expensive if your end product runs too slowly to be useful, and nobody buys it.
Performance still matters in a lot more areas than many people seem to give credit for: scientific apps, graphics, high load server work, firmware and instrument control software, games of course, any smart AI, heavy duty data processing... If performance for other things really no longer matters, why do today's applications somehow run as slowly on 2GHz+ PCs as they did on 200MHz boxes a few years ago? Sure, some of it is feature creep... but not that much.
When people say things like "performance no longer matters" and "processor cycles are cheap", I get the impression that the pinnacle of their programming expertise is writing UIs for databases.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
There is no mention of the memory settings for the java vm. I ran strcat4 with the default heap and saw 40% GC times. When I reran with a sufficient heap, the compiler had a chance to kick in and made a 50% difference. After increasing the eden size, I could avoid GC altogether and the times improved another 20%.
On the strcat profiling, there is no mention of the number of iterations, hence no way to verify the numbers.
Java uses StringBuffer, not StringBuilder. (last sentence, page 8)
In the strswtch example he cites 850K iterations and the java vm exhausts memory. Tell me the vm settings and I might believe you. I have one piece of framework code that does a 58 element switch using a hashmap to map the string to an int and then using that in a switch statement. It runs millions of switches per day and doesn't run out of memory. This approach is 10x faster than using nested if/thens as long as the switch is using consecutive ints.
I know the article is about C#, but every time I read something about C# I think to myself "I can do that in Python". Python is cross-platform, interpreted, object-oriented, fast, easy to extend with C or C++ and even more exciting for some people, usable transparently with Java as Jython.
I've found that almost all the programs I've written I could've written smaller and better and more obvious (and therefore easier to debug and maintain) with Python. None of those that I have rewritten show any noticeable performance penalty for having done so either.
Just wondering if you've dealt with it at all yet.
- Michael T. Babcock (Yes, I blog)
Clearly this kind of argument continues to promote zealousness amongst ourselves as developers. C# is faster than Java, Java is faster than C#, C is faster than C++ and so forth, when you realize that speed is relative in the computer world, this whole argument becomes moot. In order to avoid a lot of rhetoric that could easily be mentioned here, I regress. I will only say that attention to detail in any programming language yields good results.
My experience with C# is mostly on an academic level, I have never done anything *practical* in C#. Java and C are my languages of choice, and I have worked with a variety of other languages. Out of all of theese experiences I learned that any language can produce very efficient code for what it is designed for, kind of like why cars don't make very good boats.
Lastly... /. users can't seem show this as they are constantly yearning for the much *equality* with MS Windows and possibly Mac OS X.
Java and C# are both 4th generation languages, which means they are generally more disconnected from the CPU's native assembly language, and are generally made from another procedural type language. It is also noteworthy that 4th generation languages are more complex and in terms of mainstream age they are still quite young. Since 4gl are in fact young they should be given a far greater window of evolution to grow and stabilize with. Java is still fairly young and volatile, JDK 1.1.8 was hardly usable by any sense of the word and JDK 1.2 was released in roughly in 1999-2000. C# having the advantage of knowing Java's mistakes will not likely suffer the same roadblocks and stumbles as Java, it could in fact encounter new roadblocks which Java can learn from and viola you have a nice competitive and reasonably fair environment where you have options and choices to do the best job to suit your needs. It is funny that
try out Anjuta it has native supprt for the mono project when you want to run your program from within the IDE. www.anjuta.org
Hey, are you coming on to him? :)
The conclusion, as ever, must be that good programmers can do well in any decent language, and bad programmers will shoot themselves in the foot in any language.
The great irony, of course, is that a big selling point of Java was its ease of use. They took out all the "over-complicated" bits of C++, to make it faster to learn and less prone to programmer errors. If you're going to get the same sort of problems coming up in Java as in C++, you might as well stick to the latter and at least make the power and flexibility available for the good guys...
(I'm only considering that specific selling point here. Obviously there are other relevant issues to consider when choosing which language to use as well.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
the default random class does not provide a robust random number generation. This is very easy to test. Generate random number between 1 and 30K for 5K times. The result is repeatable. To get better random number generation, you have to use a win32 native library or something else. This would indicate a pure C# library for encryption would be weak and is easily compromised.
You mean all the way back 1994-95 era computing? sheesh. You work in a museum.
Translation: Today they are used to butcher a perfectly fine language and add new impediments to understanding.
Show me on the doll where his noodly appendage touched you.
i have been looking into learning c++ or java (i've known c for about 5 years). the unclutteredness (from what i've gathered) of java had me leaning towards it.
;) with java. java apps are only as portible as the jvm is ported. netbeans is unusable on my alpha (running linux, btw). i tried kaffe, but it's even slower - it only uses one thread per java app!
.net/mono will be much different.
until i tried it.
i have a dual 833 alpha, and even compaq's 1.3.1 jdk makes it run like a 386. part of this is compaq's fault (my 333mhz ultra5 running solaris runs netbeans faster - and compaq's jvm is buggy). the other part is inherent (no pun intended
my other problem, of course, is hp's ignoring linux/alpha. there is no (and i doubt will ever be) a 1.4.1 jvm. not that i blame them a whole lot, since alpha is dieing.
back to c++. it's more portable than java(!) and way faster on alpha. not to mention, java seems to be adding more and more c++ features.
to conclude, java may be more ideal than c++, but at least c++ is usable! java has had plenty of time to mature, and is disappointing (at least to me). i doubt
Parents, just as you would ensure you children learn the best programming language to master the cyber-universe in, please don't stoop to nightmarish "musical instruments." If you aren't going to use modern instruments, then by all means teach the kids the classical ones. (shoot, just go to a Scottish Festival and load up on the various goodies there)
20 min of googling for replacements to no avail
well, 10 min of googling, 1 second of pre-ordering TTT:Special Edition, and 9:59 of wandering off into something totally unrelated, then absently realizing I was in the middle of submitting a post.
if you were game developer , would java swing be your language. NO. For you and your science program, it fits. Got to disagree with you on swing though.
Yes , i used java on a Pentium 5 2.6 ghz and it was good.
But startup was not.
And why does java have to be used and nothing else. A programming language for each problem ? !
Not eevn colse
No, it is not the be-all end-all of programming languages.
There are none of those. They ALL suck.
I have been a well paid programmer (yes, even in today's economy) for 20+ years. I have used VMS, DOS, Windows whatever, Macs, and various real-time OS's as platforms. I have used BASIC, Z80, i860, FORTRAN, ALGOL, C, C++, C#, VB, and countless scripting languages (including the write-only language known as Perl).
They all suck, and I like it that way. I get paid more because of it.
If your PHB could just ask the computer do do what he wanted, I would be out of a job.
Bottom line: Different languages for different tasks. If I want to write a nice windows app, quick (and know the end user has the 20MB download for the environment) I'd not hesitate to use C# today. If I want a nice, small statically linked exe - you don't pick C#.
This issue is a bit more complicated than you think.
Yep. Although several other functional languages also have good macro facilities.
C++ templates are actually pretty useful; they're just incredibly hard to read.
Java generics are junk, to be honest -- they don't even optimize out the typecast. Basically just syntactic sugar.
Why would create a free account on the Windows Developer Website. Hell you can get the same effect by visiting the goatse.cx website.
Got Code?
Actually, Modula-3 has been doing that for years.
Try this:
Write a backend app in Java, and one with the same functionality in C or C++. Make sure they both read and write data to an Oracle database. Now, with stopwatch in hand, make them both run on Win2K, Cygwin, Solaris, and Linux.
Guess which language will allow you to finish first.
It is compiled Just In Time by the JIT compiler i.e. at runtime. Once an assembly has been compiled the machine code will stay cached and that is what will be called subsequently. Code will run slow the first time it is used after that it should be just as quick as a C++ binary. The reason the IL (intermediate language) is distributed is for portability i.e. a Linux .Net CLR (as if) will run the same IL as can run on Windows. C# is not interpreted like the old days, it IS compiled, just only at runtime.
Tell me that dude
:)
if java/c# is so great, why isnt there one VM running that handles the whole genome desktop with all its apps.
we could then have a 20meg genome install
oh and you wont see j2me on pocketpcs
Liberty freedom are no1, not dicks in suits.
Correction: generics are unglorified macros. Templates are glorified macros. Templates can add type safety at compile time with no runtime penalty. Generics macro expand their type safety into java casts, which incur a decent runtime penalty (especially for large container intensive algorithms).
Additionally, I once saw someone (saurik from saurik.com) use templates to do dynamic programming at compile time. He wrote an exponentially increasing algorithm to have an exponentially increasing compile time but constant run time when an arbitrary limiting value n was increased. Not actually useful, but still really damn clever and it illustrates the versatility of templates for meta-programming. And more importantly, I am pretty sure the same program is illegal for generics.
There's a firly good one out there... it doesn't compare to VS.Net 2003, but it serves its purpose, called SharpDevelop. Here's their homepage: http://www.icsharpcode.net/OpenSource/SD/Default.a spx
Hope that helps.
As someone who once did extensive work on a system that ran across nine different UNIX flavors AND both VMS's AND MPE (HP300), let me tell you that C "portability" is almost a complete myth - yes you can compile it everywhere but you are going to have a lot of ifdefs to maintain. Just look at any project of real size, like GnuMake or GnuEmacs. You always end up with some annoying architecture specific code.
I've done work in Java for a number of years and it offers very real portability much better than C or C++. I can develop on NT or my Mac and then deploy the same compiled code on UNIX without a hitch. I can also run GUI apps across platforms and they work, more or less (though there the portability starts to falter).
To make a long story short, the very worst problems of platform portability in Java are like a pleasant dream compared to the darkest dilemmas of the C programmer.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
C# is nothing to write home about: I don't believe any benchmarks that show it running alongside C++. OTOH C++ is a notoriously bad design-time language, so while the C++ developer is writing code, the Java developer is testing the final product.
C#, C++ and Java are all 3rd-generation languages no better than C. Until the vendors step up to the plate and deliver something similar to the old "4th-generation" languages, productivity will be in the basement. If I were an optimist, I might believe that this is the chance for the old "5th-generation" languages to enjoy a revival.
I forget which game exactly, but one major game at least (overhead forced perspective 3D) action game dealing with vampires used Java for the AI portions of the game, and seemed to have no problems.
:-) ) - and Java can help out for those parts.
I think there might be at least one other, but I can't remember anything more specific.
There's more than just a 3D engine to a game, you know (unless you are ID
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I love my Prolog!8-))
(define (lisp-fanatic? username body sig)
(and (map (lambda (text) (string-index text "lisp")) (list username body sig))))
Why be stupid in public? Oh, you linux fatties...
Book 1: The Silent Void
1.2
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
KFG
For Java, there is ProGuard, which can shrink and obfuscate a jar (or just shrink, or just obfuscate). The shrinking works by stripping out classes and members that are not referenced (directly or indirectly) by the entry point (main()). Obfuscation also shrinks things further, by shortening symbol names.
There are others, but ProGuard looks like the best free one.
I don't think this really saves memory though, it just results in a smaller .jar file. The Java classloader does not load the whole multi-megabyte runtime into memory all at once, it loads and initializes classes as they are referenced. Unused classes are neither loaded nor initialized.
IOW, go read how blitz++ works and hang your head in shame that you said Java generics are up to matching C++ templates.
-pyrrho
I posted this already... go see how blitz++ works.
It doesn't make the language butchered in the least, quite the opposite, the end result is very clear to use and the confusing part is hidden inside the classes, where it cannot cause trouble.
the thing about C++ is, sometimes things are hard, but the reason you do them anyway is because they are worth it, and you can get high levels of abstraction (arbitrarilly high) without taking runtime hits. You have the ability to control your overhead, templates are a great example, especially the examples the parent poster mentions, expression templates, and high performance math libraries.
Blitz++ uses templates in an elegant, mind blowingly cool way. It might not be clear how it works to many, but that doesn't change how it works. Truly beautiful. And it makes the code easier to read, not harder.
-pyrrho
Try fltk
pyrrhonist, as in The Outlines of Pyrrhonism?
-pyrrho
Say you have two apps in a crowded app category.
One is written in C and is hacky, memory leaky code.
Another is written in C# and is garbage collected and cleaner to read. For argument lets also suppose this one has a few more features.
Now, if they are both free, then one thinks the superior product wins.
Actually, not always. Since one app is managed code, it by definition has less control over how memory is allocated. All it takes is *one* "power" user who notices that the managed app has a working set size of 28,000K, and they immediately post "OMG SO BLOATED!!!!!!" on some bulletin board. Misinformation like this tends to spread like wildfire, and soon you have joeuser298182131 on slashdot saying "no way would i ever use that memory chugging program" and being modded up informative.
Differences with how memory is treated in managed code will not be easy to train to the power user group, which prides themselves on their knowledge of computers but can be resistant to changes like this. Remember when ACPI first came out? We were told that "IRQ SHARING IS VERY BAD!" Now no one even thinks about it.
In time our metrics for 'good' programs will change. Personally I think that even many unmanaged programs use up way too much memory for what they do.
A couple of these replies suggest that my original point was that good programming is sitting around writing hand-optimized assembler. Not at all. I totally agree that a great choice of priorities is to focus on excellent compiler design. I totally agree that no developer should have to worry about which instruction is faster -- other than the compiler writer, or somebody working very close to the hardware. No arguments. I always liked the famous comment by (I think) Alan Kay: "An operating system is what the language designers left out of the compiler. There shouldn't be one." Or words to that effect.
My point was that we spend too little time on high-quality software. Some individuals do, but as a field we sadly do not. Well, actually 'sadly' isn't right. Your comment about moving targets, priorities, and where to spend your budgets is quite correct -- it's not wrong to rely on faster hardware to fix our software problems. If we have the cubic inches, we should use them, for sure. But the price we pay for poor quality is in the thousands of security holes, endless Windows service packs, nonorthogonal languages, cheesy user interfaces, missing features, poorly-thought-out feature sets. No time to do it right, must get it out the door.
Back to compilers -- there are indeed some decent compilers being written today, but I think most of the interesting strides in compiler algorithms were made 30 years ago. I think that our whole approach to language and compiler design stagnated, and perhaps regressed, for a couple of decades. Or how about data management! How many applications are built today by folks with no clue about how to normalize relational tables, nor any understanding of the mechanics of a database? Most of the data structures I see in production use today are crying out for help -- for skills that used to be much more common among practitioners. We've dummed-down our methods to a lower common denominator.
My feeling is that the overall direction of software practice has been coopted by a quick-and-dirty mindset that discourages us from investing in good architectures, good designs, good documentation, good test plans...good engineering.
There are plenty of exceptions, of course. But back to my original point: when hardware stops being so cheap (i.e. when the rate of improvement drops) we'll again have a reason to focus on building smarter software. And we will.
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
Your story about good C++ programmers being shitty Java programmers is complete crap. They must have sucked at any language they used. Any good C++ programmer WILL BE a good Java programmer. Why? Because C++ is a fucking difficult language. If you can master that, then you can take on any language - especially one as simple as Java. Save your bullshit for your boyfriend.
EBay moves from a 3.3 million line C++ ISAPI DLL to Java, and now handle a billion transactions a day. YMMV.c es/cont ent/sf2003/conf/sessions/pdfs/3264.pdfr vlet.java.sun.com/javaone/sf2003/conf/se ssions/display-3264.en.jsp
j sp?thread= 8142
http://servlet.java.sun.com/javaone/resour
http://se
Other case studies:
http://www.artima.com/weblogs/viewpost.
Rick DeBay
You must not understand C++ templates very well, or you'd never compare them to Java generics.
The only thing the two have even remotely in common is their abstraction properties, which still aren't all that similar. Generics provide abstraction for abstraction's sake, maintaining it all the way through runtime where it causes a performance penalty. The only thing generics do is correct a casting problem inherent to Java, and at a runtime cost to boot.
75% of eBay is J2EE code. They started off on .Net and were highlighted by MS. But mid transision they ran into a brick wall of .net promisses != features... Anyway they started over with J2EE but used a compatible infrustructure so when you access the web site you get portions of the old C++ code and portions of the new J2EE code. They talk about huge improvements in scalability, features and performance.
You obviously only programmed "simple servers" transaction management (not simple DB transactions), threads, communications protocols (even TCP/IP, winsock...) are not easy to port. The advantage of J2EE is also portability between application servers that ofer features you probably can't even imagine if these are the things you claim.
.Net supports 20 languages on top of the CLR and the JVM supports over 60 (such as REXX, Python, Basic, JavaScript etc...).
You fell for marketing hype, MS emphasized this ability which is not truely different since their VM is very much fitted for C# and didn't fit VB at all so it had to be changed in huge incompatible ways since VB.Net is nothing like VB.
The adoption of C# by the industry cannot be said to be a good thing. Developers, who mostly program for Windows, may not mind it. However, from a computer industry point of view, it isn't so good. Will C# ever take off on Linux or Mac or whatever? Nope.
Sivaram Velauthapillai
Sivaram Velauthapillai
Seeking the meaning of life... @slashdot of all places
I just posted my comment, because some people really revile metaprogramming techniques. It was a bad joke.
Blitz++ uses templates in an elegant, mind blowingly cool way.
That's what scares the crap out of me. ;) I've got it bookmarked now, so I'll check it out.
It might not be clear how it works to many, but that doesn't change how it works. Truly beautiful. And it makes the code easier to read, not harder.
Hopefully better then the way ACE uses them. Man, that thing was a pain to debug. It also took several hours to build on a Sparc with the Sun compiler because of the templates, AND I had to add swap. Sheesh.
Show me on the doll where his noodly appendage touched you.
Currently there are C#, C++, VB, and even Java
.NET framework correctly, there is no way to support either multiple inheritance or templates--in which case C++ cannot be accurately modeled in .NET. Nor will Java be .NETtable after 1.5, which will introduce pale imitations of templates (but imitation enough to give the CLR a hissyfit).
.NET CLR does not support multiple languages. It supports one language--C#. Its "multiple language support" comes from being able to compile down many functionally-identical languages with different syntaxes down to the same bytecodes.
.NET supports are those which are subsets of C#. And once you realize that, .NET becomes much less interesting.
.NET much in the last few months. Last I checked these things were true, but after being very unimpressed with .NET I haven't kept up with things.)
If I understand the
The
But truly different languages are not representable in the CLR. Show me how to do a Scheme continuation in the CLR, please, or export a C++ template, or a LISP macro.
The only languages
(Warning: haven't used
But the .NET Class library is incomplete and immature to the point of frustration. Two bits for somebody who can tell me what class will allow me to browse for a directory without interfacing with COM.
I won't say that Java is right for every task, but I don't think you have a good grasp of how it is normally used, and what it offers.
I spend almost all of my time nowadays working with Java (mostly server-side, but also a few GUI apps), so I can clear up some of these confusions with good examples.
Portability - Server-side Java, by nature, does not involve any OS-specific activity. So, with no loss of portability or functionality, you could do the same in C/C++. Which, incidentally, will run on any platform for which GCC exists - About 30 *times* the number of platforms for which a JVM exists.
I ported a large J2EE application from OS/400 to win2K (for testing and development) and Solaris (production environment). The only changes required in the application were updating some properties file (different JDBC database connection strings, logfile locations, etc.), and some changes to embedded SQL (for differences in database syntax). That's it. Once those glitches were ironed out, I could deploy updated, compiled code to either platform by just copying out the updated JAR files.
I'm doing the same thing now with an even larger application, where I use a win2k server for development and as/400 for test and production. You're *sure* I can do this safely with a C++ app? Let me point out as well that the only bugs that have shown up on one OS but not the other have all been either configuration mistakes, or database issues.
JIT? Server-side apps also tend to have very short process lives, doing a small task and exiting. In such situations, JIT causes worse performance, as it wastes time optimizing something that will never execute again during this process' invocation.
What server apps are you talking about? Old-style CGIs? Utilities like grep or wc? I'm talking about the big server apps (the server half of client/server), where performance really matters. Never mind Java - if you're writing these in C/C++, you'll be using threads instead of dropping everything and needing to reload all of your resources, reconnect to the database(s), etc. on every client request.
In theory (skipping over hardware maintenance, some kinds of code changes, etc.), most server-side apps don't need to ever go down. A lot of application servers now allow hot code swapping, so they can stay up forever. That's exactly why Java is seeing so much use on the server-side -- it fits that model perfectly by costing a little more in the startup time (where it doesn't matter) for benefits later.
There are a lot of limits to talk about re GUI programming -- the portability factor was a much stickier issue there in AWT, and Swing just turned the apps into nice-and-portable memory hogs.
But the server-side benefits are hard to fault. Obviously I'm biased, but I think most developers would agree with me on these points alone.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
There is an open source alternative IDE for .NET called SharpDevelop, which you get at http://www.icsharpcode.net.
It is not as good as VS2003, but quite near :)
Intelligence shared is intelligence squared.
And I believe CLR stuff can be compiled at installation time, making it even better than JIT.
Not necessarily! Some optimizations that cannot be done without runtime data. You can get some of this info by profiling (and recompiling with profiled data), but you can do better with realtime data. Here's one example of such a system: ADAPT (at the University of Toronto). There are probably others.
I have been using C# for the past 6 months on a mid-sized distributed business application with multi-threaded socket handling, web services, ADO.NET, and XML and I have to give Microsoft some credit where it is due. When one compares the features that are built into C# such as callback delegates, custom event handlers, excellent threading support, and the extensive class library provided with the .Net framework it is difficult to understand why anyone would want to write a new piece of business software with C++/MFC, or platform SDK and C. That being said, both C and C++ have advantages in niche application development such as drivers, operating system kernels, and the like but they are far to expensive to use and maintain except where absolutely necessary or in the largest scale projects. The Java question is an entirely separate issue since C# and .Net were designed, more or less, to directly compete with the features offered by the Java platform. They often speak about a concept at Microsoft which they call developer mindshare and how it can be extended and maintained. Now, I know that Java is frequently taught in Universities and C# is not...but think about it. If you are a new Computer Science grad in a tough job market then your odds of obtaining employment are significantly enhanced by choosing the C#, .Net, Windows route, rather than the Java, Sun, Linux route. Regardless of what you may think about Microsoft, the world uses their software and there are many more Windows programming jobs out there than Sun, Linux, and UNIX jobs. For my part I usually choose the route of least resistance when I write software and in my situation C# has been a good choice. I really hope that something comes of the whole Dot GNU project so that C# and .Net applications which compile to the Common Language Runtime can run on Linux too. In summary the features which I find most useful in C# are:
1. Excellent XML support including Xml Document Model, Xml Serialization, Xml Schema Validation, and of course Xml Web Services (this is VERY useful).
2. The combination of the Windows Forms with the power of a full featured c-style language. If you ever worked with C++/MFC or C with Platform SDK then you know that this was a long time in coming and a welcome relief.
3. Callback delegates - you never realize how useful these are until you start using them in your applications.
4. Advanced threading library including thread pooling, support for various synchronization methods, and easy to use asynchronous framework.
Of course, C# and Java compilers "measure up" in terms of simple benchmarks: they are statically typed languages, somewhat simplified from C/C++. They don't have pointers, but pointer manipulation does not speed up code with modern compilers on modern architectures. They do have garbage collection, but garbage collection is generally at least as efficient as manual storage management. Many library routines (string handling, etc.) are coded in C or assembly anyway. The only places where there is potentially more overhead is in a few more places where they do error checking, but that overhead is a few percent at most.
The biggest difference between C/C++ and Java is probably in terms of memory usage. Java slaps a three word (!) header onto every object. So, an array of one million structures consisting of two shorts each takes 20Mbytes in Java, while it only takes 4Mbytes in C or C++. In C#, you can avoid that overhead by using value classes, although for heap allocated objects, it still uses more memory than C and probably C++.
These days, the real question is how these language "measure up" in terms of facilities, and that does have a profound influence on performance. Both languages use read-only string types, which result in enormous overhead for string manipulation code written in what programmers consider the "natural" common way. One can argue that that overhead is acceptable, but it is there. To avoid it, you have write your Java code completely differently. C# has value clases while Java doesn't, which means that writing a lot of scientific code is much easier in C# than in Java.
Libraries are another big issue. The standard Java libraries are inefficient in many places: often, their implementation is bad, and in many cases, the API simply does not allow an efficient implementation. I would guess the C# libraries are pretty similar, given that they are so closely modeled in Java.
Note that this is also a major problem with C++ libraries: the compiler can be as good as it gets, but if the libraries are designed and implemented badly, the resulting programs will still be bloated and slow. That's why so many programmers still prefer C: programming in C is such hard work that C programmers don't make their libraries very complex and general, and as a result, they tend to be more efficient.
With these high-level languages, the question is not whether they perform well on microbenchmarks--they do--the question is how well they encourage and support writing efficient code. Java downright discourages it. C# is a little better. C++ lets programmers write efficient code easily, but it also makes abstraction so easy that many programmers still end up writing overly general and inefficient code.
I prefer Ada's treatment of generics for the way it makes the use of the generic explicit. To make an integer-based stack, you'd declare a new type based on the Stack generic with an Integer as a type.
I remember when C++ got its templates (IIRC, that was in the 2.0 specification); it took compiler developers a long time to integrate the features. Before that, we'd put together token-pasting (##) macros.
Trying to track down troubles in a C++ template used to be utterly atrocious; define-at-first-use (e.g. first time the compiler encounters Stack<int> per target file) combined with the way the compile/link actually generated the templates behind the scenes made for... to put it mildly... a cryptic experience in a very long error log, usually at link-time. *laugh* Based on some more recent MSVC error listings I've seen, I don't think it's gotten much better ;)
(P.S. Does anyone know whether IBM has removed all the unnecessary #pragmas from their 'STL' implementation? :)
I'm personally interested in generics in any given language for a few reasons:
- Less typing
- Less typecasting
- Changes to the algorithm occur in one spot
- Type-safety at compile-time
None of those reasons make or break using a language. I've survived with and without generics for years on end.Java should do quite well by generics. They will be useful. C++ got along famously without them, but did better with them. Indeed, lack of them in a language is no indication that the language wouldn't be useful with them.
Delphi has no official generics, either, but just like C++'s old token-pasting, there are ways to do generics in Delphi, too.
Binary geeks can count to 1,023 on their fingers
AFAIK, the watcom compiler (openwatcom) has the best granularity performance. The compiler has a switch (iirc) which can compile automatically each function into its own unique object file when creating libraries. Then the linker only adds the code you actually use.
Ok, I agree with what you say relative to RAM... however...
Modern operating systems are going to do paging of these large loaded files. They don't care what functions you use, they track the usage of the memory by pages (4k ON I386 IIRC). So if you load a 8MB library (Windows DLL for example) and are only using 16K of code in it... windows will page out the unused part when RAM is tight.
It isn't a perfect solution, but it does solve the problem. Loading the massive libraries (paging them all in to init) tends to be the big hit.
Can I write in c#:
1 - a kernel
2 - a device driver
3 - a videogame
so that almost nobody will notice any substantial performance|system-load|code-size differences from the same code written in asm or c?
In other words, is this an application only language or a general purpose one?
Many Java API's are in fact implemented in fast native code. I've written a Swing application that loads 150 meg files over the network using Java NIO, relying on memory-mapped and random-access file channels. Behind the scenes these are implemented on the OS level. The user can browse around in the files and the display is updated instantly. Now, I understand that it might be *slightly* faster in C/C++, but is it worth increasing my development time by a factor of 2 to 5? No way!
All comes down to the fact that we still need hand-optimize code to get computers to do something reasonable. Nowadays, most software engineers are not aware of the memory piramide. At the top we have a little very fast memory and at the bottom we have a huge amouth of memory which is relatively slow. The differences are in the order of 10^9 (if you include the Internet).
Computers spend most their energy in moving data in an efficient way between different forms of memory, and managing available memory. This has lead to incredibly complex systems, beyond the comprehension of a single individual.
And it would not surprise me if some CPU's have a single instruction for doing this!
Though I have coded in various environments before, back-ends is where I usually try to end up at, so I speak mostly from experience there. (Also, only with C, C++, Delphi, Java and Python).
:)
:) 3rd party code is ALWAYS a pain. Open source code is much better. The *other* reason Java Is Good (tm).
Java and C++ are alot cleaner than C when it comes to managing a large amount of code. Namespaces help alot.
C++ I don't like because of all the rules I have to remember. Frankly, it's just too much.
Java and Delphi (python aswell?) both have powerful standardized APIs, less sort routines to write.
Now, I think Python is a spunky language as well, and are finding excuses to use Jython in my stuff (I code java-things for a living), and writing Python scripts whenever I'm hungry. But I feel Java + Python have different problem-domains to tackle, IYKWIM.
So there you are.
Eat dirt.
When you think C++ is a nightmare and all code you've seen is a total mess, you maybe should start looking somewhere else. For example at the rapid progress of the KDE project. Btw, perhaps you should tell the Gnome team that using C is no good idea, maybe they just didn't notice yet.
I've done significant work in benchmarking Java programs versus equivalent C/C++ programs. I've found that garbage collection is the sole reason that Java is slower than C++; having a "virtual machine" imposes no performance penalty whatsoever. This is unsurprising, when you think about it; a JIT compiler simply moves the latter phases of compilation ("byte code->assembly") to runtime.
Contary to what many people think, even most traditional C compilers work by compiling source to byte code, optimizing the byte code, then compiling byte code to assembly. There's no reason to expect that the resultant assembly will be any slower just because the final phase is done at run time by a JIT.
Programs compiled using IBM's Java compiler routinely outperform equivalent programs compiled using "gcc -02", if garbage collection is not used in the Java program being compiled.
Since registration is required to read the article, I have not read it. But given the title of the publication I was alert to the possibility of bias, and I think it's quite strongly present in the introduction. Java is the platform against which .Net will be measured for the forseable time and I think that the choice of benchmarks in Part 1 strongly favour .Net.
.Net libraries can't do better than the Java libraries then I'm appalled.
.Net
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
string comparison, string concatenation, string tokenization
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with
Programmers of the world unite, you have nothing to lose but your strings.
Seriously, the MS EULA's forbid publishing benchmarks of any .net components unless MS approves of them. And this isn't even the .net EULA, its standard in all of their security updates.
This study shows C# isn't so bad... how many are being censored by MS?
Since Microsoft EULA forbids to disclose and/or perform any sort of benchmark on .NET I don't trust any performance roundup that pitches the Microsoft .NET platform against it's competition. Peer reviewed repeatable measurements is science, all the rest is just infomercial.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
On Wintendo only Microsoft compilers were lagging, Borland more or less was tracking the draft standard. MS products were a joke, MFC my ass, more like MFM (Microsoft Foundation Macros)...
First of all -- what's the deal with this whole "WARMUPS" thing? This is just the most explicit way possible of training the JIT mechanisms without measuring its overhead. That might be fine if you believe that the overhead asymptotically costs nothing, however, I don't know what evidence there is of this. The test should use other mechanisms other than this explicit mechanism to allow the language itself to demonstrate that the overhead is of low cost.
The way this test is set up, the JIT people could spend hours or days optimizing the code without it showing up in the tests. This is the wrong approach and will do nothing other than to encourage the JIT developers to cheat in a way such as this just to try to win these benchmarks.
Ok as to the specific tests:
1. FloatInteger conversion on x86 are notoriously slow and CPU micro-architecturally dependent. It also depends on your rounding standard -- the C standard dictates a rounding mode that forces the x86s into their slowest mode. However using the new "Prescott New Instructions", Intel has found a way around this issue that should eventually show up in the Intel C/C++ compiler.
This does not demonstrate anything about a language other than to ask the question of whether or not the overhead outside of the fi rises to the level of not overshadowing the slowness of the conversion itself.
(That said, obviously Intel's compiler knows something here that the other guys don't -- notice how it *RAPES* the competition.)
2. Integer to string conversion is just a question of the quality of the library implementation. A naive implement will just use divides in the inner loop, instead of one of the numerous "constant divide" tricks. Also, string to integer will use multiplies and still just be a limited to the quality of implementation as its most major factor determining performance.
3. The Pi calculation via iteration has two integer->floating point conversions and a divide in the inner loop. Again, this will make it limited to CPU speed, not language speed.
4. The Calculation of Pi via recursion is still dominated by the integer divide calculation. It will be CPU limited not language limited.
5. The Sieve of Erastothenes (sp?) is a fair test. However, if SLOTS is initialized to millions, and the comparable C implementation uses true bits, instead of integers, then I think the C implementation should beat the pants off of C#, Java, or anything else.
6. The string concatenation test, of course, is going to severely ding C for its pathetic string library implemenation (strcat, has an implicit strlen calculation in it, thus making it dramatically slower than it needs to be.) Using something like bstrlib would negate the advantage of C#, Java, or any other language.
7. The string comparison with switch is a fair test, and gives each language the opportunity to use whatever high level "insight" that the compiler is capable of delivering on. It should be noted that a sufficiently powerful C compiler should be capable of killing its competition on this test, however, I don't believe any C compiler currently in existence is capable of demonstrating this for this case. I.e., this *could* be a legitimate case to demonstrate that C# or Java's high level abstractions give it an advantage over where the state of the art is in C compilers today.
8. Of course the tokenization is another serious ding on the rather pathetic implementation of the C library. None of strtok, strspn, etc are up to the task of doing serious high performance string tokenization. If you use an alternative library (such as bstrlib or even just PCRE) you would find that C would be impossible to beat.
-----
Ok, while the results here are interesting, I don't think there were enough tests here to truly test the language, especially in more real world (and less laboratory-like) conditions. Please refer to The Great Win32 Computer Language Shootout for a more serious set of tests.
If you are looking for a real nice performance comparison of different languages, check out the The Great Computer Language Shootout at http://www.bagley.org/~doug/shootout/. Why I did not link it directly? Because it has a "slashhole"!
Templates and Generics are synonyms. The difference lies within a) what name a particular language chose to use, and b) the implementation within that language.
What you are talking about, I suspect, are pattern matching constructs. Those are found in Haskell, ML, and to some degree in C++ (if you are so inclined...), and probably in a hundred other languages I don't know of.
Actually I worry about this. I seem to remember that the template system is in fact turing complete and you can write your entire program in it, making the language unnecessary. Compile time is run time.
No, they aren't, because C++'s template mechanisms go beyond the generics applications. That's kinda the point.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
There are 2 open-source IDEs for the .Net Environment of note:
a spx
1. Web Matrix, an ASP.Net oriented IDE. Can be downloaded from:
http://www.asp.net/webmatrix
2. #develop, a more general IDE for C# and VB.Net. Can be downloaded from:
http://www.icsharpcode.net/OpenSource/SD/Default.
Both of these IDEs are only available for Microsoft OSs at this time.
3. A C# plug-in is available for Eclipse. It can be downloaded from:
http://www.improve-technologies.com/alpha/esharp/
It should run on Linux, using Mono.
Okay, I admit that I would program much slower while holding a stopwatch in one of my hands. OKAY?!
Are you sure about this? That would mean there must exist legal C++ code that will never finish compiling. I have a really hard time picturing code like that.
Sig:Why copyright isn't a fundamental human right
That's bull. I've found that for massive text and XML processing that Perl kicks C#'s butt, hands down. We're talking parsing a 200 MB XML file takes 5 minutes in Perl, using 6MB of RAM and C# took 45 minutes and 400 MB of RAM.
use CPAN;
Cable's Black and White
When are people going to learn that languages that target the Common Language Runtime (CLR, only part of the .NET Framework) compile to the same thing (Intermediate Language - IL)? C# is not being tested here. The C# compiler optionally optimized and compiles source code into IL which is later JIT'd and executed. Because of this, it's the CLR and the base class library (BCL) that are being tested.
This could just as easily been done with VB.NET (not that I condone anything resembling VB) or J#, although MC++ is a different monster because it can (but doesn't have to) use native code in mixed mode and, thus, is not verifiable).
The only differences besides language syntax is the specific language compiler and the optimizations it makes. The C# compiler does - as far as I've tested - a better job of optimizing. The VB.NET compiler, for instance, automatically adds an extra local var to support the syntax FunctionName = ReturnValue whether or not you use it!
So, let's get the facts straight. C# is not being tested here. The .NET CLR and BCL are.
The AIX linker loader combo are smarth enought to load only the functions they need. So it doesn't matter how much dead code the library has, it won't be mapped into memory.
Upgrade your Linux to AIX then...
How about Emacs.NET?
an ill wind that blows no good
Really? It is certainly possible to add a proof from the compiler that a particular cast is unnecessary, with the verifier checking that and then short-circuiting the cast. Article in Dr. Dobbs described it quite well a couple years ago. Even was backward compatible with old VM.
so your point is moot. Saying "Java would be fast as long as it did not have to collect garbage" is like saying "McDonalds would be a good restaurant if it did not serve all that fast food".
Java is essentially a statically typed compiled language (javac) not unlike C++. If you want a good and expressive garbage collected language use Python instead.
SharpDevelop -- www.icsharpcode.net/OpenSource/SD/
GPL'ed IDE, not (yet) as mature as Eclipse, but targeted specifically towards C# development, and very usable. It even has a GUI builder. Highly recommended!
F# is not Fortran, but a CLR implementation of ML. Of course, this required a few extensions to the VM, but the point of the exercise was to show that it wouldn't be hard to add functional language (hence the 'F') support to the CLR.
aQazaQa
Languages that are conceptually different from C# have to make compromises to run on the CLR. They aren't quite the same language after that. That's why they get names like Scheme#, etc. The parent post is not as ill-informed as yours is.
The parent post is only ill-informed about Lisp macros. Those are done at compile time, and there's nothing about the CLR that would preclude them. However, the parent post was dead on about Scheme continuations. CLR changes to better support continuations have been "coming soon" for the past couple of years.
Microbenchmarks about string concatenation and method calling are mostly irrelevant. What's important is too see how an implementation scales up to huge programs, say 500,000 lines of code and 1GB of data. There have been plenty of cases of fast languages not scaling up well (like C++), because you have to add so much cruft to hande the kind of problems you hit at that level, and much "slower" languages outrunning them because they were architected for that kind of problem.
One interesting case is Yet Another Web Server (YAWS), which is written in an interpreted language and completely blows the socks off of Apache under high load.
Can I run a C# on a Unix platform?
It's all fine and dandy to say that, with Moore's law obviating the need to be careful.
That is, up until the point when you have to write some code for a Palm device, or a cell phone, or even a wristwatch. Then all of the old virtues become relevant again.
BZZZT! Wrong answer. Thanks for playing.
Talk about a typo making you do a double-take. Thanks for the visual. Now I'm imagining deer with runny noses trying to drink coffee.
--JoeProgram Intellivision!
Now, in response to the above thread, the type system in Java was a deliberate choice, not "a bug." Sure, it's ugly. Sure, it's inconsistent. Howevever, it's been extremely successful--it was more in appearance like C++, so that businesses were more quick to adopt it. Smalltalk and Lisp have been around for decades, but how many businesses out there use them?
Anonymous Brave Guy is correct, generics are NOT templates, or even close to their "power." A lot of people are really into power. One can stockpile their home with bigger and bigger armaments; personally, I'd rather not live with a few live grenades under my pillow.
You see, I have also been in the receiving end of having to debug C++ templates. You can only lose so many brain cells doing this intricate exercise before realizing that what efficiency and elegance was gained during development was lost many times over during maintenance. It's very sad but true.
I've seen C macros used and abused to redefine the language until it wasn't even C anymore, and I've seen C++ templates overload the syntax of operators until a pointer wasn't a pointer anymore and you have no idea what you are looking at or even what
means. The real question is, why would anyone in their right mind want to, especially when so many easier options exist?Its sure not ready for my set top channel guide. That thing was programmed in Java and it takes me 90 seconds to scroll through all my TV channels.
When you guys write java applications/applets, do you state they need a certain version in order to run it? I coded a simple web application that worked well within Jdeveloper but when I loaded it into tomcat I had a ton of trouble with different browsers and I can only assume that if I actually made this accessible to the internet i'd have a dozen different browsers and versions of the jre trying to connect.
How do you get past those issues?
And also, i've had tons of GUI issues between linux and windows. For some reason the fonts used in linux are larger and it makes the whole thing look messy.
"Thanks to the remote control I have the attention span of a gerbil."
This is not exactly an accurate test. In many cases the author states that since the "stock" version of the feature runs slow in C/++, he has provided a replacement.
Any truly accurate test would have to ignore most of the "stock" implementations in all languages. The composer of the study would also have to be equally skilled in the languages, for the test to be accurate.
It would also be good to know which JVM he was using to test with. I assume it is the one he used to compile with (JDKSE 1.4.1-02 by Sun). The Sun reference versions have been shown in other tests to be inferior to implementations by other vendors. As we can see here, different implementations have VERY different performances.
To sum up, while this may be a fair comparison between C# and the C derivatives, it does not seem to be an objective study of ALL of the langauges tested.
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
"If you didn't already know that, please read it again and understand it before proceeding."
.. structure if you wanted to use that structure again. Make no mistake, C++ did not have this feature originally. They were a response from the OOP community that the language had thereby not very useful. OOPs which promises re-use wasn't there yet. The language actually fought re-use. It was added so that it could patch a serious deficency in the language against other languages like Smalltalk that were competing for OO programmers back then. The strong typing of C prevented C++ from being a serious language because of this lack of re-use. So Template were needed to make C++ viable and people have found that the way there were implemented that you could use it for things it was not intended for. Which means of course that there is no hope of fixing the problems with template (oh sorry features) which allow it to be used for compile time metaprogramming. It as a language feature acts outside the language more like a pre-processor exention.
Well there is that effect of a people taking bad language features and accepting them as good things because they can do very clever things with them which are un-intended conscequences of language features.
The new Java generics are not a macro capability. They are actually integrated into the language and are just a syntax with symantics. There are no macro/pre-processor side effects nor opportunities like C++ Templates have.
Some of the issues you might consider are what object oriented programming means vs. what strong typing means. There are some languages that combine the two but others that don't. They are different features with different goals.
Smalltalk is Object oriented with objects having a type and respond to services. Its clean, expressive and tremendously powerful. I would say many times more powerful than C++ in its power to express ideas simply and cleanly. Variables don't have type, they don't need to, objects have type from the class they are an instance of. You don't need templates, you never needed templates.In the object world template are meaningless. You do, however, have to adopt very good discipline to not have runtime errors, but those runtime errors are relatively soft and harmless.
In a Dynamically Typed language like Smalltalk, you can have a collection of object (of different types, in object terms thats just different objects) without trouble. Maybe you have different business objects that you want to queue up and process. You don't need to have them all from the same class (or ancestor class, base class for you C++ only programmers) to put them into the queue. You don't need to have them service all the same messages to put them into the queue (this is a requirement for strongly typed languages, you use downcasting to get around that). You can ask the object what it is and route it or use double dispatching to do that in a more OOPs way. That is a much more powerful scheme that the 2 dimesional one that the strong typing places opon you. Your entire system's design is controlled fundementally by this strong typing requirement. You give up so much power to have the safety of strong typing. Programms written in OOP's system with strong typing and without are very very different.
So strong typing in C++ came from C and is a non-object oriented technique/restriction on the language to try and move some potential programming errors from run-time back to compile time. So I am sure we would all agree that this feature in C and in C++ has made those coding environments runtime bug free. (pause for laughter).
Templates are a way for C++ to have a facility that to not have to copy and retype every damn queue, stack, list, tree
Java on the other hand adopted a more purely Object Oriented approach, with every class having a common ancestor class (in C++ you for some reason call it a base class, whats that all about, well windows calls them folders not directories..) the Object class which
one.cc:
#include "two.cc"
two.cc:
#include "one.cc"
Of course, this will cause a precompiler stack-overflow, but of course, to be Turing-complete assumes a machine with infiniate storage.
-- And when Justice is gone, there is always... Force. --Laurie Anderson, "Oh Superman"
>I guess any language ends up indirectly making you think in a different way. Maybe that's the magical part.
you are correct but let me clarify.
I claim that C/C++ never takes you away from how the machine works... the way it makes you think is "like the machine thinks"... so it can introduce OO concepts, but not to the point they conflic with how the machine works.
-pyrrho
I had the pleasure of taking a class on skepticism from Benson Mates at Berkeley, while he was finishing his translation of Sextus' Outlines of Pyrrhonism...
Ok, it's a little tacky to name drop in general... but cool, eh?!
-pyrrho
Indeed. That effect is responsible for many of the most useful advances in programming technique since forever.
One might argue that, but it wouldn't have the same relevance. C++ is designed, from the start, to be a multi-paradigm language. By Stroustrup's own admission, templates probably should have gone in earlier. However, as it stands today (and has for many years) C++ is not a purely OO language, nor meant to be one. Keeping the fundamental types clear of the OO baggage is one reason compiled code in C++ can be so efficient.
Java, on the other hand, has hyped OO from day one. It maintains that everything is an Object, and non-OO programming is inferior. Hell, for years, Java evangelists have claimed that templates are a bodge and they don't need them. In that context, having your primitive types not being Objects is just plain out of place. It leads to rather absurd concepts like the wrapper types, and those in turn to "boxing", which is a poor man's excuse in a language that doesn't properly distinguish between value and reference semantics.
I'm afraid I'd like a little more credit than that. I've been using C++ for more than a decade and Java for several years, and I've got more than a passing familiarity with ML, Python, Perl, various assembly languages and several more besides. I have an active interest in language design, and am familiar with a lot of the background theory, including structured programming, lambda calculus, formal type deduction systems and the principles of OO.
And by the way, you seem to confuse the concepts of strong/weak type systems with static/dynamic ones. There's a very significant difference, and all four combinations are possible.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Straight from Microsoft's own propaganda:
It's true that debugging templates can be a royal PITA, but that's really down to the quality of your development environment, and things are improving. The thing is, you only have to debug the templated code in your library once, and then you get cleaner higher level code forever -- and that cleaner code is much easier to debug thanks to templates and operator overloading, because the logic errors are easier to spot.
Incidentally, anyone who uses Visual Studio might care to note that you can do a lot with AUTOEXP.DAT to simplify debugging when working with complex UDTs, templated or otherwise.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Something like this ought to do it.
template <int N> struct Counter {
static const int value = Counter<N+1>::value;
};
I guess you'll get integer wraparound in the compiler breaking that eventually, but if you had arbitrarily large N available, as Turing-based stuff pretty much implies, then it would recurse indefinitely, no?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"However, as it stands today (and has for many years) C++ is not a purely OO language, nor meant to be one. Keeping the fundamental types clear of the OO baggage is one reason compiled code in C++ can be so efficient."
This is true, but I would counter that C++ was never designed to be a purely OOPs language.
"templates probably should have gone in earlier."
I agree that the templates gave C++ something it lacked and made it a viable language for OOP type development. It also allowed re-use and with the STL some form of collection classes. Which are needed if you want to program at any level above assembler c-esk programming. Much of C++'s strength comes from its ability to couple these to very different paradigms. This is especially useful when you are writting code that has to have maximum performance. That perfomance is often a compromise of good coding practice.
" It maintains that everything is an Object, and non-OO programming is inferior. Hell, for years, Java evangelists have claimed that templates are a bodge and they don't need them. In that context, having your primitive types not being Objects is just plain out of place"
Well it is the paradigm and most any system can be coded as a series of ADT's as a veiw to algorithm creation. That everything is an Object really comes from Smalltalk for with everything really is an object from the programmers point of view. It is the compilers choice (an ADT if you will) to implement that more or less efficiently. Java having primative types I feel was a hold over from C++ and made some of the compiler choices probably simplier. After all it was originally designed for set top boxes.
"It leads to rather absurd concepts like the wrapper types, and those in turn to "boxing", which is a poor man's excuse in a language that doesn't properly distinguish between value and reference semantics."
Well this is true but gate back to my other comment about the compiler as and implimention of the ADT that is the language itself. It does not matter really what it does as long as the contract you have with it is maintained about the expected result. That is the compiler creates a program that is logically and/or mathematically equivalent to what you said you wanted done. The new autoboxing will make that disappear from view as it should. This feature like C++'s template should have gone in from day one. But you know what perfect hidsight looks like.
"And by the way, you seem to confuse the concepts of strong/weak type systems with static/dynamic ones. There's a very significant difference, and all four combinations are possible."
Well I don't really confuse them but thanks for pointing that out. C++ also allows seperating what I term "data polymorphism" from "functional polymorphism" i.e. allowing a variable to point to different objects, but some of the behaviour are not overridden by the sub-classes code. So you can get all sorts of combintions of questionally usefull and complex relationships in your programs. I think of it as OOP's rococo.
I prefer to keep the model simple. It is much easier to write, understand and maintain.
I appologize for my critcism of your being young. but I do feel that your programming world revolves around those application and problem domains for which C++ is a good fit. Mine does not and never has been. In that I have been involve in application that solved problems quickly or problems that needed to added to or maintained over relatively long periods of time. (you know those projects that started out as only to have 6mo lives but end up many years later still useful and in use). For what I do, the OOP paradigm saves much time, the language features in Java such as garbage collection mean that I don't have to spend time engineering things that have absolutely nothing to do with the task at hand. The OOP's modeling has a close fit for the problems (business problems) that need to be solved. So my experience comes up through, Fortran, algol, PLI, C C++ Smalltalk, Java, and all the side languages and scripting as well.
The question wasn't directed to me, but I hope you won't mind if I chime in here.
Modern C++ allows you to cut out whole classes of errors by following just a few simple rules. If you're interested, here are some starting points to consider.
If you're interested in learning how to program C++ safely, cleanly and efficiently, I promise you that all of the above are worthwhile investments of your time. When you're done, you'll find it even more offensive that so many C++ programs have memory leaks, buffer over-run vulnerabilities and seg faults through following NULL pointers. Your programs won't, though.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Sometime back, I had posted a review of a 1999 interview of Anders Hejlsberg.
- The Visual Studio IDE isn't as good as eclipse. In fact when I think about it, it sucks.
- The IDE's refractoring is no existant. This is fine if you're copying existing design/code or working on something Mickey Mouse.
- Define an ArrayList add two items. Now how many items do you think will be in the set. 2? Nope, some other amount. And therefore you constantly need to TrimToSize to the empty items. This sucks big time.
- Threads. Better than Java is some fringe areas, but far worse in key areas. Like how threads aren't reuseable. This leads to more code. Sucks again.
- foreach is ok. But big deal!
In summary, C# is just like Java, renamed and changed slightly, slightly better in minor ways, and really overworked and dud in key areas. I perfer languages/libraries that are clean, simple and logical. C#'s aren't.
There's no way Microsoft developers use this or SourceSafe!
> We could have had a modern Multics. Instead we have VMS (AKA WinNT) and Unix, all over again.
Exactly. I've said the same thing in the same words. In those days, the pace of hardware advance was largely managed (and shrouded) by IBM. Their hegemony, like Microsoft's, shaped the development of the industry. We pay the price today.
Though I'm not sure that the practitioners 'missed the ramifications' of the advances, as you say. We saw that new, faster CPU models came out every year; that memory footprints expanded rapidly; that DASD got bigger and faster. We saw small computers come onto the scene, first with 4K, then 8K, then 32K. We saw bitslice microprocessors arrive and said "Damn, with some AMD 2901's I could build a perfect instruction set." We realized that the little machines would proliferate.
But being able to glimpse the future doesn't mean you can change it or profit by it. Suppose you and I and a few pals had sat down and BUILT that 'modern Multics' you mention. It would probably have been squashed by market forces, the same fate of many promising systems. Our investment would probably have gone down the tubes. We would have been better spending our time and money on a BASIC interpreter.
For example, in 1979-82, two partners and I built what today would be called an object-oriented message-passing microkernel multiprocessor operating system. This was not an academic project but a commercial venture. It totally kicked butt. And it totally died as a business venture. Oh well. The Ellisons and Gates of the world always triumph. <sigh>
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
that's why C has been called a portable assembler, and C++ mol follows in that vein.
All the power of machine code, but you get to use function names, structure definitions, class syntax, type checking... etc.
C/C++ do a lot of that nasty work involved with machine code (and indeed, most assemblers also provide some such features, but far less than C), such as working out the offsets and aligning for structures.
It's called the best of both worlds.
-pyrrho
I tend to prototype using STL and then redesign performance critical areas.
The good choice of design patterns help reduce the complexity and bug count.
Heigh performance/ low footprint techniques such as copy on modify and lock pre-emption can ?easly? be coded in C/C++, but you need a whole framework that is far out of the reach of STL &co.
thank God the internet isn't a human right.
(That, and you like LISP!)
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.