Java 1.5 vs C# 790
Here's the list of enhancements to the Java Language:
- Generics (C# 2.0 already supports this)
- Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
- Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
- Typesafe Enums (again C# 1.0 already implemented this, but I think they've added a little bit more twist in Java, that its actually a better implementation)
- Varargs (C# 1.0's params construct, ellipsis construct in C++)
- Static Import (I don't know if C# 1.0 has this, or C#2.0, but C# has a construct for aliasing your imports - which is way cooler. Static Import, actually promotes bad coding habits IMHO)
- Metadata/Annotations (this is C# 1.0's Attributes, Sun's upturned noses just gave it a fancier name - also, C#'s implementation is better and more intuitive)
They've beefed up the API some, and integrated several packages with the regular JSDK that used to be a part of a separate package or installation ---in my NSHO, the Java API has become bloated...
At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby - Java could become the child nobody wants to talk about if Sun dies) - right now that's C# and the .NET Framework ---
If you ask Paul Graham though, both language would be utter crap and fit only for idiots :) http://www.paulgraham.com/gh.html [I'm exaggerating, so hold off on those flames.]
I code C# for a living (Score:4, Insightful)
Re:I code C# for a living (Score:5, Interesting)
Regards,
Steve
Re:I code C# for a living (Score:3, Informative)
c# library vs Java library: c# is much cleaner in some aspects.
VS.net vs Eclipse: no contest, VS.net is much worse.
Re:I code C# for a living (Score:5, Informative)
While 'ref' paramters are debatable, 'out' parameters are stupid. They should have created a way to return multiple values from a function. Allowing first class tuples would have been the correct way to do this (in most C-style languages, tuples are allowed as arguments to functions and disallowed everywhere else). Adding tuples would also have eliminated the need for the hacked up delegate functionality. Then again, Java doesn't have any equivalent functionality, so it could be seen as an advantage for C#.
Operator overloading is a good thing. It can be abused, but so can anything else. Removing operator overloading doesn't even come close to making it impossible to write obfuscated code. There are many situations where operator overloading makes things a lot simpler.
Properties are also good. Instead of identifying them through string matching ("get*", "set*"), language-level support for properties allows more accurate data type modelling. In the end, however, the CLR doesn't really have true support for properties. They implement them as methods (like Java, except at a lower level so most programmers don't have to care about it). This implementation mistake resulted in different opcodes for field access and property access, which means you cannot switch between fields and properties without changing the class's public interface (and breaking binary compatibility with client code). It's still better than what Java does...
Function pointers and anonymous functions. This has got to be the biggest improvement over Java. Unfortunately, class libraries were already designed before the anonymous function feature so they probably wont be designed to take advantage of it. Also, VB and C++ are probably holding things back because, as everyone knows, "language agnostic" is just a euphemism for "lowest common denominator".
You also forgot generator functions. They make it easier to write pull-style classes (a "pull" XML parser, for example). Though it isn't as powerful as full-blown continuation support, I think it'll still be useful for many coding tasks.
C# has more comprehensive generics support (aside from variance). Though both languages made the mistake of allowing arrays to be fully covariant (ArrayStoreException), Java got screwed when they decided not to maintain dynamic type information for generic type parameters. This limits the use of generics in often confusing ways. Type erasure isn't a problem in languages that have a good enough type system to avoid resorting to dynamic typing (like ML or Haskell). But C# and Java do not have good enough type systems and the C# people recognized that and chose to keep the dynamic type information around.
C# is better than Java in almost every way. Java has better enums and support for covariant and contravariant generic type parameters, but that's about it.
Operator overloading (Score:4, Informative)
Just because operator overloading can be used for evil is no reason to throw the baby out with the bathwater.
Java lacks a Currency class, so I wrote a Money class some time ago that I use for common financial calculations, and it takes care of the pesky problem (and newbie mistake) of using floating point types for money.
BUT, in Java, you have to have add(), sub(), mult(), and div() methods. Reading RPN style caclulations consisting of sequenced and nested method calls instead of algebraic operators is painful. Operator overloading is wonderful in those cases.
Operator overloading certainly can be evil: What does it mean to increment an Employee? Do I really want to know? But for new types that you can actually do algebra with, it is quite helpful.
And there are other cases.
In my C++ days I wrote a FileHash class that kept an index of offsets to the start of each text line in a text file. Then I overloaded the array subscript operator so that a text file could used like an array of char pointers (or a String class if you liked). That was a perfectly good use of overloading.
Moreover I think overloading the array subscript on ordered collections also makes perfect sense.
I often wish Java had this feature. I agree with every simplifying choice they made except this one.
Re:I code C# for a living (Score:5, Informative)
Suppose you have a class like this:
class A {
A method() { return new A() }
}
And another class like this:
class B extends A {
B method() { return new B() }
}
This construct is called covariant. The class B is ingeriting from A, while the method method() is overwritten in B. Not only is the mthod redefined but also the return value is. As it is redefined to the taype of the class, this is called covariant.
If the method in A would return a B and the method in B an A, it would be called contravariant.
For template parameters there are similar definitions, but they are a bit more complex.
angel'o'sphere
Re:I code C# for a living (Score:5, Informative)
Re:I code C# for a living (Score:5, Insightful)
java doesn't have to do that much to "catch up" to it.
Stated another way, Java 5 is still behind C#, to which I would agree.
As to how far behind, that depends on what you value. Java's event handling/callback design is atrocious compared to the convenience of delegates. I would much rather pass a single method called OnAccountOverdrawn()to the event notifier than the Java style of making the whole class an instance of some interface, implementing stubs for all the useless methods of the interface, then implementing the one useful method--which will have a useless name like DoAction() that you can't change, then passing the object that contains the DoAction() method to the event notifier.
And for many things such as generics, autoboxing, enums, etc. (I don't recall which ones specifically), there are actual semantic differences in the virtual machine for C#, whereas Java's knockoff versions are just syntactic sugar for the writing out the equivalent source code yourself. I AM in favor of syntactic sugar, but having the actual semantics available in the underlying runtime gives you additional advantages.
Java's great advantage is its ubiquity, which is also an impediment to improvement. Sun's position was that it was pretty much finished with language improvements after Java 1.1 and would thereafter concentrate on libraries that would run on existing JVMs. New JVMs might run the code even better, but the old JVMs would still run it.
Microsoft knew they had to do better, or nobody would switch. They did a lot of things better, and they seem committed to doing more, even if it means obsoleting their existing VMs. They have far more control over The (One) Platform and seem quite willing to make improvements to C# and the other
One catgegory of improvement they seem interested in is a way to make dynamic languages, like Python or Lisp, work REALLY well. Another is support for functional languages like Haskell or OCaml that have special needs of their own.
And if they do it well, (my speculation now), they could even add some of the attractive features of those languages, languages I like more than C#, to C#, widening the gap with Java.
Java might have a very hard time keeping up with C# improvements while anchored to existing runtimes, and letting go of the anchor would seriously impact its ubiquity, which is one way in which Java is vastly better than C#.
I don't think it's a given that Java is going to catch up to C#. But if Mono and/or DotGnu don't succeed, it may not matter as Windows fades away (which I believe it will).
Re:I code C# for a living (Score:4, Interesting)
Meh, that's just my take on it. And it would appear that my opinion is officially modded "troll". Oh, well. =/
Re:I code C# for a living (Score:5, Insightful)
Personally I find them reasonably equivalent, but C# has a few advantages (properties, delegates, events) and the
Ravioli Code (Score:5, Insightful)
Re:Ravioli Code (Score:5, Insightful)
Varargs? (Score:5, Funny)
All in it together (Score:5, Interesting)
Re:All in it together (Score:3, Funny)
And in other news, Microsoft decides to bundle Cygwin with Longhorn...
(ok so maybe Mono could do Java, not that I understand why they'd want to)
Re:All in it together (Score:5, Informative)
Re:All in it together (Score:5, Interesting)
Re:All in it together (Score:4, Informative)
I'm confused (Score:4, Insightful)
"One Person"... "One C# Developer" (Score:4, Insightful)
Only thing I agree with is generics has been long overdue.
Learn to write? (Score:5, Funny)
Re:Learn to write? (Score:5, Funny)
Re:Learn to write? (Score:3, Funny)
Re:Learn to write? (Score:3, Funny)
"It compiles... ship it!"
Comment removed (Score:4, Funny)
Re:what about... (Score:3, Funny)
and you're foundations in OOP is rock-solid
Come on, people. Conjugate.
flamebait (Score:4, Insightful)
At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby - Java could become the child nobody wants to talk about if Sun dies) - right now that's C# and the .NET Framework ---
Re:flamebait (Score:3, Interesting)
Re:flamebait (Score:5, Informative)
It's not about the enterprise, it's about the desktop. Microsoft had to do something there because C++ and MFC and COM was seriously getting in the way of getting the job done. Java isn't even trying to compete seriously on the desktop, so C# wins by default on the desktop. And (crazy as those people may seem to you and me) Microsoft desktop application developers actually seem to like Visual Studio. If Microsoft can additionally win market share from Java in the enterprise, that's icing on the cake for them.
Re:flamebait (Score:4, Funny)
You're going to name it what?! (Score:5, Informative)
Rich
Re:You're going to name it what?! (Score:4, Insightful)
Cue the zealots on both sides (Score:4, Insightful)
--
I'll pay you $10. Really. [slashdot.org]
Java 1.5 vs c# 2.0? (Score:5, Informative)
Re:Java 1.5 vs c# 2.0? (Score:4, Insightful)
Comparing a released software product that is available almost for free to an unreleased product that costs hundreds of dollars is just dumb. Where is the story here?
Re:Java 1.5 vs c# 2.0? (Score:5, Insightful)
Seriously, I couldn't care less about better performance. I care about being able to avoid probably 75% of all casting that goes on in our 10.000+ source file project and being able to specify our API even tighter and catch more problems before it hits our customers.
I just wish Sun had done this 3 years ago, but better late than never.
What Language (Score:3, Funny)
I want functions (Score:3, Insightful)
Re:I want functions (Score:3, Funny)
Why not argue against managed memory while you're at it.
YES THIS IS A TROLL
HITLER
Too bad we can't mod articles (Score:3, Insightful)
My feeling is that these features are good news. There should be no gloating on the part of C#, it was clearly built on Java's coattails.
Competition is a great thing, ain't it?
Re:Too bad we can't mod articles (Score:5, Insightful)
I wouldn't give Java the credit for C#. If anything, it was Delphi that C# was built upon. The only thing that C# "borrowed" from Java is the idea of a VM, and even that functions in a different way than the Java one.
Why is there a C# advertisement on /.? (Score:5, Insightful)
I've worked on C# and Java projects. As far as I'm concerned, C# = MS Java. MS could not control Java, so they abandoned support for it and built thier own "version." It's really a rinse & repeat cycle for MS: see successful software, build own version of said software to try to take over that market as well.
Re:Why is there a C# advertisement on /.? (Score:3, Informative)
Ditto. I'd go so far as to say that .NET has some of the same bugs as the MS JVM and class libraries, especially in the networking support, where Java is streets ahead.
Corrected URL (Score:5, Informative)
Perhaps /. will correct the error. I emailed the editor when the story was in preview, but it was too late.
I call bullshit (Score:5, Insightful)
Here's my theory. Along with the ubiquitous slashvertisements and the Microsoft-bash-of-teh-day barrage posts, these are a perfect opportunity to create a story that will generate 1,000+ comments and ten times those many page views and ergo ad impressions.
C'mon, C# vs. Java? Outside of "RIAA sues 86 year-old grandma", "We hate Bush, let's talk" and "Microsoft patents KDE" there is no better source of inflammatory material in the dorkosphere.
Sad, really.
Maybe I'm an oldtimer, but... (Score:5, Funny)
Oh, how I pine for the days of vi vs. Emacs.
- Tony
the crap argument (Score:5, Interesting)
"At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby..."
Which "crap" argument is he talking about? I assume he means that when using those languages you have thousands of directions to go for help in howtos, docs, tutorials, books and of course the loving #perl. I normally would not reply to something like that, but I took offense. Yes I love those languages. They all have strong points and make life fun when coding. I have support and have never had to rely on a company to provide said support. Oh yeah, and I write enterprise software with the mod_perl crap everyday of my life. Thanks.
iamchaos
Version (Score:4, Funny)
Optimization models (Score:3, Informative)
Mistake (Score:3, Insightful)
This, BTW, is why you don't want your language to be controled by a company which in turn has a marketing-driven bottom-line. The idea that two languages could co-exist with different target audiences is nonsense to marketing droids, but perfectly reasonable to someone like Guido van Rossum, Larry Wall or any of the other maintainers of truly open-source languages. Open source isn't the only way to maintain this focus, but in today's marketing-driven world, you aren't likely to see too many Bell Labs-like organizations putting out languages like C (which was semi-open source, as was Unix). Java and C# are probably much more typical.
Re:Mistake (Score:5, Insightful)
Heh (Score:3, Funny)
SexyFingers writes "Sun released Java 1.5...
The ultimate question is... how did you get those sexy fingers ? Java, C# or... Pr0n# ?
AVP (Score:5, Funny)
whoever wins, we lose.
IIS vs J2EE Servers (Score:5, Informative)
Recently I switched to C# (new job) and I have to tell you, the language is pretty neat with some of the tricks you can do. Nothing ground breaking though.
What's really missing is the platform for release, and release management. Where are WARs and EARs for
The constructs and tricks of a language can be debated as long as you want. You will probably find something nice in every language. But when you have to [operationally] deploy any application, great or not, on some cheap as shit, crap ass, hard to manage, non-repeatable platform such as IIS, that's when the real rubber hits the road with Java.
J2EE deployment platforms are light years ahead of
Re:IIS vs J2EE Servers (Score:4, Informative)
In the Java world with your Servlet engine, you drop a war (which is a glorified zip) file in a given deployment directory, and the engine unpacks it, and brings the app online. That's your entire process for deploying a simple app. It includes your web pages, classes, libaries, base config, etc.
SourceSafe may be free, but my biggest complaint with it is it's poor branching, lack of proper security, and non-client-server access menthods.
I've recently switched the windows developers at work to CVS, and had them install WinCVS and TortoiseCVS. WinCVS handles the hard stuff that you do very rarely. TortoiseCVS handles the everyday stuff. It ties into Explorer and My Computer (and other file browsing areas) and allows you do normal SCM operations (checkout, update, commit, tag, branch, diff, log, etc) right from the file browser.
It's a nice package to try out if you've never seen it. CVS has it's own problems, but they're pretty easy to watch out for. Once the windows tools for subversion get a little more time under them, I'll probably end up switching our repositories over to it, for the renames, repository-wide version, and O(1) tagging/branching.
Important differences between Java and C# (Score:5, Insightful)
With C#, stuck in windoze (Score:5, Insightful)
He kind of forgot that there are many programmers and customers who DON'T want to deploy their systems on win32. With Java apps, you don't have to. In fact you can choose almost any operating system and hardware. Anybody who chooses C# over Java for enterprise deployments is truly a MicroWeenie.
:]
I much prefer my 8 processor HP UX box any day
Re:With C#, stuck in windoze (Score:5, Insightful)
Re:With Java, stuck in Windows/Linux/Solaris (Score:5, Interesting)
If it's a choice of language based solely on the portablity of code, C# wins out IMHO. With Java, you're dependant on Sun to support your system, which is a royal pain. (as anyone with a *BSD box will tell you)
I run a J2EE application on WebSphere on a mainframe under OS/390. Where's .Net for OS/390? I can (and have) also deploy that same application with zero changes to Linux, Windows, Solaris, AS/400 or Mac OS X. I can choose from a number of J2EE implementations like WebSphere, WebLogic, JBoss or Resin, each of which have different features and strengths. I don't even recompile, I just drop in the WAR and go.
And it is incorrect to say that you are dependent on Sun to support your system. Independent vendors like IBM, BEA and Apple also license and support J2SE and J2EE for their own platforms. My personal systems are Macs and I get my Java from Apple, not Sun. My corporate systems are IBM and I get my corporate Java from IBM, not Sun. If I have a problem with either, I don't call Sun, I call Apple or IBM. IBM provides my production support contract. IBM are the ones who responded with a custom patched version of WebSphere for OS/390 in less than 24 hours when I had a production problem. Not Sun.
Java C# porting - Lucene as example (Score:5, Interesting)
If C#/Java continue in this direction, I think we will see many more applications that have parallel versions in the two languages.
See:
Lucene [apache.org]
dotLucene [sourceforge.net]
Limitations of Generics in Java. (Score:3, Interesting)
Java, which are properly addressed in C#.
For more details, you might want to read:
http://www.artima.com/intv/generics.html
C# still has a few extra niceties like properties,
events, delegates, anonymous methods and iterators.
Miguel.
Java poor design choices (Score:3, Insightful)
The new generics feature is clearly patterned after C++ templates, but in the name of backwards compatibility Sun chose to implement generics using erasure. This means that a generic type loses all of its type information leading to a alot of issues including broken support for arrays. Using erasure keeps much of the potentially confusing syntax of C++ templates and virtually none of the power.
I suppose I would be less upset if the feature had a different name. Maybe something like AutoCasting (like the name AutoBoxing). "Generics" implies things that the feature does not even try to deliver. Adding true generic programming constructs to java would have been a huge leap forward for the language. Instead we are left with a toy feature that allows you to build type safe containers, nothing more. Very disappointing.
API talk... (Score:3, Informative)
CB*($#@
Enterprise development (Score:3, Interesting)
The new features to Java in version 1.5 are all anticipated and appreciated by the development community, but us J2EE developers won't be able to access these new features in our apps until the official J2EE 1.5 release comes out, and the various app server vendors (IBM, BEA, Oracle, Sun, JBoss, Apache, etc.) support it in their products.
April 1st? (Score:3, Insightful)
> of IDE, tools, api, and longevity of the vendor
Eclipse/IntelliJ/Together
Apache/Tomcat, WebSphere, BEA
RedHat/Suse/Mandrake/Debian
All of these tools and vendors have been around longer than C# and
> pushing it (forget the OpenSource crap argument,
> those guys are too in love with Perl, Python,
> and Ruby - Java could become the child nobody
> wants to talk about if Sun dies) - right now
> that's C# and the
You misspelled "FUD."
still very different (Score:5, Informative)
Basically, Sun did a bunch of things they could do without changing the VM too much and without breaking old code. But for a bunch of other features, they punted and just added a bit of syntactic sugar to the compiler that makes Java look superficially like it's doing the same thing but is much less efficient under the covers.
For enterprise applications, those differences may not matter much (and they may even be harmful), which is probably why Sun doesn't do anything about them. But for desktop use and application programming, they do matter. Microsoft wanted to create a new language that their legions of C++ programmers could use, and C# is a pretty credible answer for that. Those people don't care about cross-platform features, they care about getting the job done, and if that involves the occasional unsafe module, it doesn't matter to them.
Plenty of differences (Score:3, Insightful)
For enterprise-grade work I still prefer J2EE over
Re:Plenty of differences (Score:4, Informative)
C# and Java are so similar.... (Score:3, Informative)
When you think about it though good OO concepts tend to evlove toward similar goals. Languane and usablitly concepts are the same all around. Its to the point now where the differences between Java and C# are more syntax and available libararies. Ive even been able to easily port Java to C# and vice versa since the languges are so similar.
It has defintaly opened up things more for me, as now I leave it to the client as to what they want. If they are an MS shop then C# is an obvious choice if they use Linux or perfer alternative platforms then Java is obviously what you should build in.
How exactly is Java "OO from the ground up"? (Score:3, Insightful)
It hinders programming efficiency, and it hinders code efficiency: any place where primitive types can be used, the compiler can infer that primitive code can be generated, any place it can't you'd have had to use object types... but the compiler is MUCH smarter about figuring where casts need to be than average (or even above-average) programmers.
Smalltalk is "OO from the ground up". Java is "OO from the Integer up".
It's the installation stupid (Score:4, Informative)
C#, despite any other flaws, Just Works(tm). Install Visual Studio, write some code, click the run button. Sure it takes a bit of thinking to get a n-tier implementation up and running properly, but the installation of the back-end stuff (IIS, db connections, remoting) is incredibly simple.
On the other hand, to get enterprise Java (J2EE, although some would argue that a class library is easier and more versatile), you need to learn how to install an app server (JBoss, Orion, or god forbid WebSphere), and how to configure that system for database connections, performance, session and object permanence, etc..
None of this really matters in a 'big-iron' enterprise environment, because there's room to hire a websphere monkey to look after the cat-herding. In anything below a mega-corp or mega-bank however, the overhead of running Java can sometimes be a burden that developers just don't want to think about.
I see it kinda like using Firefox over IE. They both do pretty much the same thing, and one does it 'better', but at the same time requires some effort to implement. Some people just can't be bothered with the effort.
varargs is *not* an enhancement (Score:4, Interesting)
As Stroustrup says of the ellipsis construct in C++, "The most common use of the ellipsis is to specify an interface to C library functions that were defined before C++ provided alternatives", and gives an example of the "extra work that face[s] the programmer once type checking has been suppressed using the ellipsis." Using the ellipsis construct, other than where it has to be used to access some legacy C library, is definitely very poor style in C++.
Re:Fix the link (Score:3, Funny)
It turned out that the submitter (or someone editing the article) lost the rest of the link when they submitted it. Thus the source code showed:
Re:APIs (Score:5, Informative)
You mean like JAXP [sun.com] and JAXB [sun.com]?
Re:APIs (Score:3, Insightful)
Or, is your complaint based on the fact that the libraries that underlie the XML and Security algorithm API's can be swapped out? To me, that's a feature not a bug but YMMV.
Re:APIs (Score:5, Insightful)
They ARE.
XML package [developerd...ummaryhtml]
MD5 and SHA support [developerd...iindexhtml]
The former has been in Java since 1.3, and the later since 1.1(!).
Honestly, Java has every feature and the kitchen sink in its core APIs. And if a feature isn't there, it's very easy to write a library to add it. That's why programmers like Java so much.
Any other features you'd like me to find for you?
Re:APIs (Score:3, Informative)
The XML APIs were part of a standard extension in 1.3. They were added to the core in 1.4. Also, I found the JavaDocs for 1.1, so here's a link [redbrick.dcu.ie] to back up my statement that MD5 support has been around that long.
Re:APIs (Score:3, Informative)
So, were you trolling, or did you just not bother to keep up with Java?
Re:Sounds a lot like religion (Score:5, Insightful)
Java is not any more closer than C# to open source technologies. Sun doesn't like open source, just as Microsoft.
It's a very well known fact that Java has been a base (or in other words "the" figure) for Microsoft while developing C#, but that does not imply that "Java is good, C# is bad" or vice versa.
I would be happier personally to code in Java, but professional life yields to disqualify who resists new technology.
Your choice of programming language is not your religion, and it can change continuously through your life. Just like your operating system.
Re:Sounds a lot like religion (Score:3, Insightful)
How do you explain that Sun provides official Java runtimes for Linux (and for that matter sells Linux boxes) as opposed to Microsoft's complete lack of support for anything except Windows?
Sun has always been much more open than Microsoft. They are also allowing open-source implementations without fear of reprisal. We'll see if Microsoft manages the same tolerance with Mono.
Re:Sounds a lot like religion (Score:3, Informative)
In the driver arena this the prefered solution to having a closed official impementation. I would assume it is the same for the sake of a language also.
Re:So this is what... (Score:3, Funny)
Re:Flaws in both Languages (Score:5, Insightful)
For enterprise-grade web-applications (not hacks), it's
End of story. Don't argue with me, just accept it.
Re:Flaws in both Languages (Score:4, Insightful)
I take exception to that. Just because you can't do it doesn't mean that it can't be done. Maybe where you're from, Sun runs things, but here, it's the business-- how can you get the job done better and faster? And Java has proven to be a useful tool, when used by competant programmers (not Learn Java in 21 Days type).
I'll try to make my case for "enterprise-grade web applications". Such an application needs the following features:It's #5 and #8 that are hard to come by. As for maintainability, I see Perl as a Write-Once language, with PHP only slightly better. Java/C# are much easier to maintain because (a) their syntax is not prone to being overly compact (read: unreadble), and (b) the number of people who can maintain Java applications is probably much larger than those who can modify your Perl app.
You advocate Java and slam PHP in the same post? Both of these languages belong in the same beginners class.
Where do you work that Java is considered "beginner"? Have your company actually produced applications?
Re:Flaws in both Languages (Score:5, Insightful)
1. What exactly does it mean if a language is "open source?" Surely, the specification is available for free. If you wanted to, you could write a lexer/parser/compiler without paying anything to Microsoft/Sun. Do you mean that the tools provided by the companies aren't open-source?
2. C# doesn't "require" a virtual machine any more than Java "requires" a virtual machine. One could write a native compiler for both. Additionally, in fact, Microsoft's .NET implementation does just-in-time compilation of the .NET assembly generated by the C# compiler (the bytecodes, basically), so it doesn't actually run inside of a virtual machine, nor is it interpreted. Since Sun's javac is supposed to generate portable bytecodes to run on different architectures, they decided to use a VM to avoid having to write a thousand different JIT compilers.
Neither of these are inherent weaknesses in the specifications of the languages, they're implemetation details. Since this story is supposed to be about new language features in Java, I don't see how bitching about Microsoft/Sun's implementations is really relavent.
Re:Flaws in both Languages (Score:5, Interesting)
Neither is open source. Languages can't be classified open source, because they aren't programs. Certainly both languages have non-open source implementations, but they also have open source implementations.
Both require virtual machines. Well, I guess it depends on what you mean by a virtual machine. Technically even the C runtime is a virtual machine. That being said, both Java and C# can be compiled to native code, bypassing the need for the JVM/CLR.
Despite being marketed as portable, but have portability issues. ROTFL! Yes, perfect portability isn't possible. However, both languages are amazingly portable considering their extensive feature sets.
We don't really need them. Really, when you think about it, we only really need C. PHP/Perl/C++/Python are really all flawed languages as a consequence.
They're closely tied to their respective companies. This is more of a perception problem than a reality problem. I can do development in either language without getting involved with either company.
Re:Flaws in both Languages (Score:3, Insightful)
Don't want to get into a religious argument here. Being 100% open source is not always a benefit.
Both require virtual machines.
Really? [gnu.org]
Despite being marketed as portable, but have portability issues.
"They're not perfect, so toss 'em out!" Great argument...
We don't really need them.
Yeah, we don't really need Perl of PHP either. I do all of my web pages in assembler.
They're closely tied to their respective companies.
Really? [ibm.com]
Re:Flaws in both Languages (Score:3, Insightful)
# Neither are open source.
How can you "open source" a language? Are you talking about compilers themselves being open source, or what? The language specifications for both Java and C# are trivially available for anyone that cares to look at them.
# Both require virtual machines.
This is simply not true. For example, there are at least two Java compilers that produce native executables.
# Despite being marketed as portable, but have portability issues. Java is not backward compatible with older version
Re:Flaws in both Languages (Score:3, Insightful)
Re:Only Microsoft (Score:3, Insightful)
Relying on documentation to tell API users what exceptions can be thrown is a really terrible idea if you're trying to write server software that has to actually work. And work all the time, 24/7, not just in a demo. MS still seems to be in the mindset where their developers are mostly making client-side VB applications or tiny ASP sites.
We've had a number of cases so far where C# library methods unexpectedly threw an undocumented exception (that w
Re:Only Microsoft (Score:5, Informative)
No, the code will just appear cleaner. Hiding exception propogation is an invitation to ignore exceptions. If someone wraps code in a single catch, you can at least see where they've been sloppy. The equivalent in a non-forced exception check is to do nothing, which is invisible.
Re:Only Microsoft (Score:5, Informative)
Um, Java supports both checked and unchecked exceptions.
Re:Java checked exceptions suck, but how to fix th (Score:5, Interesting)
And, before you whine about having to write the try/catch block, let me echo what somebody else said, that an IDE like IntelliJ will do it all for you (except for the comment).
Re:varargs (Score:3, Informative)
I think you've completely misunderstood polymorphism and/or varargs.
I've never, ever had to write a Java method that would have been better implemented using varargs, but I've written plenty in C and C++ in the past that would have been better written without them...
I can only think of a couple of cases in Java where varargs would actually improve matters (have a look at MessageFormat, the work around it uses to emulate varargs is painful so varargs would be great there). But I just know varargs will get
Re:Meanwhile, C++ goes nowhere (Score:3, Informative)
C# doesn't really compete directly with C++, it competes with Java.
Re:Meanwhile, C++ goes nowhere (Score:5, Insightful)
C++ is a great language, but it's choosy about its friends. It takes some time to master all (well most) advanced aspects, but as soon as you do, nothing beats a good C++/STL combo.
What I don't like about C++ standard, is the lack of a decent socket library that would be part of the i/o streams. There are non-portable classes for this of course, and everyone could roll their own, but it's not in the C++ standard (yet).
IMHO, one of Java/C# biggest advantages over C++ is this particular aspect. Not that it would convince me though to switch away from C++ to Java, which simply doesn't cut it yet.
For fast prototyping, I'd stick to Python, but when performance really matters, C++ is still king!
Re:Meanwhile, C++ goes nowhere (Score:3, Insightful)
The same can be said for COBOL. I bet somewhere in the world there is a guy that likes COBOL.
What I don't like about C++ standard, is the lack of a decent socket library that would be part of the i/o streams. There are non-portable classes for this of course, and everyone could roll their own, but it's not in the C++ standard (yet).
Sockets, as an operating system specific issue, don't really have a place in the language standard. Especially fo
Welcome stranger! (Score:5, Insightful)
Here, we have compilers that can do bounds checking - avoiding buffer overflows, if you decide to use them.
However, the template feature of our C++ is so powerful, that when used together with structs and classes, one can produce beautiful code that is extremely powerful, yet so simple that it is easy to ensure it is not susceptible to said buffer overflows (or memory leaks or the thousand other plagues of much of the software that surrounds us).
This is why there is actually not anything fundamentally wrong with our C++. We are some who want template namespaces though, but outside of little issues (that do have workarounds) like that, the only things we really want is additions to the (already powerful) standard library, the STL.
One problem remains with our C++ though. We live on a planet inhabited mainly by clueless morons, people who do not like to learn, people who refuse to accept that maybe others have seen farther than themselves. This is why we, too, have a lot of problems with software in general - buffer overflows as you mention, among many other problems.
I am sure we can arrange for you to get a copy of our C++ standard - that will allow a clever individual, such as yourself, to write software without the problems we discussed. I would then suggest that we join our efforts, in teaching the unwashed masses how to actually use the language properly, so that we will not have to re-do all software in the world (both ours and yours) by ourselves.
Deal?
Re:Meanwhile, C++ goes nowhere (Score:3, Interesting)
So, why do we still have buffer overflows? Is it because of the language? I think my previous paragraph shows that this is no longer the cause, and hasn't been for years. On the other hand, C++ does still allow you to mak
Re:Meanwhile, C++ goes nowhere (Score:4, Insightful)
[snip]
"This problem is the primary reason that C# exists. If the C++ committee had fixed their language, we wouldn't need C#."
[snip]
First, this is not why C# exists. For real reason as to why it is search the net. Enough info out there without me reiterating it.
Second, there is "nothing really wrong with C++" and the reason the committee buys that is because it is true. The language specification spells out, as a single example, that if you index beyond the end of an array or dereference a null pointer BOOM! Undefined behavior, as in may work with some sort of reasonable expectation or may unleash flying monkey demons from your spouses nose with the sole purpose of ruining your computer career.
Third, C++ is not an OOPL like Java or C#. It is a multi-paradigm langauge with support for any type of construct you want to throw at it - including shitty code regardless of paradigm.
Again, I am trying to understand where you are coming from but I just do not see your point - or more directly that your point is valid.
C++ as a language is not really lacking at this ponit. Now standardized libs, like the inclusion of the STL was to the standard, are welcome. Things like concurrency, threading, gc, GUI, etc. Yes there are plenty out there but none of them "officially" standard yet. I think this argument would support your point better, if I was understanding what you meant rather than what you typed.