Your obvious bias against Microsoft has slanted your views on an excellent platform.
C# is a *super-set* of Java, meaning it has more features.
Also, C# is far more standardised than Java will ever be, even though pundits have attempted to get a proper Java specification in the works lots of times.
The only half-way decent XML serialisation I saw for Java was something a company offered as commercial software, and it still didn't come anywhere as close to the way C# handles XML.
I like Java. I also think Sun has done excellent things for the open source community (mainly OpenOffice), though it is still an old school UNIX hardware company at heart.
It's just that C# exceeds the performance and functionality of Java in most cases, now on the Win32 platform, and other implementations are rapidly catching up - mainly due to Microsoft's surprisingly open standards.
I have used both a fair amount. My previous job was writing Java business web applications, and I am currently managing the development of a C# webservice (for the server) and a C# winforms client.
Let's start with the picture from 10,000 feet: C# is aimed squarely at Java, and for all intents and purposes, it is a superset of Java. Similarly for.NET and J2EE, though they are less similar than the language comparison.
Language Differences:
C# has less integrated threading support. (which is a bad thing, imho)
C#'s XML and SOAP integration make it/ideal/ for any application dealing heavily with either protocol. In fact, I would say that it is nothing short of brilliant.
Java's XML integration is a nightmare. JAXB is the only thing that comes close to being halfway decent, and it still doesn't come close to the integration C#. XML serialisation in C# is fast and beautiful.
C# gives you far more control over the dynamic reloading of classes, as well as increased security through what.NET calls 'AppDomains'. This is a very powerful feature.
C# documentation isn't quite as nice or refined as the standard javadoc fare, but MSDN is a pretty nice source, though sometimes you have to look a little harder or deeper than you would with the javadocs.
In general, both APIs are very clean.
As for maturity, I don't really think that's an argument. Most of the Java technologies available now (especially the XML/web services bits, in which the competetition is most fierce) are no older than.NET/C#.
I think the larger question is the underlying/platform/ maturity, but I will leave the zealots to argue Windows vs Unix.
Do you feel comfortable locked into a Microsoft platform and x86 hardware? Personally, for a server, I don't. Go help out Mono, which is progressing nicely, but could definitely use some more help. (http://go-mono.org)
If you do, I would definitely go with.NET and C#. When Mono gets further along for web services, it will certainly be a force to reckoned with. As for writing webservice and database clients for Win32, it is really quite nice. You could use GTK# and have it cross-platform, yet still take advantage of features that C# includes.
In short, the pros: excellent XML and SOAP handling, speed, many small features which are currently emulated at the API level in other languages...and the cons: currently somewhat locked into MS' platform (though this should change shortly with Mono), somewhat inferior auto-documenting to javadoc.
This is a complete troll - there is absolutely no comparison between a closed system specifically *designed* to provide incompatible extensions and a much superior shell which has become the defacto standard for *many* years.
Can you find me a platform that doesn't have bash available, but does have sh? If you can, you have the source, you can port it yourself.
Do you suppose you can compile Win32 code on a Win3.1 compiler?
That about describes the generation leap. I'd say that bash does a pretty damn good job of augmenting the old shell.
The point to a journalled filesystem/transaction manager is to maintain data *consistency* by having disk operations happen atomically.
That way, if the power gets cut in the middle of a file operation, your file won't be half borked.
It *does* protect your data on basic operations aslong as all of the data is in one place.
Ofcourse, we really should be using atomic/transactional for ALL application data storage: data loss and consistency due to power failures and other things would more or less be a thing of the past.
I agree with you, fundamental point of view: the web as an information retrieval medium should be more about data than presentation, the presentation being far more user controllable.
However, that is precisely what CSS was designed to do: decouple standard/generic document structure from presentation.
On a different level, the web is now being used increasingly as a thin-client architecture, where client display control is of great importance. In my opinion, javascript/DOM/CSS are actually *underused* in this realm.
You do appreciate the use of pop-up windows in native applications, don't you?
Java, Python, Perl and lots of other languages fit the bill quite nicely.
By the way, SSL is a API and protocol for public key encryption, hence 'Secure Socket Layer' - not a database. Use of SSL is the job of the webserver, and has absolutely nothing to do with the language that the web application was written in.
I suppose IMAP could possibly be called a database interface language, because a mail server vaguely resembles one - but that's a stretch.
So what on earth are you talking about?
Not to bash the language, as I really haven't taken a good look at it, but their example comparing Java servlets with Water was ridiculous. You cannot make a fair, honest or remotely reasonable comparison of languages on such a small scale, and use "this only took numer of lines as opposed to !"
Disclaimer: I have gotten paid for JSP/servlet development.
Only several connections per second? Only a Celeron 300 with 64MB of RAM?
I could write a webserver out of a shell script and [x]inetd that would run ten times faster!
Yes, Boa is a nice and fast little webserver, but the last time I looked at the code, it was an awful messy hack.
I also question why it is an odd comparison: the purpose of a web server is serving HTML pages.
Realistically, serving static HTML pages with Apache *SHOULD* be just as fast as Boa - few Apache features (which apparently disqualifies Apache from actually being compared objectively against anything else) ought to slow down Apache for serving *static* pages.
It's a stupid argument to argue that Apache isn't slow - it is. Yes, it's also featureful - however, few of those features effect the speed of serving static pages.
Slashdot Mirror
C# is a subset of Java? Are you on Crack?
Your obvious bias against Microsoft has slanted your views on an excellent platform.
C# is a *super-set* of Java, meaning it has more features.
Also, C# is far more standardised than Java will ever be, even though pundits have attempted to get a proper Java specification in the works lots of times.
The only half-way decent XML serialisation I saw for Java was something a company offered as commercial software, and it still didn't come anywhere as close to the way C# handles XML.
I like Java. I also think Sun has done excellent things for the open source community (mainly OpenOffice), though it is still an old school UNIX hardware company at heart.
It's just that C# exceeds the performance and functionality of Java in most cases, now on the Win32 platform, and other implementations are rapidly catching up - mainly due to Microsoft's surprisingly open standards.
Nice try, though.
Can you objectify your implication that .NET is 'easier' and J2EE is 'more flexible' ?
I have used both a fair amount. My previous job was writing Java business web applications, and I am currently managing the development of a C# webservice (for the server) and a C# winforms client.
.NET and J2EE, though they are less similar than the language comparison.
/ideal/ for any application dealing heavily with either protocol. In fact, I would say that it is nothing short of brilliant.
.NET calls 'AppDomains'. This is a very powerful feature.
.NET/C#.
/platform/ maturity, but I will leave the zealots to argue Windows vs Unix.
.NET and C#. When Mono gets further along for web services, it will certainly be a force to reckoned with. As for writing webservice and database clients for Win32, it is really quite nice. You could use GTK# and have it cross-platform, yet still take advantage of features that C# includes.
...and the cons: currently somewhat locked into MS' platform (though this should change shortly with Mono), somewhat inferior auto-documenting to javadoc.
Let's start with the picture from 10,000 feet: C# is aimed squarely at Java, and for all intents and purposes, it is a superset of Java. Similarly for
Language Differences:
C# has less integrated threading support. (which is a bad thing, imho)
C#'s XML and SOAP integration make it
Java's XML integration is a nightmare. JAXB is the only thing that comes close to being halfway decent, and it still doesn't come close to the integration C#. XML serialisation in C# is fast and beautiful.
C# gives you far more control over the dynamic reloading of classes, as well as increased security through what
C# documentation isn't quite as nice or refined as the standard javadoc fare, but MSDN is a pretty nice source, though sometimes you have to look a little harder or deeper than you would with the javadocs.
In general, both APIs are very clean.
As for maturity, I don't really think that's an argument. Most of the Java technologies available now (especially the XML/web services bits, in which the competetition is most fierce) are no older than
I think the larger question is the underlying
Do you feel comfortable locked into a Microsoft platform and x86 hardware? Personally, for a server, I don't. Go help out Mono, which is progressing nicely, but could definitely use some more help. (http://go-mono.org)
If you do, I would definitely go with
In short, the pros: excellent XML and SOAP handling, speed, many small features which are currently emulated at the API level in other languages
There are *thousands*, maybe even tens of thousands.
How on earth was this modded up?
This is a complete troll - there is absolutely no comparison between a closed system specifically *designed* to provide incompatible extensions and a much superior shell which has become the defacto standard for *many* years.
Can you find me a platform that doesn't have bash available, but does have sh? If you can, you have the source, you can port it yourself.
Do you suppose you can compile Win32 code on a Win3.1 compiler?
That about describes the generation leap. I'd say that bash does a pretty damn good job of augmenting the old shell.
Did I just get trolled?
> Or use differential GPS, and get accuracy to a few > tens of millimeters.
That would be centimetre...
Hmmm... yes and no.
The point to a journalled filesystem/transaction manager is to maintain data *consistency* by having disk operations happen atomically.
That way, if the power gets cut in the middle of a file operation, your file won't be half borked.
It *does* protect your data on basic operations aslong as all of the data is in one place.
Ofcourse, we really should be using atomic/transactional for ALL application data storage: data loss and consistency due to power failures and other things would more or less be a thing of the past.
2 failures out of 12 drives? That's a 16% failure rate - no small number!
I agree with you, fundamental point of view: the web as an information retrieval medium should be more about data than presentation, the presentation being far more user controllable.
However, that is precisely what CSS was designed to do: decouple standard/generic document structure from presentation.
On a different level, the web is now being used increasingly as a thin-client architecture, where client display control is of great importance. In my opinion, javascript/DOM/CSS are actually *underused* in this realm.
You do appreciate the use of pop-up windows in native applications, don't you?
Wow - talk about signal to noise ratio.
Thing is, I don't get anywhere near that. Maybe 1 or 2, if I'm unlucky..
Do people (excluding Taco) really get that many ?
OK, from your profile, you appear to know what you are doing, but your comments make absolutely no bloody sense.
How do you implement a language in SSL? IMAP? or a DB?
You mean you've used the SSL libraries? Or you just configured your HTTP server to run an HTTPS service?
You are incredibly vague.
Java, Python, Perl and lots of other languages fit the bill quite nicely.
By the way, SSL is a API and protocol for public key encryption, hence 'Secure Socket Layer' - not a database. Use of SSL is the job of the webserver, and has absolutely nothing to do with the language that the web application was written in.
I suppose IMAP could possibly be called a database interface language, because a mail server vaguely resembles one - but that's a stretch.
So what on earth are you talking about?
Not to bash the language, as I really haven't taken a good look at it, but their example comparing Java servlets with Water was ridiculous. You cannot make a fair, honest or remotely reasonable comparison of languages on such a small scale, and use "this only took numer of lines as opposed to !"
Disclaimer: I have gotten paid for JSP/servlet development.
Only several connections per second?
Only a Celeron 300 with 64MB of RAM?
I could write a webserver out of a shell script and [x]inetd that would run ten times faster!
Yes, Boa is a nice and fast little webserver, but the last time I looked at the code, it was an awful messy hack.
I also question why it is an odd comparison: the purpose of a web server is serving HTML pages.
Realistically, serving static HTML pages with Apache *SHOULD* be just as fast as Boa - few Apache features (which apparently disqualifies Apache from actually being compared objectively against anything else) ought to slow down Apache for serving *static* pages.
It's a stupid argument to argue that Apache isn't slow - it is. Yes, it's also featureful - however, few of those features effect the speed of serving static pages.
I carry mine for the sole purpose of Dopewars.
Well, until the bird nicked it... for the sole purpose of playing Dopewars.
*sigh*