Java 1.5 vs C#

SexyFingers writes "Sun released Java 1.5. The non-API stuff that they've added made it finally "catch-up" with C# - since both languages are built to support OOP from the ground-up, their constructs become almost identical as additional OOP "features" are supported. So if you're doing C# and your foundations in OOP are rock-solid, there really isn't any difference whether you're coding C# or Java."

Here's the list of enhancements to the Java Language:

1. Generics (C# 2.0 already supports this)
2. Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
3. Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
4. 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)
5. Varargs (C# 1.0's params construct, ellipsis construct in C++)
6. 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)
7. 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.]

Comments

I code C# for a living

[carpe_noctem]

...and let me tell you, java doesn't have to do that much to "catch up" to it.

Re:I code C# for a living

[danheskett]

What don't you like about C#? Or do you just feel that C#/.NET and Java are roughly equivalent?

Re:I code C# for a living

[carpe_noctem]

Maybe I just don't grok OO design, but the whole language is really abstract. Nothing seems to tie together to anything else in any sort of logical fashion, and it takes hours to figure out how anything works.

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

[Westley]

So if you find C# abstract, where *exactly* is Java better, as a language? Or were you actually comparing the libraries? (Which bit of C# itself took hours for you to figure out?)

Personally I find them reasonably equivalent, but C# has a few advantages (properties, delegates, events) and the .NET library has had fewer iterations so is less internally inconsistent than the Java libraries at the moment.

Re:I code C# for a living

[LnxAddct]

I code in java on the side for some small business apps. I've also coded in C# and have used all of the MS Visual Stuido nonsense. Both languages are at a level that you can do just about anything with one that you can do with the other. So the deciding factors come down to really which is a better platform to develop on and cross platform compatibility (in some cases the latter isn't an issue, but it is for me). As far as IDE's go,I don't get what people like about Visual Studio, especially VS.net. I enjoyed VS 6.0 much better the VS.net, regardless I have since moved to a strictly open source platform and only use Windows for testing. When I did do C# coding, I preferred using vim or Sharpdevelop. I really can't stand VS.net. Anyway, Java, imho, has superior IDEs (some may argue that IDEs reinforce bad programming, etc..., but if used *correctly* they can significantly increase productivity) Eclipse puts Visual Studio to shame in many areas. Eclipse is an amazing IDE and made programming fun again. Another great IDE for Java, that puts great focus on GUI dev, Web App dev, and Mobile phones, is Net Beans. Both IDEs have very nice integrated features with a great tool selection and good plugin frameworks. I use both interchangeably depending upon specific tasks and projects. So in my oppinion as far as having a good platform to work on, Java is superior. Next is cross platform compatibility. Although Mono is making leaps and bounds, Java wins hands down on this. It gives my customers more options and major open source software foundations like the Apache foundation actively work on many java based enterprise applications. This allows my customers to also have low start up and implementation costs.No real need for further discussion on that. Another area where I prefer java is for distributing applications via WebStart. It makes life very easy, in many areas including maintenance and deployment. This is just my 2 cents. I don't really see why anyone would use C#, I mean they took Java and improved, and now Java has taken both its past and C# and improved itself :/
Regards,
Steve

Re:I code C# for a living

[spacecowboy420]

Thread is over, 'nuff said.

Re:I code C# for a living

[CaptnMArk]

C# vs Java, mostly a tie (c# good: ref and out parameters, indexers, foreach; c# bad: properties, operator overloading)

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

[fitten]

How exactly does it pale in comparison? What features does it have that make it better? What features does VS.NET lack?

Re:I code C# for a living

[gooser23]

Granted I've only used a few IDEs (VS6, VS.Net2002, VS.Net2003, Tornado for vxWorks, Xcode, Kdevelop & ddd), but of all VS.Net is cleanly the easiest to get things done in overall.

I did not find Kdevelop or ddd particulary more useful than vi other than having been weaned on VS6 I am simply more comfortable with a GUI than a tty.

Xcode does every part of project management and structure more correctly than VS in my opinion. The idea that your source tree is separate from your targes and that your targets are separte from your executables just makes sense. There's a lot less special cases this way.

Tornado for vxWorks (ver 2.2.1 IIRC, its been some time since I used it) is a poor copy of VS6 -- possibly more correctly VS5 or 4, but I've never used those. The one thing that Tornado got right is the remote debugging (e.g., you build a vxWorks system, load it onto your embeded system, and you can debug through your app via ethernet, serial port, or a local pci bus). In fact, without the remote dubugging I would have considered Tornado to be utterly useless.

The things that set VS apart is its build styles and debugging features. Xcode could catch up on the both of these (esp. the build styles), but I'd say gdb has a long way to go to be on the same leve als VS's debugger. Its really nice to be able to add new code, change existing code, and arbitrarily set the execution pointer. Really the 'advanced feature' I've figured out how to replicate on gdb is changing a variable's value, but even this feels rudimentary to how in VS you can arbitrarily change the contents of memory directly.

So, in short, what I like about Visual Studio is its build styles and debugging capabilities. But I do think Xcode 1.5 is better thought out, just not as polished in these two areas.

I should add that all this does not apply to any APIs of the aforementioned products, in which I would agree with you (having used MFC, ATL, COM and WIN32), I don't see why informed person would choose these over the alternatives (wxWindows, stl, boost, Cocoa) if they had a choice.

Re:I code C# for a living

[iezhy]

Java has checked exceptions

exception management in c# is so painful without them

Re:I code C# for a living

[Bloater]

> VS.net vs Eclipse: no contest, VS.net is much worse.

So you could say that VS.Net has been eclipsed. Heh... Sorry, that was terrible.

Re:I code C# for a living

[WebfishUK]

One of the reasons that Fortran has such reusability is because everything was an array. It was eaasy to use some elses function I just had to re-organise the elements in my array (you soon build a library of functions to do this that you use a lot). The problem with OO languages is that you get complete ability to define clever objects which you (and me) always assume will be the focus of everyones life. It becomes very difficult to reuse stuff not from a coding point of view but because the object you have to work with is never exactly what you wanted.

Re:I code C# for a living

[swilver]

Seriously, I tried most of the IDE's you mentioned and then some, but Eclipse just blows them all away. The fact that it builds a complete syntax tree of your project which can basically be queried in any way you see fit makes refactoring so easy. It can rename method calls for an entire project, add new parameters, reorder parameters, change return code, display what methods call what method in tree form (especially if you suspect the code is dead), displays lots of very useful compiler warnings (unused parameters, variables, methods, unneeded casts, often surprising how many you can find of those in non-Eclipse projects and the possible subtle bugs they introduce). That's just scratching the surface really... it's very evident that Eclipse was written by programmers for programmers, and even after using it for more than a year it still manages to surprise me :)

Re:I code C# for a living

[rnd()]

Uh, SharpDevelop is an OSS clone of VS.NET. How could you hate one and love the other?

Re:I code C# for a living

[Three Headed Man]

Every time I see "C#" I always think of a funny comment from a poll, maybe 6 months back, of "What do you call #?" The options given were "Sharp, Hash, Pound, Channel, Tic-Tac-Toe sign" etc. The funny comment was "I call it the 'rap' sign. You know, as in C#"

Re:I code C# for a living

[fitten]

Why do you think delegates are a mis-feature?

Re:I code C# for a living

[shatfield]

It becomes very difficult to reuse stuff not from a coding point of view but because the object you have to work with is never exactly what you wanted.

This means that you just subclass the object that doesn't quite fit your needs and either extend or override the original functionality. That's the beauty of OOP -- plan well, and you're options are unlimited.

Re:I code C# for a living

[Westley]

Events as in syntactic sugar for a way of adding/removing (and firing, although that's not supported by C#) delegates in a uniform manner.

When you do:

someButton.Click += new EventHandler (Whatever);

That kind of event.

Re:I code C# for a living

[MrScience]

But it does need some
tags...

Re:I code C# for a living

[cakoose]

C# vs Java, mostly a tie (c# good: ref and out parameters, indexers, foreach; c# bad: properties, operator overloading)

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.

Re:I code C# for a living

[cduffy]

Its really nice to be able to add new code, change existing code, and arbitrarily set the execution pointer.

Re arbitrarily setting the execution pointer, see gdb's "jump" and "return" commands -- and yes, it also allows arbitrary memory changes. That said, binary patching with gdb is a royal PITA compared to the way VS automates it (yes, it can be done with gdb in some cases, but it's difficult and underdocumented).

Re:I code C# for a living

[rnd()]

I think there's something wrong with your machine... maybe you're running windows 98 or something. I have never had any of those problems. Actually since .net 1.1 it hasn't crashed at all, and it only did once or twice prior to that.

Re:I code C# for a living

[tyrione]

You said,

"I should add that all this does not apply to any APIs of the aforementioned products, in which I would agree with you (having used MFC, ATL, COM and WIN32), I don't see why informed person would choose these over the alternatives (wxWindows, stl, boost, Cocoa) if they had a choice."

Red flag. Clearly you don't know squat about Cocoa and particularly FoundationKit with AppKit, let alone I/O Kit, so on and so forth. I also don't see any mention of Objective-C. My conclusion is you don't know ObjC and the power of Cocoa and just used Java with Xcode1.5. I do recommend you revisit this with the pre-release Xcode 2.0, assuming you are a paid ADC member.

Re:I code C# for a living

[IIEFreeMan]

Can somebody explain what you mean by the covariant and contravariant things ?

I searched in wikipedia but algebra is quite far behind :)

thanks

Re:I code C# for a living

[SnprBoB86]

Out parameters are kind of neccesary if you have ref parameters. They are basically ref parameters that MUST return a value and because C# requires all variables be initalized, if you have ref, you must have out and you must force all ref params to be initalized before being passed in.

Out parameters are mainly for use with API calls that return strings and such in reference paramters.

As far as I know, nowhere does the base class library use out paramters (I am sure there is somewhere, but it is probably obscure or related to native interop).

Re:I code C# for a living

[GCP]

And I was a member of one of the JCP expert groups that brought you Java 5.

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 .Net technologies that will require a VM upgrade.

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

[panaceaa]

Anyone who doesn't call # an octothorpe by now is behind the times.

Re:I code C# for a living

[Warhaven]

...whereas Java's knockoff versions are just syntactic sugar for the writing out the equivalent source code yourself...

Just to be fair, isn't the entire C# language just one big knockoff of JAVA?

Re:I code C# for a living

[angel'o'sphere]

For covariant and contravariant exist several definitons depending on context (inheritance versus template parameters, e.g.)

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

[cakoose]

"Out" parameters are used to return more than one value. But "out" parameters are the wrong way to accomplish that. They are a holdover from the old C technique for faking multiple return values.

Re:I code C# for a living

[CanadianCrackPot]

Obviously sir you haven't touched Scheme or Lisp. Now that was one hell of a migrane (and to think recursion in C or Java usually just gives me a headache).

Re:I code C# for a living

[SlightOverdose]

Personally I can't stand checked exceptions, but to each his own.

Re:I code C# for a living

[elgaard]

>Can somebody explain what you mean by the covariant and contravariant things.

In an OO language with objects and types we may say that a type, ST is a subtype of T.
The meaning of this is that an object of type ST can be used where an object of type T is expected.

Objects of type ST can have more operations (functions) than objects of type T, but it must have the same operations as objects of type T. These operations must have the same number of arguments and results as operations in T. But the arguments to those operations does not necessarily have to be the same type.

Say T has an operation (signature): ft(a1:Ta) -> (r1:Tr)
ST must then have an operation: ft(a1:STa) -> (r1:STr)

Results are easy. A program that do:
foo:T
bar:Tr = foo.ft(...)

requires that bar have a type that are a subtype of Tr therefore
STr must be a subtype of Tr.

Arguments are more tricky: A program can do:
foo:T
ba:Ta ...=foo.ft(ba)

foo can be of type T or ST therefore ba must work as an argument to ft in objects of type ST.
This means that Ta must be a subtype of STa.
This is contravariance.
One consequense is that Array[T] is not a subtype of Array[ST] or the other way around. Because Array (or any other collection) must have both a set(T/ST) and get->(T/ST) functions and because of contravariance T must be a subtype of ST and ST a subtype of T, i.e. T==ST.

It does not work quite like that in Java, because in the foo.ft(ba) the "ft" function defined in the base class, T, would be used.

But in Java an array of a supertype is considered a supertype of an array of the subtype.

Object[] objects = new FooClass[10];
objects[0] = new Object();

Will give a runtime ArrayStoreException

Re:I code C# for a living

[GCP]

Yes, in my opinion that's mostly fair. I say mostly, though, because a knockoff is usually a subset. Those features in Java are (mostly) a subset of the goodness found in the C# version. C#, though, is not a subset of Java.

C# is an improvement on Java, but it obviously borrowed so much from Java that it is essentially Java II, which makes it sort of a "knockoff" of Java I, but it also borrowed things from Delphi, C++, and other languages that Java never had.

Microsoft was telling the truth when they said that Java, the language, was just what they needed for many of their plans. (Of course they hated the idea of Java, the platform.) If they had been able to control it, they would have forked an improved Java that would have looked a lot like C#. They weren't able to do so, so they created a new language that gave them what they wanted in a language with no strings (except their own) attached.

Part of the reason it looks so much like Java is because they are trying to attract Java developers and want to make it an easy transition, but part of the reason is that they genuinely liked Java (the language).

Re:I code C# for a living

[k8to]

Yes, OOP works beautifully, all you have to do is predict the future.

Re:I code C# for a living

[Anonymous Coward]

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.

I think that languages are pretty similar in so many ways that there's not much point in trying to claim one a clear winner. But personally I just find C# tries too hard to pack "just one more feature" in. There are things that definitely should have been left out; and in pretty much every case it's been one of mistakes C++ made. Operator overloading is specifically one such case. It's bad and evil, and not much better than multiple inheritance. The only reason to allow it is to make user types act like primitive numeric types. You can always come up with the bland old "but it's cool if I need complex numbers" argument, but otherwise it's just a complicated feature (to support by language) worth little.

Now, one could claim that if operator overloading was limited to just the most useful cases (assignment, indexing, derefencing) it might add nice amount of syntactic sugar. Maybe, maybe not; I just prefer not having the whole mess at all. Infix notation works for numbers, since that's how mathematics notation is. It doesn't have to mean a thing for user types. And finally, while leaving operator overloading wouldn't by any stretch of imagination prevent bad code from being written, leaves open one more way to write it, without getting anything else out of it expect for allowing "clever" use of indexing over collection types. And even that feature could have been implemented using methods other languages (like Python) use, to make it somewhat useful, as it doesn't try to pretend you can fully redefine meaning of infix operators.

Not surprisingly, I also thing ref types are silly, but at least it's consistent with "C++ subset" theme of C#. Also... whereas C# could have truly allowed efficient stack-based allocation, even transparently (or with just one keyword), they just screwed it up completely. Due to automatic copying etc., it's often useless for thing it should help with, performance improvements. Weird thing is Microsoft had done best research papers on subject (doing implementation in Java!), they completely failed to make anything useful out of their expertise for C#.

There are couple of nifty things C# has that would be good additions to Java; specifically delegators /event handlers. And metadata is a nifty idea, but C# implementation shows that they didn't copy it from Java -- it's pretty much alpha quality, decent idea, not too stellar implementation (including defining API... which makes it hard to fix later on)

I do agree in that returning tuples is one thing that languages in general should have... it's really strange it is not there, as adding that would be an obvious yet quite simple thing to do.

Re:I code C# for a living

[kaffiene]

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.

I disagree. Properties increase the number of entities you have to deal with - there used to be member values and member functions, now in C# you have memnber functions, member values and member properties. Many times in C# I find my code breaking because what I thought would be a property is implemented as a getter and setter or vice versa. This ends up wasting your time reading documentation to find which way getting the value is implemented. This is never a problem in java, it's always getMyVal();

The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:

A.B.C = someVal;

I beleive it's because the A.B bit puts the B value on the stack and assigning a value to it doesn't get back into A. At any rate, it doesn't work and to me it's pretty obvious that it should.

Function pointers and anonymous functions. This has got to be the biggest improvement over Java.

Again, I disagree. Function pointers are not a good feature. Implementing an interface in Java (which is the equivallent process to function pointers in C#) is better because the interface expresses a contract and the naming of the functions involved reflect that contract. What I mean is that when I see this in Java:

public void actionPerformed(ActionEvent ae)

I know that I've found a method fullfilling the ActionListener contract - what's more, the class involved will say implements ActionListener so the existence of the contract is explicit. With C# I could find a function like so:

public void myfunc(object sender)

...And that could be the end point for any old connection between classes. The good thing about OO is that the methods on classes represent the communication contract between entities. This is an important API and should be as explicit as possible, not virtually rendered anonymous as in C#

And in the end, the obvious difference between Java and C# is that Java is everywhere and open and C# isn't. Yes, .NET has *parts* of it as an ECMA standard, but ECMA standards *DONT* exclude technology which is patent encumbered. Meanwhile there are dozens of open source Java implementations and Java exists on pretty much every machine under the sun.

Re:I code C# for a living

[Trejkaz]

I'm surprised the poster above didn't mention the best IDE in existence, IntelliJ IDEA. IDEA does everything you describe and a lot more, and every time I use Eclipse I come across another missing feature which makes me miss IDEA.

Re:I code C# for a living

[rtayek]

i code java for a living (and prefer it). but java does have some catching up to do). just comparing the langages: the generics are almost useless, no operator overloading, and how would you do custom attributes in java? like: http://www.mantrotech.com/technology/csharp/articl e_customattribute.asp

thanks

Re:I code C# for a living

[maxwell demon]

I don't know about the C# implementation, but in general, it is possible to define out parameters so that they are different from return values. Namely according to the time when they are modified. Look at the following code in an hypothetical, C-like language (and to better make my point, it contains the named return value extension which for some time was part of gcc):

int global;

void test()
{
print(global);
}

int with_return() return result
{
test();
result = 5;
test();
}

void with_out(out int i)
{
test();
result = 5;
test();
}

int main()
{
global=3;
global = with_return();
test();

global=3;
with_out(global);
test();
}

This program would print out

3
3
5
3
5
5

Note the difference between the 2nd and 5th value (which come from the 2nd call of test from with_return and with_out, respectively). With out parameters, you get an instant change (reference-like behaviour), while with return values, you are producing a temporary value which then is copied to the destination.

Re:I code C# for a living

[maxwell demon]

The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:

A.B.C = someVal;

But this is not a problem with properties per se, but with the special implementation of properties in C#. I don't see a reason why an implementation of properties would not be able to allow that.

Function pointers and anonymous functions. This has got to be the biggest improvement over Java.

Again, I disagree. Function pointers are not a good feature. Implementing an interface in Java (which is the equivallent process to function pointers in C#) is better because the interface expresses a contract and the naming of the functions involved reflect that contract.

You are speaking about one specific application of function pointers, which indeed would be better solved with other concepts. Moreover your C# example is explicitly obfuscated through a terrible naming convention (which BTW is also possible for Java interfaces: What does the method public void mymethod(MyInterface mi) do?).

A simple example where function pointer make sense is the following function(I'll use C syntax since I don't know the syntax of C# function pointers):

typedef double (*real_function)(double);
double integrate(real_function f, double lower_bound, double upper_bound);

Here using interfaces would not only be overkill, it would actually be a disadvantage (what if your function comes from a different library which doesn't know anything at all about your interface? You'd have to make a wrapper for every single function of that class).

Actually function pointers aren't optimal in this case, either; the best solution here are C++ templates:

template<class Float, class Func>
Float integrate(Func f, Float lower_bound, Float upper_bound);

Of course it would be even better if one could formally specify that Func must accept function parameters of type Float and also return such without requiring that you have to explicitly have to state the conformance to that interface on your function/functor declaration or definition.

Re:I code C# for a living

[kaffiene]

But this is not a problem with properties per se, but with the special implementation of properties in C#. I don't see a reason why an implementation of properties would not be able to allow that.

But we are talking about C#, and this is the behaviour that it has. And it cannot be implementation specific, unless you're telling me that Microsoft's implementation of C# is incorrect?

You are speaking about one specific application of function pointers, which indeed would be better solved with other concepts.

I'm talking about their use as event handlers which is 99% of their use in the entirity of C#. This is hardly a niche issue.

which BTW is also possible for Java interfaces: What does the method public void mymethod(MyInterface mi) do?

Ummm... that doesn't exist anywhere in the Java APIs.

The fact is that all of the standard APIs have well named interfaces. This means you are guaranteed that the implementation of event handlers are well named in Java by design, but because of C#'s delegate system, you have no guarantees about what the event handlers are called and you have no idea from reading the class what events it handles. In other words, C# has obliterated every trace of the contract between the event producer and the event consumer. This reduces code readability, hence maintainability and is a bad thing(tm)

A simple example where function pointer make sense is the following function(I'll use C syntax since I don't know the syntax of C# function pointers): typedef double (*real_function)(double); double integrate(real_function f, double lower_bound, double upper_bound); Here using interfaces would not only be overkill, it would actually be a disadvantage (what if your function comes from a different library which doesn't know anything at all about your interface? You'd have to make a wrapper for every single function of that class).

Ahhh... you're not familiar with C#'s syntax.... that explains a bit (since the 'disadvantage' you mention for interfaces applies exactly the same to delegates for precisely the same reason). It's not the equivallent to the C/C++ function pointer - you have to declare a delegate type first which types the pointer and an event property on the event producer which provides the event, and write the code which raises the event and marshalls its parameters - so you see, C# actually has pretty much the same amount of setup work to handle these kind of things as Java, it just does it without enforcing any kind of naming standards or documenting where the end point of an event actually is.

Unlike yourself, I have actually programmed with both Java and C# (and C, C++ as well) and I can tell you from actual experience, that delegates are a mess and Java's interfaces are a much more maintainable and clean approach.

You say interfaces are overkill because is C you have the svelt:

typedef double (*real_function)(double);

That's hardly a million miles away from:

Interface realFunc { public double calculate(double in); }

Well... except that the Java version is easier to read.

Re:I code C# for a living

[fitten]

It was an honest question.

Re:I code C# for a living

[SnprBoB86]

You are 100% correct. There are many C functions that return a string by returning the string length (or a negative return code) and by putting the string into a preallocated buffer passed in as an "out" paramter.

From my understanding, the out keyword in .NET is primarily to ease the use of these functions.

Re:I code C# for a living

[cakoose]

I am aware of this behavior, but it's not usually what the programmer requires. I'm betting that 99% of the time 'out' is used, the programmer doesn't rely on this weird behavior. All he wants is multiple return values. The other 1% of the time probably consists of things you shouldn't be doing anyway :)

The advantage of tuples is that they make things more general. C, Java and C# do have tuples. It's just that they're only allowed as arguments to functions. This limitation makes it really difficult to do some things cleanly (for example, the CLR "Delegate" class is a huge back-end hack). Also, you can't pass properties as 'out' parameters because they need to be set through method invocations. Crappy tuple support is really holding back C# and I'm surprised they actually chose 'out' parameters over proper tuple support. Tuple-friendly languages have been around for a long time and so it's not even like they'd be breaking new ground.

Re:I code C# for a living

[rnd()]

I'm sure SharpDevelop will catch up soon... it has tremendous potential even to overtake VS.NET... the only thing I wanted to point out was that at this point it's largely a clone and a not quite 100% complete clone at that...

Re:I code C# for a living

[jenesuispasgoth]

Just a question... Can you change your compiler with VS and still enjoy the use of the debugger ? I mean, having a great debugger is fine, but when the compiler is buggy, there's a big problem.
In VSC++ 6, there was this funny little piece of code :

void f() { for (int i=0; i

This code doesn't compile with VC++ 6, because "i has already been declared before".
Later on, when VC++ .Net was released, they fixed the problem... As an option : there where too many developers who had been coding with the bug to make it available by default...

Re:I code C# for a living

[jenesuispasgoth]

sorry, I messed up with the code. So it is like this :

void f() {
for (int i = 0; i < i; ++i)
; // empty loop, as you can see :-)
int i = 1;
} // OK, VC++6 has already begun to go wild :-)

This code is considered wrong by VC++ <= 6

Re:I code C# for a living

[cakoose]

That's hardly a million miles away from:

Interface realFunc { public double calculate(double in); }

You're leaving out the code you need to actually use the interface you created. This is how you'd do it if you had function pointers:

list.map(&Math.sqrt);

This is how you'd do it if you didn't:

list.map(new RealFunc() {
. . double calculate(double v) {
. . . . return Math.sqrt(v);
. . }
});

Now, this could have been shorter if every function in java.lang.Math were actually a separate object that implemented the appropriate interface, but doing so would be stupid. You'd have an entire class of interfaces with completely redundant names. RealFunc is a stupid name because it gives you no new information; all you need to know is in the function signature. By giving it a name, you're essentially wasting time performing manual C++-style name mangling (for no reason at all).

Re:I code C# for a living

[cakoose]

The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:

A.B.C = someVal;

Could you elaborate? I tried this and it worked for me:

class Test {
. public static void Main() {
. . A a = new A();
. . System.Console.WriteLine(a.b.c);
. }
}
class A {
. private B _b = new B();
. public B b { get { return _b; } }
}
class B {
. private string _c = "Goose";
. public string c { get { return _c; } }
}

Were you trying something weirder than that? I know that properties aren't implemented perfectly (they don't work as "ref" or "out" parameters and they're different from fields at the bytecode level), but I'd be surprised if something a simple as this didn't work. (I tested with Mono, not with the Microsoft stuff).

The good thing about OO is that the methods on classes represent the communication contract between entities. This is an important API and should be as explicit as possible, not virtually rendered anonymous as in C#

Even with the Java method, you still wont know everything there is to know about the ActionListener . All you know is that it might be called by some source that emits ActionEvents. Who cares? You still have no idea who will call it. The bit of information about when/why it will be called is much more important than the simple fact that it is an ActionListener. The extra information is usually provided by the programmer in comments, so you're not really any much better off.

With C#, you can provide comments, but you can also set the method name to reflect what it really does, possibly eliminating the need to read the comments. (In Java, you can emulate this by providing this information in the parameter name.)

public void cancelButtonPressed(int howHard, int howLong);

public void actionPeformed(ActionEvent cancelButtonPressEvent);

Also, for each event source, you'll need to create a new inner class (another opportunity to provide a meaningful name!). This is tedious and so the most common "solution" is to send all the events into one class and explicitly demultiplex them (which, obviously, is stupid).

Re:I code C# for a living

[kaffiene]

By giving it a name, you're essentially wasting time performing manual C++-style name mangling (for no reason at all).

No. Not at all. When you have:

list.map(<thing you can insert here>)

There is a relationship between map and the thing that you insert as a parameter. This relationship has meaning and the interface attaches a name to that meaning. This is the whole point of interfaces expressing a contract between objects and not being anonymous like the C example you gave.

Look, you either get that documenting relations between classes is good, or you don't, if you're seriously upset about those couple of extra characters Java puts you through then you're probably not the kind of person who values maintenability over brevity anyway.

Re:I code C# for a living

[kaffiene]

Could you elaborate? I tried this and it worked for me:

Dude, you did notice that none of those code lines was a case of

A.B.C = someval?

Note: it's an assignment to A.B.C, you only ever read the value of A.B.C - I didn't claim that that didn't work!

Re:I code C# for a living

[maxwell demon]

I'm all for tuple support. All I wanted to say it's not entirely an either-or, because there's a semantic difference.

Re:I code C# for a living

[hotpotato]

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.

IMHO the most important difference between the two languages is checked vs. unchecked exceptions. In my experience (from C++), unchecked exceptions are completely unusable in large projects. That's because it makes relying on documentation a necessity, which is of course a Bad Thing. This alone makes C# vastly inferior to Java in my book.

Re:I code C# for a living

[cakoose]

There is a relationship between map and the thing that you insert as a parameter.

What is that relationship? Can you come up with a good name for it? The map function is extremely generic and so there's no name you can give it that will provide any more useful information than its function signature.

Regarding maintainability... Traditionally the most common maintainability issues are caused when lazy programmers forget to document things or give variables uselessly short variable names. This is why many people I've met (and you seem to be one of them) use the heuristic that verbosity increases maintainability. That heuristic will work fine a lot of the time, but it doesn't take into account that redundancy reduces maintainability. In this case, the extra interface name is redundant and will not improve maintainability.

Re:I code C# for a living

[cakoose]

Whoops, my mistake. I changed it to:

class Test {
. public static void Main() {
. . A a = new A();
. . a.b.c = "Moose";
. . System.Console.WriteLine(a.b.c);
. }
}
class A {
. private B _b = new B();
. public B b { get { return _b; } set { _b = value; } }
}
class B {
. private string _c = "Goose";
. public string c { get { return _c; } set { _c = value; } }
}

It still works. I tested with both Mono and Microsoft's 1.1 SDK.

Re:I code C# for a living

[carpus]

Let's see:
* JavaDoc (still the undiscovered killer-feature)
* A very stong Event-handling model
* Cross-platform
* API Documentation

And what exactly do you find in C# that isn't in Java, given that Java has great Properties and Events? Aside from the whole Microsoft Windows-only architecture, where does C# shine better?

Java still seems to be the choice of many enterprise system implementations as it provides a vendor-agnostic solution. There are many types of coders for these environments, including MS VisualStudio folks, Forte folks, and vi coders. Most large companies will still find both .NET and J2EE.

Re:I code C# for a living

[Westley]

JavaDoc - C# has XML documentation
Event-handling model - Java as a language doesn't have this at all
Cross-platform - yes, Java has this over .NET, although it's not a *language* feature. (Whether Mono will end up providing the answer to this remains to be seen.)
API documentation - .NET's documentation is pretty much as good as Java's, as far as I've seen. The layout is slightly less useful, but the information's still all there.

Java (as a language) *doesn't* have properties or events. It has conventions which some libraries use, but that's not the same thing.

So in short, you haven't provided any features which Java has over C#, as a language. Nor have you given any examples of ways in which C# is "abstract" (to use your term) where Java isn't.

Re:I code C# for a living

[carpus]

Perhaps I need some education. I know Java very well, C very well, but C# is less known.

JavaDoc is an automated documentation system writing out correlated HTML documentation for a code tree. Does C# have something like this?

Event-Handling Model: I guess I am speaking to Exception-handlers and the Throwable interface. What does C# do for Event-Handling?

Could you define what you mean by Properties and Events since I obviously don't follow you?

Thanks,
Matt

Re:I code C# for a living

[Westley]

Yes, C# has an automated documentation system. It uses XML documentation, which can be processed in various ways, such as by ndoc.

Event handling - exceptions aren't at all the same thing as events. If you mean that Java has checked exceptions and C# doesn't, then it's certainly a matter of debate as to which is the better approach - I'm pretty much on the fence at the moment. C# still has exceptions, an exception hierarchy etc, just without the idea of checked exceptions. Again, I have to say I've never heard this called an event-handling model before now.

C# allows properties to be defined so they use the same kind of syntax as field access, but with methods being called behind the scenes. This makes for more readable code, IMO.

C# allows events to be defined which allow clients to subscribe and unsubscribe from those events, using delegates (another thing Java doesn't have). The list of subscribed delegates is then executed when the event is "fired" or "raised".

So, for instance, you might use:

someButton.Click += new EventHandler (HandleButtonClick);

These are pretty basic parts of C# - I don't think you can really comment sensibly on the language (or the .NET platform, which is where most of the above comes from really) if you don't know this kind of thing.

I note that you *still* haven't said in which way you find C# "abstract" compared with Java...

Re:I code C# for a living

[carpus]

I never called C# abstract :)

Event handling through the Throwable interface is quite powerful as is the event-listener interface. These are easily utilized for event-handling. I have done it many times, where other objects will register with the object throwing the event (like Button-click) and when the event occurs the listener has some method executed. Perhaps C# may have a simpler method implementation (I wouldn't know) but it is not something to discount Java for not having. Or did I miss something you were saying?

Hmmmm... Allowing a method to look like a Field, and that is supposed to make *more* readable code? Sounds to me like muddying the waters so you can *really* confuse other developers. One thing I appreciate about Java is generally knowing what I'm looking at and being able to read other developers' code. Nothing like Perl for non-compiled code-obfuscation ;)

Sounds like you're full of opinions but I appreciate that you seem to value both languages.

Re:I code C# for a living

[Westley]

Apologies about the abstract business - I keep getting you mixed up with the person I originally replied to (especially when trying to post and sort other things out at the same time :)

If you really handle events by throwing exceptions, you've got the strangest exception handling code I've ever seen. Throwable isn't an interface though, it's a class.

If you could give an example of how you'd execute some listener code using the standard classes, that would help. JButton has addActionListener, for example. You implement ActionListener somewhere, subscribe to the event, and the code is executed when the button is clicked. C# is like that, except it has the model built into the language rather than just being a convention (although conventions are still involved, of course). Due to the way delegates work, you can listen for several actions in one class - no need for a separate implementation of ActionListener or the equivalent for each event. (Usually anonymous inner classes are used for this in Java, but that gets ugly pretty quickly, IMO.)

Properties make the code more readable just by getting rid of a lot of the gets/sets and brackets in your code. They aren't easily confused with fields because you shouldn't be exposing fields publicly anyway unless they're effectively constants (in which case, it doesn't matter whether they're implemented as properties or not).
Before I started actually using C#, I thought this would be a problem too. It really isn't.

(One of the things I *dislike* about C# is implicit conversions - that really *can* make things confusing.)

Yes, I'm full of opinions, having used both languages thoroughly. (I haven't used Java for a while, but a groups.google.com search for skeet@pobox.com will show that I'm hardly a stranger to it.) Valuing both C# and Java has brought me flames in the past in both the Java and C# groups respectively, unfortunately.

Re:I code C# for a living

[carpus]

Not a problem about the confusion, keeping track of discussions can be more difficult that spaghetti-code.

You're right, Throwable is a class; I was intending to speak of the approach to event-handling, not the prototype. But nice catch.

I'm willing to accept that C# is a good language. From the initial spec it looked a lot like Java, which in turn looked a lot like C (with a lot of improvements and a few limitations). I'm currently teaching myself Perl and it is reminding me how nice Java is to code in. Perl is excellent in its own right, but my coding-style and habits lend themselves to Java.

One thing which makes the whole "cross-platform" thing very important to me: I don't use Windows except when necessary. My business runs completely on Linux and only a couple customer sites force me to pop in the hard drive with Windows. So C# simply isn't an option for me at the moment. My knowledge of it is from reading but not doing. I wouldn't mind learning it, particularly the libraries. I am a security professional, so knowing at least basic hacking in the language is good. I've been looking into VBScript though. I'm not sure it will do what I need it to do, but when penetration-testing it is valuable to put code on the remote system without doing a "file-transfer" and definitely without compiling.

Keep doing the job and knowing the major players. They will both be around for some time, and getting religious about a programming language can't but hurt your career options and lessen the value of your opinion.

I do find that I am a little sensitive to Windows-only developers knocking Java either
a) without understanding it or
b) discounting many of the benefits

Microsoft has done a lot of good things over the years (security notwithstanding), and I am willing to accept that C# is one of them. I believe religious breakouts, especially amoung the non-Microsoft camps, is partly due to the possibility for the technology we have learned and loved to be discounted without cause and diminish to obscurity.

Nice chatting with you.

Re:I code C# for a living

[Westley]

I'm *still* confused as to how you handle events. To me, event handling and exceptions are entirely separate things. I wouldn't handle a button click by throwing an exception (which is what Throwable is about). I would add a listener to the event - and that's the kind of event handling that .NET and C# have built into them, rather than just using plain interfaces and classes.

By the way, C# *is* an option for you on Linux - see http://www.mono-project.com. It's not the complete .NET framework, but the bulk of it's there, and there's GTK# for GUI applications.

Re:I code C# for a living

[carpus]

Exceptions are an event, which is what I was originally getting at.

I have read code (not actually chosen this method of design myself) using Throwables and Exceptions to respond to events. When I think of "Event Handling" I think of both the Listener interfaces and Throwable/Exceptions. As I wasn't clear which type of events you were talking about, that was the first which popped into my head. Once you mentioned handling a Button click, I knew you were referring to Listeners. Not sure why that is so difficult to do, especially since once class can implement many different types of listeners, if you wish. It's about flexibility and personal choices, I suppose.

Re:I code C# for a living

[Westley]

Interesting - I don't think I've ever heard exception handling referred to as event handling before. C#/.NET has very similar exception handling to Java, just without checked exceptions. (It also has the "using" statement which makes finally blocks extremely rare, and management of resources like files significantly simpler, IMO.)

Using listeners in Java isn't particularly difficult - it's just even easier and more elegant in C#.

Re:I code C# for a living

[carpus]

Being self-taught on most the languages I use I suppose I probably don't adhere to all the standard lingo at times. If I had more 'training' I'd probably not have misinterpretted Event-Handling.

Personally, I appreciate the checked-exceptions. It has kept me from missing quite a few potential gotchas, and more importantly forced me to deal with them at least minimally at code-time. Made me think over the exception-handling decisions as I wrote code.

Good coding to you,
Carpus

Varargs?

[American AC in Paris]

That sounds like it should be some Adams-esque race of semi-competent space pirates...

Re:Varargs?

[Anonymous Coward]

That sounds like it should be some Adams-esque race of semi-competent space pirates...

You're thinking of the Variag, the Vikings who colonized Russia.

Re:Varargs?

[worst_name_ever]

No no, Varargas was the guy who drew all those pinup photos during WWII!

Re:Varargs?

[Anonymous Coward]

That sounds like it should be some Adams-esque race of semi-competent space pirates... ...much like the two languages in question...

All in it together

[Doc Ruby]

How about a cross-compiler that takes advantage of this vendor competition in cooperation to combine both communities of programmers into one pool targeting either virtual machine?

Re:All in it together

[pjt33]

Libraries? You have four options: port Java's libraries to C#; port C#'s libraries to Java; write some kind of wrapper which interfaces with both; write new libraries from scratch. All of those are harder work than bytecode translation.

Re:All in it together

[Gherald]

> How about a cross-compiler that takes advantage of this vendor competition in cooperation to combine both communities of programmers into one pool targeting either virtual machine?

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

[Cannelbrae]

Quick, someone email Bill. Slashdot wants Java.NET. ;)

Re:All in it together

[databyss]

Isn't that what we have J# for?

Re:All in it together

[arkanes]

There's a J# which is intended for porting Java code. I'm not really familiar with it so I can't say how similiar it is to Java, though.

Re:All in it together

[jungd]

ikvm.net ( http://www.ikvm.net ) is a java VM for .NET/Mono that uses classpath for the JDK API. It can also statically cross-compile java bytescodes into IL code. For example, you can compile a .jar into a .dll (even the resources are preserved).

Re:All in it together

[carpe_noctem]

You know, microsoft does have a tool that can import java code into .NET and essentially "compile" it into a c# project. I've never used it, but I've heard it works pretty well...

Re:All in it together

[VertigoAce]

J# sounds a lot like the second option. It is sort of like coding in Java but using the .Net framework. It's not really intended for anybody to start new projects with, but instead as a stepping stone between Java and C#.

Re:All in it together

[PhrostyMcByte]

IKVM is a Java VM built for Mono and MS.NET. Not exactly what you said, but it's a good start.

Re:All in it together

[mortenmo]

Trust me, we looked at that one. The "tool" can only be used in extremely simple circumstances and is not much more than a marketing trick from Microsoft.

Re:All in it together

[bobbozzo]

Still no multiple inheritance in Java?

Does/will C# have it?

Re:All in it together

[achacha]

The designers try to avoid multiple inheritance since they are aiming Java and C# to the bottom 85% of the programmers and multiple inheritance is too complex and way too many weak programmers do not understand how it works and create problems with its misuse. Give an unskilled worker a jackhammer and you can expect a call from your local utilities company. Just my observation...

Re:All in it together

[Doc Ruby]

I like it, because it reflects the material reality we already understand. Why can't the compiler and VM catch circular inheritance, like other circular references?

Re:All in it together

[Corngood]

The can and do, he doesn't know what he's talking about. You don't need multiple inheritance to make circular inheritance.

Re:All in it together

[Fnkmaster]

Yes, but are you sure it's stepping you in the right direction?

Re:All in it together

[blowdart]

C# does not have it. For 75% of circumstances using multiple interfaces does the same trick anyway.

Re:All in it together

[fitten]

Interfaces are your friends. Most of what people use multiple inheritance for can be achieved by using multiple interfaces.

Re:All in it together

[aminorex]

Java has always had multiple inheritence. Cf. the 'interface' and 'implements' keywords.

Admittedly you have to manually delegate to get re-use of implementation, which is kinda stupid (blame Gosling), but it's still there.

Re:All in it together

[Anonymous Coward]

If you've ever had to program in J# you'll know that it isn't s stepping stone, it's more like a pit of despair.

The compatibility is ancient, and it's maintained by a klunky .NET to Java abstraction layer. It just gives up on some issues cross language issues (like the signs of integers).

The only sane person who programs in J# is someone who is forced to port old Microsoft Visual J++ to .NET. But honestly, with the headaches it's given me, my advice is to just bite the bullet and either port the dam thing to real Java or real .NET and relieve yourself of this bastard child of Satan.

J# is a bad April Fools joke.

Re:All in it together

[pjt33]

Too late: Sun already has it.

Re:All in it together

[DerWulf]

That would be VB. Btw, the most wise programmer I ever spoke to (my father) thinks MI is not such a good idea. So your opinion is by far not that of the top 15%.

Re:All in it together

[Nautica]

Man you moderator! This guy is giving us links to java.net at sam spade, when the original thread was talking about java for .net and you gave him a point for something that was off-topic. (Sorta of like this post)

Re:All in it together

[pjt33]

Eh? That post hasn't been moderated at all. It's at 2 because I start there because I've excellent karma. Of course, if people want to mod it Funny, I won't be complaining: that's what I was aiming for.

Re:All in it together

[infinidim]

A interesting explanation is here.

Re:All in it together

[kubrick]

I think the question you're looking for there is "Where do you want to go today?"

Re:All in it together

[kaffiene]

I've used it.

I can tell you it does *not* work well.

Re:All in it together

[Greg Newton]

Most of what people use multiple inheritance for can be achieved by using multiple interfaces.

... and large amounts of tedious, error-prone and unnecessary work (re)implementing the same interface over and over again :-( (or at least disguising another class as that interface).

Re:All in it together

[pnatural]

the most wise programmer I ever spoke to (my father) thinks MI is not such a good idea.

Wise tho he may be, the need for MI is best explained this way:

Multiple Inheritance is like an emergency parachute. Almost all of the time, you don't need it. But when you do need it, you really need it!

Re:All in it together

[achacha]

Multiple inheritance is way complicated and most people that don't understand it, dismiss it as not useful. It's complicated enough to teach average programmers about inheritance and polymorphisms, when you add multiple inheritance along with virtual base classes, most people can't comprehend and misuse the design.

Your sampling of good developers may be limited to your dad, thus your opinion is apropriately biased.

Re:All in it together

[DerWulf]

Your sampling of good developers may be limited to your dad, thus your opinion is apropriately biased.

Quite true. Statistically it doesn't matter at all. Also, he is way old school and doesn't like the relativly new OO stuff very much. Incidentally, few days after I wrote the original post, I did need multiple inheritance. It occured to me that it is quite cumbersome to implement a new method of an interface into all it's subclasses, eventhough you need the special case making this method necessary only in one. In light of this new experience I fully agree with the first answer to the grandparent: 'usually you don't need it, but if, you need it badly'. I also agree with your point, that when using multiple inheritance the design must be well thought through. My personal guess as to why it didn't make it into java is not that java is aimed at novices (especially J2EE java is not easy) but that it was just to much trouble to implement.

Re:All in it together

[achacha]

That is true. The difficulty of MI is that it takes a bit of discipline to get it done right. The one item that makes it potentially dangerous is common base classes (ones that are not labeled virtual).

Given the following scenario:

class Human {};
class BikeDriver : public Human {};
class CarDriver : public Human {};
class AllDriver : public CarDriver, public BikeDriver {};

If you do:

AllDriver *pAll = new AllDriver();
Human *pH = (Human *)pAll;

You get an ambiguity (and luckily one that is caught by most compilers), as to which Human class instance do you want to use one that CarDriver is based on or BikeDriver?

To fix this:

class Human {};
class BikeDriver : virtual public Human {};
class CarDriver : virtual public Human {};
class AllDriver : virtual public CarDriver, virtual public BikeDriver {};

Now that example will have just 1 instance of Human class.

This is the dreaded diamond inheritance that is often brought up when talking about multiple inheritance.

In Java you can have a kind-of multiple inheritance by allowing a class to extend from another class and to implement 1 or more interfaces (abstract class in C++). This is a nice feature and a lot easier to trust people with implementing. Multiple inheritance is just a generic version of this.

There are times where inheriting from multiple classes is very useful (especially when dealing with lots of base generic classes, many of which are abstract). You can always work around it but as it stands in C++ getting rid of it without a better replacement may be a bad idea.

Fix the link

[eissimuf]

Fix that first link. It shouldn't have a slash at the end:

http://java.sun.com/j2se/1.5.0/docs/relnotes/fea tu res.html

Re:Fix the link

[eissimuf]

omg, it hates me... trying one last time Java 1.5

Re:Fix the link

[AKAImBatman]

You should have seen the original story from the future. It said, "Sun releases Java". Pretty short intro. :-)

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:

Sun releases <A href=" http:// Java 1.5</A>

(lots more text here)

Re:Fix the link

[Fenresulven]

Like this you mean?

I'm confused

[abrotman]

Where's the story? Or is this just one person's interpretation of Java vs. C#?

Re:I'm confused

[Tim C]

Why not? A few months ago it was one guy's opinion of why Java and all Java programmers suck, and why Python rules.

This is slashdot; the website is paid for (at least in part) by ad impressions, and nothing drives ad impressions like a good flamebait article, to really get people good and pissed and posting like there's no tomorrow...

Learn to write?

[Palshife]

I've never seen so many grammatical errors. You win.

Re:Learn to write?

[American AC in Paris]

Don't think of it as loaded with grammatical errors. Think of it as Compiled with (0) errors, (472) warnings ...

Re:Learn to write?

[Otter]

And the linked page doesn't exist. And (for the Java-mostly-ignorant like myself, who were wondering why 1.5 is coming out years after Java 2), it's about JDK 5.0 (aka J2SE 1.5.0). Other than that, it's a nice job by the editors.

Re:Learn to write?

[Palshife]

I've learned to blame nobody for the silly versioning Sun does for Java. Java 2 is a pretty strange moniker for a language platform with version numbers in the 1.5 range, and then calling 1.5 JDK 5.0 is just darnright batty.

But hey, we get autoboxing! See ya later longValue()!

Re:Learn to write?

[Tumbleweed]

I'd love to see his version of Hello World. :)

Re:Learn to write?

[mog007]

Maybe he takes Microsoft's stance on the issue...
"It compiles... ship it!"

Re:Learn to write?

[roror]

that would surely be

Hell World.

Re:Learn to write?

[Hell O'World]

You rang?

what about...

[syrinx]

and you're foundations in OOP is rock-solid

What about our foundations in English?

Re:what about...

[JDevers]

What about this one too?

"since both language is built to support"

Re:what about...

[yoyhed]

You missed another:

and you're foundations in OOP is rock-solid

Come on, people. Conjugate.

Re:what about...

[dAzED1]

they changed that..."both languages are" now.

flamebait

[Bert690]

It's times like this when you'd REALLY like the ability to mod the story itself as troll/flamebait!

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

[oniony]

Fully agree. The guy doesn't know what he's talking about. Java has much more support in the industry, .NET in the enterprise is currently painful. The tools are barely usable (Visual Studio debugger on a large application, anyone?) plus he makes some fundamental errors in the list. .NET does not support auto-unboxing for example (at least not .NET 1.0 or 1.1).

Re:flamebait

[Anonymous Coward]

What's a better java debugger for large applications?

Re:flamebait

[That's Unpossible!]

Java 2, SDK 1.5 what is that? Is it version 2 or NOT?

It gets worse... it is actually called Java 5 (SDK 1.5) now. Java 2 started with SDK 1.2. Not sure why they don't just start calling it by one or the other.

Re:flamebait

[micromoog]

Large applications written in Java don't have bugs.

Re:flamebait

[33degrees]

I don't know much about C# or Java, as I jumped ship from the microsoft camp before .NET and currently program in PHP, but I can say one thing; based on the emails I get from recruiting websites, there's at least twice as many java openings in my area as there are .NET. That settles the argument for me.

Re:flamebait

[p2sam]

Yeah! The Java naming conventions are almost as bad as Solaris/SunOS ... Sun should fire their marketing department!!

But here's how I see it:

Marketing names maps to Version names:

Java (1.0-1.1.x)
Java2 (1.2 - 1.4)
Java5 (1.5 - ??)

*sigh* they suck.

Re:flamebait

[jeif1k]

.NET in the enterprise is currently painful.

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

[cablepokerface]

Visual Studio debugger on a large application, anyone?

Yeah, me!
Does about 1500 classes, 340 web user controls and about 120 aspx pages do it for ya?

Don't try to make some interesting statement when you know crap about it please. It just makes people angry.

Re:flamebait

[mrogers]

Large applications written in Java are bugs. ;-p

Re:flamebait

[ecotax]

And since they won't fire them anyhow, it's fun taking a guess at the future names. My bet:

Java2005
Java XP

Re:flamebait

[Fnkmaster]

Well, I think some people might be trying to help Java compete on the desktop. Have you heard of SWT and Eclipse? It does have IBM behind it. I agree that Sun seriously dropped the ball with desktop Java for years, so nobody used it for that. As for developing desktop apps in C++, yes Visual Studio 6 was a very solid choice. Is VS.NET as good? Many people seem to think not. I haven't spent enough time with it to know, and don't really have the desire to.

Re:flamebait

[aminorex]

Personally, I expect Eclipse development using SWT to catch on, and supplant vs.net/c# development, because .net programs are such incredible resource pigs. A couple of tiny applets running at once can bury a current model laptop, easily.

Excelsior JET is an *excellent* commercial Java-to-native compiler, which eliminates that nasty JVM dependency that has been the bane of desktop Java.

Re:flamebait

[cakoose]

And how many more job openings are there for Java than there are for PHP?

Re:flamebait

[Yoda's Mum]

No, it's worse than that. It's called "Java 2 Standard Edition 5.0". And the SDK is called "Java 2 Standard Edition 5.0 SDK 1.5"

http://java.sun.com/j2se/1.5.0/index.jsp

Re:flamebait

[Tim C]

I can say with 5 years experience of developing applications of varying sizes in Java that that is bullshit. No language or technique guarantees bug-free code; some (like Java) make it easier than others, but none is perfect.

Re:flamebait

[mabinogi]

No specialised debugger for me - just the built in debugging support in Eclipse.
Or even JBuilder.
And I assume all the other IDEs have debuggers built in too.
And there's heaps of stand alone ones too. There's bound to be one that suits your needs.

hmmm....googling for "java debugger" gives a nice long list of java debuggers.

".net debugger" gives you a page full of problems with the VS debugger - headed with "The VS7.X Debugger doesn't work, What can I do?"
and one or two links that appear to be 3rd party debuggers - but aren't related to .NET at all.

I'm pretty sure that says something...I'm not quite sure what though....

Re:flamebait

[33degrees]

There are very few job openings for PHP, but considering most of the companies that use these services are quite large, it's not too surprising; PHP is not generally considered a serious contender for enterprise development.

The majority of my clients are small companies who need applications that can run on $10 a month web hosting packages, and for whom a PHP/MySql solution is ideal. I'm much happier doing that then I would be wearing a suit and tie and working for one of those big companies anyway.

Re:flamebait

[BlackStar]

*sigh* There is actually an obtuse sense to it, and I think going back to the "generation flag" with "Java 5" is actually quite sensible. If you look at the numbering conventions for Java and the reasoning (marketspeak) for the namechange it has some sense to it.

The major version number denotes a backward compatibility change that in all likelihood the Java navigators have realized probably will never happen. So market via the second number, which is meant to denote an inability to run that version on older VMs and you're set with a much better reflection of the evolution of the platform. The third number is for bugfixes and minor API enhancements. 1.1.8 should run on a 1.1.2 VM for instance, but 1.2 will not necessarily run on a 1.1.8 VM.

Re:flamebait

[kaffiene]

Java on the desktop is superior to C#. .NET doesn't even have a table component for christ's sake (Datagrid doesn't count, it's only for use with a DB)

Re:flamebait

[Trejkaz]

Hear, hear! And Sun even have libraries like JDNC and JDIC which are making desktop integration and deployment a lot more friendly. It cannot be said that Sun aren't attempting to improve their desktop integration, particularly since that was one of the major focuses of the 5.0 release!

Re:flamebait

[goonerw]

.NET doesn't even have a table component for christ's sake (Datagrid doesn't count, it's only for use with a DB)

And what pray tell do you use to populate a JTable (or equivalent) in Java? A Vector of row data and a Vector of column names.

The Datagrid in .NET can take anything that implements the IList interface. This includes the ArrayList (effectvely a Vector in Java) as well as DataSets.

Re:flamebait

[kaffiene]

Yes, a DataGrid can be populated by anything that implements IList, unfortunately, that interface is utterly impoverished - it provides no way to do simple things like re-order elements, get selection events etc....

It is designed for use by DB's - it is in no way as general and flexible as a JTable. JTable is a proper MVC component which makes no assumptions about the datamodel. See JTable's custom editors, renderers, column models, selection listeners then go look at DataGrid again and tell me they're the same.

Look - I used to work doing C# development - I *wanted* to use DataGrid for general tables - I sure as hell did *not* want to reinvent the wheel - but the reality is that for .NET they haven't got to the wheel yet as far as a basic suite of UI widgets and components is concerned.

Example other than Tables: menus - .NET menus can't even have icons in them despite that this is a W32 basic element. Java, OTOH, has had these for ages despite the rhetoric about Java being a compromise because of it's cross platform nature - the reality is quite the opposite.

Another example: Action pattern (shared action handler between button and menus) - Delphi implements this, Java implements this, .NET doesn't. And it's BASIC. Utterly primitive UI stuff that .NET *doesn't* support.

I ended up having to write an entire Table component from scratch.

Re:flamebait

[goonerw]

Yes, a DataGrid can be populated by anything that implements IList, unfortunately, that interface is utterly impoverished - it provides no way to do simple things like re-order elements, get selection events etc....

You can reorder it as long as your willing (and sadistic enough) to write a complete method for providing it with the correctly sorted rows that you ask for (Complete 1 yr old hand holding).

Another example: Action pattern (shared action handler between button and menus) - Delphi implements this, Java implements this, .NET doesn't. And it's BASIC. Utterly primitive UI stuff that .NET *doesn't* support.

What are you trying to say? That a single action handler cannot handle being called from more than one location in the GUI? .NET can do it. It works fine (except for the odd case where it seems to "forget" that there was an action to perform but that's probably in some other part of VS.NET that "forgets" some vital code.

I ended up having to write an entire Table component from scratch.

Don't suppose you have that component freely available for others?

Re:flamebait

[kaffiene]

Don't suppose you have that component freely available for others?

Sadly, no - I wrote it while working for my previous employer and under the usual IP contract rules - it's all theirs. It's a pity too, I found *some* third party tables, but they sucked - and they were charging an arm and a leg for them too (another good thing about Java - the open source mindset is very prevallent in the community)

Oh, and regarding the action handler thing - no, it's not being able to pass the same handler to more than one event producer (obviously you can do that in .NET and it works fine), it's having a single object that represents the action (handler, short name, description, icon etc...) and constructing the menu, the buttons from that. The action object gives you one place to mangage state, so that if you disable the action, it disables the associated menu, buttons and any other device that handles the action.

Again, I implemented it in C# and was pleased with the results, but again, it's closed source and lost to the world ;o)

Cue the zealots on both sides

[JUSTONEMORELATTE]

Why again can't I mod a story as -1 Flamebait?

--
I'll pay you $10. Really.

Re:Cue the zealots on both sides

[markiii]

Because if you could moderate stories, paid advertisement stories like this would get modded down,
making this way of advertising more difficult and less attractive.

It's all about the bucks!

Java 1.5 vs c# 2.0?

[hpj]

It's a bit unfair to compare the new Java 1.5 release with c# 2.0 since c# 2.0 is not due to be released until sometime Q2 or Q3 next year. But I do agree that before the 1.5 release Java had a lot of catching up to do to c#, but now c# is a bit behind (Mainly because of it's lack of support for generic classes which Java now supports).

Re:Java 1.5 vs c# 2.0?

[codepunk]

C# is alot behind because it cannot run on all the platforms that java can.

Re:Java 1.5 vs c# 2.0?

[Anonymous Coward]

Comparing an unreleased version of C# to the available version of Java is just stupid. Further, with no mention of the provided API any discussion is a waste of time. While JAVA offers a bloated API, it is extensible and great for programming, unlike dot NET 1.1 which seems to be an attempt to build OO on top of a procedural framework that doesn't provide the programmer with the same level of flexability. The other thing to consider is that dot NET means normally a purchase of Visual Studio, while JAVA normally means a free download of the JSDK and JCreator. Also IMHO Java doc is much better then the stuff that comes with dot NET. The rest is rant......

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?

[winfx]

Java's implementation of generics is just a compiler hack, the underlying byte code has not changed. The only benefits are some compiler errors and warnings and not performance and storage effiency that .net 2.0 will offer.

Re:Java 1.5 vs c# 2.0?

[traskjd]

.net 2.0 beta 1 redist. is already available and most developers already have beta1 of the new Visual Studio (you can even download C# Express for free and code to the 2.0 framework). Beta2 comes with a go-live license at that will be out early in the new year.

While you might think 2.0 is a long way off, in reality a lot of people have been using it for months (I know in my personal projects I've been coding in .net 2.0 and it's a tonne better).

Also worth noting is that in a recent TechEd04 video I watched the presenter points out that generics in Java are not as efficient as the .net ones as all the compiler does behind the scenes is chuck in your type castings for you while the CLR 2.0 actually handles it in an intelligent manner.

- JD

Re:Java 1.5 vs c# 2.0?

[mrtrumbe]

Fair enough.

But will you be releasing those apps before dotNet 2.0 is officially released (not a beta) and supported? I doubt it. I understand that 2.0 is coming, but to say it is here when the first beta was just released is a bit disingenuous, to say the least.

I applaude MS getting a beta out there and in the hands of developers. But most enterprise operations wouldn't touch a beta product from MS with a ten foot pole, and with good reason (read: history).

Taft

Re:Java 1.5 vs c# 2.0?

[mentin]

Another case where Java's implementation sucks is security: if you have a property of type Array in C#, you can be sure that runtime checks that only Foo can be inserted inside this Array. C# keeps all the metadata and enforces the correct usage.

In Java, all instanced of Array<T> are the same class, and there is no runtime type-safety. The compiler generates error if generic is incorrectly used, but you can easily bypass compiler by manipulating byte code. So if you have Array<Foo> in Java, be expecting to find Bar inside.

Re:Java 1.5 vs c# 2.0?

[PierceLabs]

So is HTML, that didn't stop people from making fubar'd versions of it as there are now fubar'd .NET implementations.

Re:Java 1.5 vs c# 2.0?

[swilver]

C's implementation of abstracting machine code is just a compiler hack, the underlying machine code has not changed. The only benefits are some compiler errors and warnings and not performance and storage efficiency that real machine code can offer.

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.

Re:Java 1.5 vs c# 2.0?

[traskjd]

Beta 2.0 is go live, when that comes out then applications written with it will start coming out. My use of Beta1 has shown to be very stable (VS2005 needs a bit more polishing but the framework itself is quite solid).

I know what you're getting at but surely you've experienced times when a beta product is already solud and when a beta product is a pile of junk? .Net 2.0 is pretty much done).

My personal view is that .net 2.0 is being held in beta because it makes no sense to Microsoft to release it until VS2005 is out to work with it. This does however provide an upside which is that the .net framework should be as solid as a rock.

Anyway, I'm just looking forward to using it all the time :-D

- JD

Re:Java 1.5 vs c# 2.0?

[AaronGTurner]

HTML doesn't run anywhere, it is simply a document type.

Re:Java 1.5 vs c# 2.0?

[AaronGTurner]

Ignore my other comment, it seems that the slashdot board didn't properly nest the comment I replied to with the parent to that

Re:Java 1.5 vs c# 2.0?

[cakoose]

You seem to imply that the VM can be crashed by bad bytecode. This is not the case. Even though the VM has a simpler type system than the Java language, it is still type-safe. The main disadvantage to Java's approach is efficiency. In Java, the VM needs to check the type dynamically on every access. Also, the primitive types have to be boxed, creating a lot of overhead in both space and time.

The other disadvantage is the lack of orthogonality. Though type erasure is perfectly OK for languages that don't rely on the ability to perform unsafe casts, C# and Java programmers use do use some weak typing and therefore depend on the ability to perform type unsafe casts. The Java compiler issues warnings for cases where a type error will not be detected as early as it should be, limiting what you can do with unsafe casts. In C#, the extra type information lets you use unsafe casts to your heart's content.

Re:Java 1.5 vs c# 2.0?

[cakoose]

How is it "just a compiler hack"? They had to modify the CLR instruction set to allow for type parameters. The underlying machine code is not the same. For reference types, the dynamic type check (which is really slow) is no longer neccessary. For value types, the code is definitely different since they'll deal directly with the values instead of dealing with them through boxes objects.

How can you claim not to care about performance at all? C# gets rid of the tedious casting and runs faster than Java. With value types, the performance difference even greater and allows programmers to use the collection classes in cases where they'd normally be forced to use arrays and do a lot of extra manual work. There is no downside. As a matter of fact, Java's downside is that you can't use generics wherever you want because the VM doesn't know about generic types and can't properly handle all the dynamic casts.

Re:Java 1.5 vs c# 2.0?

[jeif1k]

But will you be releasing those apps before dotNet 2.0 is officially released

Well, people seem to be reluctant to release code for Java 1.5 as well because there seem to be some backwards compatibility issues as well.

To me, it doesn't get interesting anyway until gcj and Mono have the features, and both of those are still several months off.

Re:Java 1.5 vs c# 2.0?

[ClosedSource]

If that's the criteria then Java is a lot behind C because it cannot run on all the platforms C can.

Re:Java 1.5 vs c# 2.0?

[Warhaven]

It's a bit unfair to compare the new Java 1.5 release with c# 2.0 since c# 2.0 is not due to be released until sometime Q2 or Q3 next year. But I do agree that before the 1.5 release Java had a lot of catching up to do to c#, but now c# is a bit behind (Mainly because of it's lack of support for generic classes which Java now supports).

Interestingly enough, I'm sure the author would also have you believe Longhorn is superior to any and every OS out there, and it's not even due 'til 2006.

Re:Java 1.5 vs c# 2.0?

[mentin]

No, in no way I implied that Java VM can be crashed by bad bytecode.

But Java programmer should be very careful with public Array<Foo> property. He might think that only objects of type Foo can be inserted into it, becase otherwise he gets compiler error. But it is possible (by fully safe code that does not have priviledges to do unsafe type casts) to insert objects of type Bar into this array.

Sometimes this is not a big problem, but often this assumption can lead to a volnurability, if the code makes security decision based on content of the array.

.NET protects programmer in this case: in .NET Array<Foo> means array of Foo, and safe code can't insert Bar into this collection.

Re:Java 1.5 vs c# 2.0?

[Da Fokka]

Comparing an unreleased version of C# to the available version of Java is just stupid.

C# 2.0 has been released, albeit it in a limited way. MSDN subscribers can download the .NET framework 2.0 and Visual Studio 2005 beta. I'm working with it and loving it, except for a few annoyances.

While JAVA offers a bloated API, it is extensible and great for programming, unlike dot NET 1.1 which seems to be an attempt to build OO on top of a procedural framework that doesn't provide the programmer with the same level of flexability.

That is just plain wrong. On .NET, C# code is compiled to IL code, which is run on a fully object-oriented VM. Java Generics do not exist in the Java VM, but .NET generics DO exist in the 2.0 VM.

The other thing to consider is that dot NET means normally a purchase of Visual Studio, while JAVA normally means a free download of the JSDK and JCreator.

Again, you are wrong. You can download a Visual Studio Express 2005 beta for free! Granted, it's crippleware but still with an impressive functionality (especially when compared to JCreator).

Hey

[gregarican]

Take it easy this article is a lot more correct then most of the ones I read here!

Re:Hey

[Majik Sznak]

Take it easy this article is a lot more correct then most of the ones I read here!

It is unclear what your goal is with that message. Just to clarify for those who don't know (and who want to learn), the correct version of that sentence is:

"Take it easy: this article is a lot more correct than most of the ones I read here!"

What Language

[jcook793]

What language was this post written in? Amazing.

Re:What Language

[rts008]

I'm reesoneebly surtan it was a Babblefish translashun of Klingon/Romulan Pigdin Universal Language, or sumthin.

Re:What Language

[logic hack]

Shhh, you'll start a perl flamewar ;)

C# and Java

[disbaldman]

Growing up as a software developer in C and C++, I'm really impressed with Java. Although it IS slower and it runs on another layer on top of the OS, it IS still very impressive because OOP gives people the chance to understand programming without having to know much besides how objects interact with each other... (Dog plays with Ball, Car has Wheels, etc.) The platform independence is also a plus, and as our processors increase in speed, the overhead of running on top of a layer which runs on top an OS will become less significant.

I want functions

[Tablizer]

I want actual functions, not "activity objects". Almost everyone, except for the extreme OO zealots, agree that OOP is not necessarily the best approach to every problem.

Re:I want functions

[MemoryDragon]

If you want functions, you can use the static imports, which sort of emulates that construct on the users level of the method. But does it really matter?

Re:I want functions

[e2d2]

There are people still arguing against OOP? How quaint.

Why not argue against managed memory while you're at it.

YES THIS IS A TROLL

HITLER

Re:I want functions

[metlin]

Dude, that was simply the best post I've seen in a long time. Thanks for a good laugh!!

Re:I want functions

[TravisWatkins]

If you like the .NET API but don't want to have to use objects for everything you could try IronPython.

Re:I want functions

[Gossy]

Managed memory reduces code size by letting the compiler/interpreter take care of stuff for you. I don't see how OO reduces code size (except in narrow limited situations). Most examples that claim to illustrate such are rigged in my observation. You are welcome to try also.

Code size isn't always the goal. OOP is designed to be easier to manage and develop in teams with, easier to maintain and more flexible to code with. The extent that it achieves these goals is another discussion entirely, but just looking at code size is a rather limited view on OOP as a whole.

Re:I want functions

[dcam]

Keep your head firmly wedged in that hold in the ground.

Re:I want functions

[Tablizer]

Code size isn't always the goal. OOP is designed to be....

I get a jillion different answers about the exact nature of OO's alleged benefits. There is no consensus. As far as I can tell, it is to get your shirts whiter.

Re:I want functions

[julesh]

What the hell are "activity objects"? I've never heard this phrase before.

If you want to do Java or .NET program without OOP think of classes as providing namespaces. And with the new static import feature in Java, you get the equivalent of C++'s "using" construct so you don't have to constantly specify which namespace you're using. And you can use classes with no methods as structure replacements, too.

As to why you would want to for anything that isn't trivially simple, I have no idea. But good luck with it anyway.

Re:I want functions

[julesh]

I don't see how OO reduces code size (except in narrow limited situations). Most examples that claim to illustrate such are rigged in my observation.

Most GUI code written in a non-OO fashion has repeated code, behaviours that are invoked by more than one widget type. For instance, the 'checkbox' and 'radio button' standard widget types have very similar behaviour, only varying in minimal ways.

What we want to do is have the same mouse handling code, but make them behave differently at the point where it's detected that the button should be switched on or off. Psuedocode in a non OO language would look like this:

if (mouse_detect_activation())
if (is_checkbox())
checkbox_activate();
else
radiobutton_activate();

Whereas in an OO language, we would not use an 'if' in the inner level there, but dispatch the call to a virtual method and make checkbox and radiobutton subclasses with different implementations.

This does produce smaller code than the non-OO implementation, and it also has the benefit of being more flexible: I could easily add another subclass if I wanted.

There is, of course, a hack that can be performed in the non-OO language by having a function pointer associated with the structure that describes your widget, and I'll admit that this is as good as the OO solution. I'll also argue that if you use it, you're doing OO programming: OO isn't about language features, it's about design. In this sense, for example, large parts of the linux kernel are object oriented. The objects are files, inodes, descriptors, filesystems superblocks, etc.

Re:I want functions

[Tablizer]

Using polymorphism instead of case/switch statements does NOT reduce code. It only moves it to a different spot. For a long, winding debate on this, see:

http://www.c2.com/cgi/wiki?SwitchStatementsSmell

As far as using function pointers (or their equiv.) in "GUI structures" being "OO", you are using a rather wide definition of OO. Interchanging code with data is much older than OO. OO is mostly about putting behavioral wrappers around data structures, not putting function references/pointers inside of structures.

Re:If sun dies...

[fitten]

Actually... whoever buys the remnants of Sun will "pick it up" and do whatever they want with it.

Too bad we can't mod articles

[MojoRilla]

This would get a -1 Flamebait.

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

[Slime-dogg]

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.

Re:Too bad we can't mod articles

[rabtech]

Java is hardly the first platform to have a VM and use bytecodes; VB through version 4 (optional in 5 & 6) compiled to pcode (bytecode) and ran with the help of MSVBVM - the VB virtual machine.

There are other examples that go even further back.

We all stand on the shoulders of giants and to whine about who stole from who is stupid.

Re:Too bad we can't mod articles

[kaffiene]

Yeah and Delphi is such a *great* environment to copy. You're right - VS .NET borrows heavily from Delphi and suffers from the same moronic view that the GUI is the sole organising structure for your code.

But... jeez, if you can't see that C# borrowed from Java you're past blind and into the "willfully stupid" catagory. C# is Java by people who just didn't get it in the first place.

Static Import Bad?

[Qwertie]

It is certainly useful in some situations -- the Math class being the best example I can think of. The fact is, object orientation isn't a universal model of everything; some things, like algorithms, and even singletons, just don't have any need to be "objects". Static Import lets you drop that OO pretense. In the case of Math, where's the bad style in writing Cos(x) instead of Math.Cos(x)?

Re:Static Import Bad?

[fishbowl]

"In the case of Math, where's the bad style in writing Cos(x) instead of Math.Cos(x)?"

None at all, but I cannot count the number of times I have had to change a co-worker's static members into Object methods because of a side-effect of some other change. And don't even get me started on what a nightmare static { ... } can be.

From the Horse's Mouth - might make more sense

[Anonymous Coward]

Maybe it makes more sense to listen to what the tech lead of Java 1.5 had to say here.

(= Calvin Austin)

Flaws in both Languages

[Dante Shamest]

Neither are open source.

Both require virtual machines.

Despite being marketed as portable, but have portability issues. Java is not backward compatible with older versions. C# has problems with porting some of the graphics stuff to Linux.

We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.

They're closely tied to their respective companies.

If you think this is flame-bait, check out this article's title.

Re:Flaws in both Languages

[jonathanduty]

c# runs ontop of a virtual machine ? (I'm not a c# programmer). So c# runs ontop of a virtual machine that only runs on MS windows? Do I have this right?

If so... um... why does c# exist?

Re:Flaws in both Languages

[lakcaj]

Since when is C# "marketed as portable"? This is MS's baby, and they don't give a shit if it runs on Linux or the Mac. The Mono project has nothing to do with MS or its C# development team.

Re:Flaws in both Languages

[SlashdotMeNow]

If you think PHP or PERL can come close to either Java or C#, then you, Sir, are an idiot.

Re:Flaws in both Languages

[Qwertie]

Microsoft also offers a virtual machine in the form of "rotor" for BSD and IIRC, MacOS X. The Mono and DotGNU projects offer .NET virtual machines for Linux.

Re:Flaws in both Languages

[scovetta]

You use PHP/Perl on a server? For something other than adding phpbb to your homemade website? Sorry, but PHP/Perl serves a purpose, and so do Java/C#, and they two are almost mutually exclusive.

For enterprise-grade web-applications (not hacks), it's .NET or Java. For real applications, it's either .NET, Java, or C++.

End of story. Don't argue with me, just accept it.

Re:Flaws in both Languages

[nat5an]

Who modded the parent up? The post is woefully inaccurate.

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

[Kihaji]

Explain to me exactly how *any* language is Open Source. Please, I really want to know. How does any language satisfy the 10 criteria http://www.opensource.org/docs/definition.php Next time you decide to spout off at the mouth, have an original thought.

Re:Flaws in both Languages

[danharan]

Neither are open source.

Yeah, so?

Both require virtual machines.

Again, so what? How is that a flaw?

Despite being marketed as portable, but have portability issues

Look in particular at MS for that. As for backwards compatibility, it's not that big a deal.

We don't really need them.

YOU don't believe you need them, and you may be right at that. Come do some server-side work in my workplace and see if you can do what we do with Perl or PHP. You remind me of MySQL 3.23 fanboys that have never actually needed a stored proc or sub-selects.

They're closely tied to their respective companies.

What? How is that a flaw in the language? And have you any idea how many other big companies (say, oh, IBM) have invested heavily in Java?

Re:Flaws in both Languages

[X]

Let's take these one at a time here:

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

[greg_barton]

Neither are open source.

Don't want to get into a religious argument here. Being 100% open source is not always a benefit.

Both require virtual machines.

Really?

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?

Re:Flaws in both Languages

[KZigurs]

This is flamebait. If you have no need for seroius programming, this don't means others don't. And try to support 500 page site written in PHP and the same - in Java. There is a difference. Therefore, we need, Java. And, we need, C#. Ok, they are not ideal languages, but, they are more or less the best mainstream languages we have now. And, at least, they don't degrade programmers the way PHP do*.

Also, PHP STILL DOES NOT have anything that remotely resembles ide. Bad. Really, really, bad.

IntelliJIdea and Java allows me to be much more productive and write better code, because I don't have to live in jet another text editor with sintax coloring added just to call it an IDE. (they don't pay me. It's just a fact. I don't have to think about writing code or looking up variables, I can concentrate on functionality. And, no, I don't use wizards (especially since there are no wizards to optimize Java midlets code to bytecode level))

But, please remember, each language is for it's own purposes. Why being interpretated (PHP, Perl, Python) is better than having virtual machine?

From my point of view -

Java. A nice language, but the API sucks. It's ye good old SUN that develops MIDP standart and forgets to add function drawPixel to canvas.

C# - Also, quite good, language. Lacks proper operating envorement, is too closely tied to M$ api, but a really good one anyway.

I can work in both. Just as in LISP, Python, PHP, C++ or perl. None is better, each is more suited for it's own tasks.

le fin.

*About PHP degrading developers - Unfourtonately, I has to say, a lot of students coming out of university choose to work with PHP firsthand. It's web developement, it's easier to get first job there, et cera. But, once starting to learn PHP, quite soon they are incapable to think about software design and how their code works. Maybe because programming with some kind of architecture in PHP is a pain in the ass task and nobody knows how PHP code executes in real life?

Re:Flaws in both Languages

[pjt33]

Java is not backward compatible with older versions.

In what way? Backwards compatibility has always been a high priority with Java, and while you do get occasional changes in behaviour they're mostly in obscure areas of the API.

Re:Flaws in both Languages

[PCM2]

Short answer is that portability is not the purpose of the virtual machine for C# (and for many people, it's not the purpose of using the Java virtual machine).

Re:Flaws in both Languages

[Teckla]

# 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 versions. C# has problems with porting some of the graphics stuff to Linux.

I work for a software company whose products target half a dozen operating systems, and based on ample experience, I can say using Java has simplified our life remarkably in terms of portability. Is it perfect? No. But just because it isn't perfect doesn't mean it's not a huge step forward in terms of making it easy to write portable code.

# We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.

We don't really "need" PHP/Perl/C++/Python either, now do we? This comment is just plain meaningless.

# They're closely tied to their respective companies.

With all due respect, this is about the only thing that makes sense in your entire post.

Re:Flaws in both Languages

[X]

He was right about that. If you compile code for JDK 1.5 and try to run it on an older VM, you'll typically get an error. Unfortunately Sun keeps tweaking things. :-(

Re:Flaws in both Languages

[pjt33]

That's forwards compatibility, not backwards compatibility.

Re:Flaws in both Languages

[Tony Hoyle]

I call bullshit.

Ever tried to compile a JDK 1.3 program in JDK 1.4? The last place I worked for actually gave up trying to port it, because there were so many differences (it didn't help that the IDE we were using was JDK 1.3 only so we were reduced to command line, which had a big effect).

Re:Flaws in both Languages

[X]

Too right. What was I thinking! The cases where backwards compatibility have been broken are far more limited, but they do exist. Typically they involve API changes.

Re:Flaws in both Languages

[Nukenin]

I refuse to accept "enterprise-grade web-applications" period. As for real applications, code 'em with whatever gets the job done and meets the customer's expectations.

Re:Flaws in both Languages

[Hakubi_Washu]

>Really, when you think about it, we only really need C.
We don't need C, not even Assembler, to be precise. Machine language is, technically, sufficient. :-)
Don't believe me?
Well, the lazy guys over at Menuet have coded a graphic OS, including alpha transparency in assembler (that's why I said "lazy", should've done it in machine language for extra geek-points :-).
It fits a floppy and is rumored to be ultra-fast...

Re:Flaws in both Languages

[Hezaurus]

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?

Java is 'open source'. Everything: JDK classes and the virtual machine, all are there for everyone to see. Sun owns the Java trademark and is in control of what language features are in and what are out.

.NET is not open source. Correct me if I'm wrong but I think that the CLR source isn't available. C# is a standardized language. That means that 'theoretically' other parties can influence the direction of the language in the future.

.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.

Sun's Java VM has had JIT compilation already in the last millennium. Java is not interpreted, it's native code just like your regular C. HotSpot compiler compiles those pieces that get the most action and interprets those that don't benefit from compiling.

CLR and Java VM are essentially the same thing. CLR is more flexible (it supports more languages, even though the list of currently supported languages is actually bigger for Java VM) and you can mix different languages for the same project. They both have advanced garbage collection schemes and both run 'inside' a virtual machine, although in C# you can 'step outside' (unmanaged mode) to do your own memory management (which is a big bonus for some projects).

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.

Duh!

Re:Flaws in both Languages

[scovetta]

As soon as people mention "enterprise-grade web applications" it's time to skip to the next thread. These people live in a little world that's been built for them by small minded project managers, clueless clients, and a university programming course that's been bought and paid for by a large corporation (usually Sun Microsystems).

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:

1. Does what the customers want
2. Secure
3. Database-driven
4. Clustered/clusterable
5. ***Maintainable***
6. Performs well
7. Integrates with other systems
8. Deliverable by the deadline

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

[goon america]

Bit ironic coming from someone posting to a web site that's written in perl.

Slashdot, livejournal, wikipedia, sourceforge, yahoo... we're talking about sites that get 100+ hits a second, and... oh no... written in PHP or perl??

(Not that I'm bashing .NET or Java. They can really kick ass if you know how to use them. In my fantasy world, someone has designed PHP.NET, php for ASP.NET using mono. Also, I am a captain of industry, the Iraq war wasn't planned by these monkeys and have the power to grant wishes.)

Re:Flaws in both Languages

[antoy]

Java is 'open source'. Everything: JDK classes and the virtual machine, all are there for everyone to see. Sun owns the Java trademark and is in control of what language features are in and what are out.

I am under the impression that they aren't. There exists a open-source implementation of Java, but the virtual machine and SDK provided by Sun do not have the source with them, and it is generally not available. Sun rejected the pleas of the open source community to open-source Java (link)

.NET is not open source. Correct me if I'm wrong but I think that the CLR source isn't available. C# is a standardized language. That means that 'theoretically' other parties can influence the direction of the language in the future.

Correct, the MS .NET implementation is not open-source. But as is the case with Java, the SDK and compiler is free and open-source implementations such as Mono are not fought against. In fact, one can argue that Microsoft is more open-source-friendly: The language and CLI is standardized which makes the life of compiler programmers easier (par example, Mono already has many C# 2.0 features, even though MS's own 2.0 compiler is still in beta). Also Microsoft provides a Shared Source-licensed implementation of .NET called Rotor

Re:Flaws in both Languages

[Hezaurus]

I am under the impression that they aren't. There exists a open-source implementation of Java, but the virtual machine and SDK provided by Sun do not have the source with them, and it is generally not available. Sun rejected the pleas of the open source community to open-source Java (link)

here. You need to create an account to be able to download. There's HotSpot client and server VM sources for different platforms and processor architectures. I'm pretty sure MS has studied these carefully when cop*ing *cough* implementing their own.
NetBeans IDE is also open source.

Re:Flaws in both Languages

[maxwell demon]

The ideal geek computer has of course just one key for input and one LED for output.

You may think you need two keys (one for 0 and one for 1), but that's not true, since the key has two states (pressed, not pressed) and that's enough as was known since the times of Morse.

And of course if you enter your zeros and ones directly, you'll naturally make very small executables :-)

Re:Flaws in both Languages

[Hakubi_Washu]

Now, THAT'S a geek to my tastes :-P

Re:Flaws in both Languages

[Decaff]

Java is not open source in any way.

Oh come on! Seeing the source code is a HUGE difference from not being able to see it...

Re:Flaws in both Languages

[X]

You have a curious definition of open source. Check the license for Sun' Java VM. It's not an open source license. There are some Java VM's which are open source, but I have yet to see what that is both certified as being Java and is open source. The language specification and the API aren't code, nor are they provided under a license which conforms to the open source definition.

Java doesn't require the JVM. Indeed, you can run it on the CLR. ;-) Take a look at gcj. No JVM there. Works just fine.

As for my comment about C.. that was sarcasm, intending to demonstrate the stupidity of the parent's assertion that Java and C# were flawed because he was able to do all he needed with PHP/Perl/C.

Re:Flaws in both Languages

[Hezaurus]

> This is nonsense. Please read the license terms. > Java is not open source in any way.

This is nonsense? The source code to all platform dependent implementations of the virtual machine and all the API sources are available.

Obviously they're not letting you to take the credit and distribute/sell it to customers that don't have a clue (MS already tried to do that, luckily they lost the case). You can however: modify the code to your hearts content as long as you keep it within your company.

Now please explain where are the sources to Windows Forms and CLR. How can I check those to see if there're any MS specific 'extensions' not available to other parties? It would be also nice to see how many lines of Sun's VM have been verbatim copied to CLR.

Why is there a C# advertisement on /.?

[Cloudgatherer]

Seriously, this looks like an ad for C#, a bunch of claims with very little support/evidence for those claims.

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 /.?

[jrumney]

I've worked on C# and Java projects. As far as I'm concerned, C# = MS Java.

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.

templates

[minus_273]

After templates (generics) come out in a few months, i dont expect java to have an easy time catching up.Personally, I really miss templates from C++ and would drift over to the camp that offers it.

Re:templates

[ArbitraryConstant]

Java 1.5 supports templates/generics/whatever.

Re:templates

[21mhz]

What is it? Hordes of classes, all alike, auto-instantiated in memory? Noooooo!

The Java 5's generics have actually struck a good balance between syntactic sugar and resource usage considerations. Plus they translate onto standard bytecodes, so your provider's J2SE 1.4 deployment may run your generic classes (if you're careful with other novelties, that is).

Corrected URL

[waynegoode]

The first link does not work. For the few who might not notice that the problem is the extra / at the end, thep link should be this.

Perhaps /. will correct the error. I emailed the editor when the story was in preview, but it was too late.

I call bullshit

[The Bungi]

There is no apparent point to this "story". It's full of grammatical errors and obvious flamebait arguments (flamebait in the context of the slashbot groupthink). What, "C# is teh roxx0rz and Java.. well, I forgot teh point I was makeing for Java"? "The open source crap argument"? Way to go.

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.

the crap argument

[iamchaos]

Is this article flamebait? Maybe I am just misunderstanding when he says:

"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

Re:the crap argument

[KZigurs]

he is right.

In commercial developement there are different values.

Really Good Ide. A MUST. There is no way your averange programmers will work day to day in a text editor. There has to be a layer that catches some of their mistakes and highlights others.
(winner: Java. IntelliJIdean and Sun Java SDK. Nuff said)

API. Even more important. Remember, the software, occasionally, is written for the client (yes, yes, I know this is not the usual case with hardcore /.ers who programm their doorbell in ASM, but anyway). Good API ensures consistent visual representation on the platform intented and, preferrably, on similar platforms too. Client would be quite unhappy if you would hadle them perl cripts with a READ_ME where configuration process (replacing strings in source using regexps) would be described. They want GUI.
(Winner: C++/C#. On Windows.)

Consistency. What point to invest in language or technology if each release of it creates a totall mess trying to clean up our own code because there are some "small improvements" to the api. If you made it stupid first time, don't change it. There is code that relies on that.
(Winner: none. They All Suck. But from my experience nether Java, nether C# isn't the worst offenders).

Open source. This is not an argument. In fact, for enterprise world, open source sounds much more problematic than any of good old microsoft solutions. They are GUARANTEED to receive support, should they need it, they are guaranteed to have an access to consistent and high quality materials as a reference instead of "take a look at that and that site (full of dirty jokes, 1st semester level 'solutions' and racism)".

And as regards to writing enterprise software with mod_perl - good luck. I'll take a look at you when you will keep supporting it for the next 20 years. The language just isn't meant for this.
But, in example, Java is. It allows me to implement some nifty features like code autoupdate or object lifecycle monitoring without any hassle. And, it shows up to be so simple, that even newbies that could be looking at my code could understand that.

Re:the crap argument

[killjoe]

"Really Good Ide. "

Eclipse supports most languages including python, php, perl and ruby.

"API."

Perl, Python, Ruby and PHP have enourmous libraries to make whatever you are attempting easy.

"Consistency. "

The languages I have mentioned have been "pretty consistent". No language is completely static and each language is trying to improve the best way they know how but they have all kept backwards compatibility pretty good.

"Open source. This is not an argument. In fact, for enterprise world, open source sounds much more problematic than any of good old microsoft solutions."

Well this certainly explains why nobody is using mysql, linux, apache, bind, jboss or any other open source project in any enterprise whatsoever. By golly I think you have something here. Which leads me to.

"They are GUARANTEED to receive support, "

Gee only if there was one or two companies who provided support for open source projects. Too bad you can't buy support from companies like IBM, Novell, RedHat, Mysql etc. Wouldn't that be cool if you could buy support for open source projects.

BTW I am happy that MS provides GUARANTEED support. All those people who bitch about the crappy MS support and documents are all probably liars or open source racist hippies who enjoy dirty jokes.

Re:the crap argument

[cayce]

"forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby..."

I believe he meant the "OpenSource crap arguments" as:

"Sun should make java open source"

"Sun is bad bad, OS community should take care of Java"

etc, etc.

Maybe he was trying to drive people away from that argument instead of focusing on this other arguments. Which (btw) are as good as that one to start a flame war.

Re:the crap argument

[Peter Harris]

Really Good Ide. A MUST. There is no way your averange programmers will work day to day in a text editor.

But GOOD programmers will... Never mind, they probably will want a pretty IDE too if forced to use Java or C#.

varargs

[$RANDOMLUSER]

I never did understand the need/desire for varargs in Java. Isn't that what polymorphism is for?

Re:varargs

[ultrabot]

I never did understand the need/desire for varargs in Java. Isn't that what polymorphism is for?

Now, I'm enthusiastically waiting for you to sketch the relationship between polymorphism and varargs. The way I see it, there is none.

Hint: polymorphism means dynamically determining the method to execute from the object at runtime. In the context of Java and C++ at least. Think "virtual functions" if that helps.

Re:varargs

[Qwertie]

Say what? Polymorphism != varargs. Varargs is for things like printf, fprintf, and, uh.... sprintf. Ahh, what a great field of possibilities it opens up!

Re:varargs

[SlipJig]

Polymorphism addresses the strict need, but makes you write extra code. In cases where you need to pass varying numbers of parameters of the same type, let's say from 1 to 10 strings, polymorphism does work, because you know before compiling how many parameters you need. But it's cleaner to write a single method to handle them, than to write one real method and 9 overloads; or to bundle the strings into a collection or array before passing them.

In cases where you don't know how many arguments you need to pass until runtime, both approaches are useless and you need to use a collection of some sort.

We're talking about some fairly specific cases here, but this enhancement does have the potential to clean up the code (and docs). Simplifying APIs is good all around.

Re:varargs

[CableModemSniper]

Woe is me! for I have just wasted all my mod points on the stupid Neal Stephenson story.

Re:varargs

[CountBrass]

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 horribly absued: so overall I think Java was better off without them.

Personally I think that, overall, Java 5.0 is a mistake. Metadata is already going out of fashion: Google for "metadata hell" to read why. It's a passing fad that's passing. Autoboxing/unboxing *shrug* nice when you need it, but how often do you actually need it? Generics/templates was something I missed when I first moved from C++ to Java 10 years ago: but now it feels like more unnecessary complexity.

So overall it seems to me the 1.5 changes address some limited circumstances at the cost of additional complexity; and no doubt we'll see them mis-used and abused and that will outweigh any benefit by an order of magnitude.

What they should have done in 1.5 is strip out all the deprecated crap: Sun has this habit of constantly adding layers but never actually removing the old stuff. I really would hate to be learning Java now: it's so bloody big!

Re:varargs

[sbrown123]

Autoboxing/unboxing *shrug* nice when you need it, but how often do you actually need it?

I love this feature. Currently I have to do this sort of crap all the time:

String to int:

new Integer("1").intValue();

or parseInt

int to String:

String.valueOf(1);

In truth, Java should have dropped the primitive types altogether and went with a 100% object approach and allow things like this:

Integer _integer = 3;
Long _long = 5;
Number _number = _integer + _long;
_number--;

The above would be total sweetness.

What they should have done in 1.5 is strip out all the deprecated crap

Agreed. First to go: java.util.Date. And fix Calendar to be actually usefull.

Version

[xPhoenix]

So which version number is it? Java 2, Java 1.5, or Java 5? Someone should teach these guys to count before they start coding!

Re:Version

[msuzio]

Yeah, I hate that too. I never used the term Java 2, though, and I'll be damned if Java 5 is going to cross my lips. It's marketing-speak of the worst sort.

Re:Version

[CmdrMooCow]

Well, they're going off the same old numbering scheme:

one...
two...
FIVE!

Re:Version

[jack_csk]

Ya, just like SunOS 5 == Solaris 2. It's SUN's style, don't you know?

Optimization models

[scumbucket]

Java has a few advantages over C# in optimization. It's very easy to analyze Java programs to be certain that certain memory locations absolutely will not be modified. That's much harder in languages with native pointers. Those invariants allow you to compile out certain calculations that would have to be done at runtime in a C# program. You can even start spreading loop cycles over multiple CPUs, but I'm pretty certain that the present JVMs aren't that smart.

Re:Optimization models

[Qwertie]

Right as you may be, most C# programs don't use pointers, and if they do, the VM can detect it (it has to detect unsafe code such as pointer use in order to prohibit it from running in a web browser, for instance)

Re:Optimization models

[Headius]

Several JVMs use an m:n threading model (such as BEA's JRockit) that allows individual Java threads to be handled by different processor threads; this results in some extreme scalability, but obviously adds complexity to the JVM (since it is now required to manage both "green" and "real" threads). I don't believe either the .NET VM or Mono suppose m:n threading (yet).

FYI.

Re:APIs

[Palshife]

XML Parser

You mean like JAXP and JAXB?

Nevermind...

[waynegoode]

It has been corrected now.

Mistake

[ajs]

I'm not pleased with the "catch-up" game that Java is playing here. Java was a fairly nice middle-ground betweeen high and low level programming, and what appears to be an effort to become a high level language is rather ominous for those who are interested in testability and performance in Java.

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

[Sanity]

Java was a fairly nice middle-ground betweeen high and low level programming, and what appears to be an effort to become a high level language is rather ominous for those who are interested in testability and performance in Java.

Generics improve testability because they largely eliminate runtime ClassCastExceptions. I haven't seen any evidence to show that any of these features impose a performance penalty. Most just make the developers life easier by saving them from repeating common code patterns.

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.

Yeah, because hardly any companies are driven by their bottom lines...

Re:Mistake

[Derkec]

I'm still not seeing a real need for Generics. They complicate the language by giving us more syntax to learn while providing very little.

If we're supposed to have a collection of rocks, what the heck would paper be doing in there? More often than not, reasonable coding should prevent this.

The key place where this might make sense is when you're producing an API for external consumption. There, it might be nice to say that the collection being thrown back at the user is all of one type or another.

Re:Mistake

[WaterBreath]

Yes, arguably you don't want your language to be controlled by a company which in turn has a marketing-driven bottom-line. Because likely the language will be imperfect, and limited in use to what the creators want/need it used for. But how many truly enterprise-class solutions (I'm talking hundreds of thousands, if not millions of lines of code here: such as PlumTree's web portal architecture) out there are written in any other type of language? I've alread seen lists here, but to be fair, a competing list for C# or Java would be far longer, and that's the important point.

C++ is the only "open-source" language that has seen widespread enterprise-level use, and I would argue that this is only because the "big players" adopted it before they had the ability to make their own tailor-made languages. Now that it can be argued that C++ is getting to be outdated, the big players have not only the capital and the know-how, but an excuse, to make their own languages which they can make money with.

And there's the rub. There is too much money behind marketing-driven languages for them to be going anywhere soon. They have the resources to make them useful. And just because a language is imperfect doesn't make it not useful. So marketing-driven, imperfect languages are going to continue to thrive on the enterprise level, because the market is the only entity with the resource and the need for enterprise-level solutions. This will become even more pervasive as "enterprise-level" solutions continue to get bigger and bigger.

Re:Mistake

[WaterBreath]

I think you're misunderstanding the nature of generics. Generics don't allow rock and paper objects to be stored together in the same collection. (No, that's what pervasive base classes such as Object in Java, C#, VB, etc. allow.) Generics allow you to write one class and use separate instances of that one single class to create, at run-time, type-safe rock collections, and paper collections, and scissor collections, etc., etc.

Of course that is merely the tip of the iceberg of the power of generics. C++ templates are a Turing-complete language in their own right, and when used correctly can do many of the things LISP programs can do, except executed at compile time.

Re:Mistake

[Fnkmaster]

The ONLY reason this took so long is Sun was unwilling to add language features until C# forced them to. Real Java developers have been arguing for Generics since ... well, since they first had to work in Java. Yes, Java is not a fun language to work in as Paul Graham aptly points out, because it takes into account the balance between developer features and code consistency/readability. I can sit down at almost anybody's Java code and comprehend it far faster than I can your average chunk of C++ that's been "spruced up" with lots of spiffy language features, for example.

Anyway, a bit of syntactic sugar does tip the balance away from "here's the one way of doing things" which made large Java projects easy to manage and to ramp up new developers on (relatively speaking), but if it saves a substantial amount of typing time and energy with minimal readability sacrificed, it's probably worth it. And Generics are just necessary, in my opinion, since you end up using too many non-typesafe constructs in Java that open things up to runtime errors.

The only thing on this list that I'm not sure how I feel about is the boxing/unboxing thing. I don't know if I like the idea of autoboxing, since it can create hard-to-track-down performance issues with object allocation. But I guess people liked it enough in C# that it was deemed a worthwhile tradeoff.

Re:Mistake

[scruffy]

By the next version or two, Java and C# will make C++ look simple with the additional advantage of not being a moving target.

Sure, each new feature will apparently simplify some aspect of programming, but it also increases the learning curve. You are not going to get simplicity by increasing complexity.

I look forward to the next new OOP language will arise because Java/C# will have become too complex.

Re:Mistake

[blowdart]

If we're supposed to have a collection of rocks, what the heck would paper be doing in there? More often than not, reasonable coding should prevent this

That is not what generics do, that's what your base collections of type object does. Generics (at least in c#) allow you to write templated code like

class List<T> {...}

where T is the type parameter. it actually comes time to create a List object, you say List or List. Now your list is a type safe list of ints or Customers, instantiated at runtime. You cannot mix ints and Customers in the same list.

The Java implementation is a compiler hack. It casts everything to objects, so in theory you could mix because it's just a compiler trick. Worse because everything is really an object you can't reflect over the List and work out what type it is a list of.

Re:Mistake

[mmusson]

You aren't alone. See this thread.

Part of the confusion is that the name Generics implies that it is something it is not, to people with more experience than just java.

In a nutshell, java generics give you type-safe containers. Properly used, this will shift runtime ClassCastExceptions to compile time. You will not need to explicitly cast items coming out of the collection. That's all it does.

The real tragedy with generics is what it could have been. Just do a google search; a lot of people are unhappy about the consequences of erasure. And Sun's justification for erasure is not satisfying.

Re:Mistake

[Fnkmaster]

I would be a lot more excited about Java Generics if it was more than just syntactic sugar. It is really the worst possible template system I can think of.

I'm curious to understand this. I will admit, I've been out of the active Java development community for several years now, so I'm not exactly sure what you think is so terrible about Java generics. I just checked out the Java Generics tutorial PDF, and it looks like generics just compile to bytecode once, they don't result in separate bytecode junks for each different generic invocation, unlike a C++ template. I haven't really thought this out though, what downsides does this technique have? Presumably it means things aren't as fast as they would be without generics, but is this difference noticeable? What other problems are there with Java Generics?

Re:Mistake

[Fnkmaster]

Hmm, I just found this bit, admittedly from the lead architect of C#, so I'll take with a grain of salt, but if this is true, it's a bit lame (I also found this, which is from a somewhat more trustworthy source). Damn.

Also, another piece from Bruce Eckel here. This is even more clear in its skewering of Java Generics. It really sounds like Sun dropped the ball on this one.

Re:Mistake

[ajs]

Ah... ok, who mentioned C++?

Were you responding to my comment about C?

Re:Mistake

[ajs]

C++ is the only "open-source" language that has seen widespread enterprise-level use

Ah... no it's not, not by a long shot.

In certain areas (end-user, non-Web-based UI design for example), I would agree that non-OSS and C++ are the only languages that match your description. But you're not thinking in terms of lines of code in use in such organizations, you're thinking of "high profile" projects.

Perl is probably the single most widely used programming language for what it was originally desgined for: report generation (followed closely by a very fragmented field of: VB, Java, Access, Cobol and such high-priced report-ware as Crystal). Perl is edged out by shell as a systems admin language under Unix and Linux, but since most tasks which grow larger than a certain size in shell end up being re-written in Perl....

C has an immense following, and probably will continue to even as C++ and the other C-derived languages contiue to add features. As corporate addoption of Linux continues, expect to see a resurgence of C usage as well.

And of course, the single most widely used programming language in the history of so-called "enterprise computing" is JavaScript (originally LiveScript), a truly open source language invented by Netscape, whose reference implementation is distributed under the MPL in Mozilla.

You really have to define what you mean by enterprise-level use, though. For example, the fortune 20 include IBM, Verizon and HP, all of which use (and even contribute to) many of the languages described above as well as many others. IBM also accounts for much of the hosting of services (including a lot of things you would never think of unless you're involved in it) for the Fortune 500, and in that capacity they write a lot of code in a number of open source langauges. Further down the list of the Fortune 500 you'll find Apple (who continue to champion Objective-C, making it a defacto member of the list, as it is shipped with, and used for most UI-development in their OS).

Interesting question though... what really ARE the most widely used languages among the largest businesses in the world. I think we might be surprised.

Re:Mistake

[WaterBreath]

I openly admit poor judgment on my part. I'm acquainted with this field, but not an expert by far. I made too many conjectures, rather than sticking with what I'm sure about.

In my defense (kind of), I think you're right, I was thinking of "high profile" projects, rather than what I said.

I do believe one of my points though was valid. That being that the languages in discussion can't be dismissed as "bad" just because there are valid complaints against them. They see such widespread use because they are useful and cheap. It's much easier to find and pay for C#/Java developers than it is to find developers for the more esoteric but stronger languages. And for most of the applications for which they are used, the tradeoffs involved in using other languages just aren't worth the money/time/effort of finding experienced developers and preparing an infrastructure to support the language and the developers.

There's litte that can be done to fight that unless open-source volunteers start donating money, in addition to time, to market (both to businesses and to schools) the stronger languages they love.

Re:Mistake

[ajs]

I would not dream of dismissing any language as "bad". There are languages which are used for the wrong purpose (e.g. TCL), but I'm not sure what a "bad language" would be.

Java is a good language, though I'm not too pleased with most of the implementations in terms of their integration with the local system, but that's a matter of taste and implementation, not the language itself.

However, the desire to grow Java into a true high-level language will, it seems to me, take the focus off of its being a bridge between high and low level languages. Others have disagreed, and quite eloquently... we shall see.

Re:Mistake

[SvendTofte]

Generics usually IMPROVE runtime performance, because you don't need to cast, and unbox/box stuff going into whatever. Hejlsberg did a demo at my school, showing between 50 and 70 percent decrease in execution times.

Re:Mistake

[horza]

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.

Yeah, because hardly any companies are driven by their bottom lines...

Which why you don't want your language to be controled by a company which in turn has a marketing-driven bottom-line.

Phillip.

Re:Mistake

[Derkec]

Wow, I was super unlcear in my complaint. My complaint was that making a collection type safe is mostly a waste of time. sorry about that.

Re:Mistake

[cakoose]

The CLR VM knows about generics so it can safely get rid of the casts. The Sun idiots chose not to modify the JVM bytecode to accomodate generics, so the casts need to be there. You don't see the casts because "javac" inserts them for you, but they're still in there, doing what they do best: kill performance.

While the 50%-70% improvement is definitely not typical, if you do some intense algorithms on collection classes, then you'll probably see that kind of speed up. Just don't expect that kind of speedup for a real-world application.

Re:Mistake

[SvendTofte]

of course. the demo was of a tight int/string loop. I'm not expecting Windows to run 70% faster, but in special cases, subrutines, it can give a good deal of speed.

And yes, it's dependent on the VM knowing what it's dealing with, as you say, the JVM doesn't, so it probably doesn't get as good (if any) boost.

Available application servers.

[MacDork]

So Java is playing syntax catchup with 1.5. (Not making a statement, just noting what the intro seems to imply.) Great, they both seem to be taking plays from the good ol' C playbook. What appservers are available for C# though? Anything not made by Microsoft?

Re:Available application servers.

[I confirm I'm not a]

What appservers are available for C# though? Anything not made by Microsoft?

Not trolling, just curious: what appservers are available for C#, period? I'd guess IIS now has some kind of .net binding? Any others?

Re:Available application servers.

[ClippyHater]

What appservers are available for C# though?

Wrong question. C#, VB.NET, x.NET, all compile to the same intermediate language. The correct question would have been "what appservers are available for .NET?"

With Mono on the .NET bandwagon, it's just a matter of time until you have both closed and open app servers.

Re:Available application servers.

[rewt66]

All right, let me repeat the question. "What appservers are available for..." I don't really care whether you complete the question with C# or with .NET. What's available now? What can I use today?

"It's just a matter of time" may be true, but if I need it for something now, "someday" doesn't cut it.

Heh

[KoolDude]

SexyFingers writes "Sun released Java 1.5...

The ultimate question is... how did you get those sexy fingers ? Java, C# or... Pr0n# ?

Re:Only Microsoft

[Anonymous Coward]

No. Checked exceptions were an interesting experiment that turned out to be a bad idea. I won't rehash the arguments here (for a reasonable example, search for Bruce Eckel's writings on the topic), but when the ivory tower of checked exceptions meets the real world of deadlines, something has to give.

I've no plans to use C#, but it's something they definitely did right.

Re:APIs

[SnapShot]

I use DOM within XML as well as the MessageDigest using the MD5 algorithm every day. So I'm letting you know...

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.

AVP

[pizza_milkshake]

It's just like Alien vs. Predator:

whoever wins, we lose.

Re:AVP

[ppz003]

We lose approximately $7 to $10 per person to be exact.

Re:AVP

[Coryoth]

It's just like Alien vs. Predator:

whoever wins, we lose.

Or Bush vs. Kerry for that matter.

Jedidiah.

Re:AVP

[dcam]

It's just like Alien vs. Predator:
whoever wins, we lose.

If you saw the movie you certainly did.

So this is what...

[Sanity]

forget the OpenSource crap argument

...passes for an "article" on Slashdot now? The argument that Open Source software is better because it doesn't rely on an existing vendor is now "crap" - and requires no more justification than that?

Combine this with the fact that nothing here is new news, and you really gotta as what exactly /. editors are for.

Re:So this is what...

[teromajusa]

See, you're just too in love with Python, Perl, and Ruby. I myself used to think that those were real and useful languages. Then I discovered that c# is maintained by Microsoft and I realized that they were actually crap.

Re:So this is what...

[Tumbleweed]

/. editors are for editing article submissions.

No, seriously!

You can stop laughing any time now.

slashdot changes stories??

[dAzED1]

The story originally was (I hit my back button, and cut/pasted here):
SexyFingers writes "Sun released Java 1.5. The non-API stuff that they've added made it finally "catch-up" with C# - like we were talking about before, since both language is built to support OOP from the ground-up, their constructs become almost identical as additional OOP "features" are supported overtime - so if you're doing C# and you're foundations in OOP is rock-solid, there really isn't any difference whether you're coding C# or Java."

"both language is built" being just one of the changes...now its "both languages are built..."

WTF? There are still grammatical errors in the "story," even with the changes. If there's nothing new to report, why can't we just have no new stories? Someone please make something like what /. used to be...

Re:Sounds a lot like religion

[jayminer]

I code C# for a living, so according to your definition, sold (or more appropriately rented) my soul to the devil. (This does not change the fact that I personally prefer free/open source technology. My PDA, my media players, my home operating system are all free/open source based.)

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:APIs

[Moe Yerca]

MD5 is native... java.security.MessageDigest.

A quick Google for "java MD5" gives a code example in the first hit, http://www.bombaydigital.com/arenared/2003/10/10/1

Think before you whine.

IIS vs J2EE Servers

[knitterb]

It's not so much the language that is a question of contest, but the platform they run on. I've done Java programming since 1.1.8, and have deployed on Tomcat, Resin and Weblogic.

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 .Net? What the fuck is up with IIS (oh yeah, it's crap)?? Where is any sort of replicated server side session management (no, long ass hidden fields are *not* sessions - and a M$SQLServer *only* solution doesn't count).

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 .Net's deployment platform (singular). Man I miss working with J2EE platforms and loathe IIS...even though it is my job to keep all this stuff running on IIS! :(

Re:IIS vs J2EE Servers

[SlashdotMeNow]

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.

Nothing groundbreaking? What about DataGrid1.DataBind() or built-in viewstate management? I love it to bits when I think back at how horrible stuff like that was in PHP.

What's really missing is the platform for release, and release management.

SourceSafe is free with VS and will be even better integrated in Whidbey.

What the fuck is up with IIS (oh yeah, it's crap)??

I don't know what your IIS issues are but on my win2003 servers we've not had a single problem.

Where is any sort of replicated server side session management (no, long ass hidden fields are *not* sessions - and a M$SQLServer *only* solution doesn't count).

Why does SQL Server not count? It's cheap and works well for server-side state/session management. You can also use the ASPNET State Server service, or if you are so inclined you can write your own with minimal effort (50 lines of code or so).
.net shits all over everything else for pure developer productivity.

Re:IIS vs J2EE Servers

[nuggetboy]

Nothing groundbreaking? What about DataGrid1.DataBind() or built-in viewstate management? I love it to bits when I think back at how horrible stuff like that was in PHP.

I see your point, but those are features of the .NET framework, not C# as a language. Also, aren't these things available in JSF?

I don't know what your IIS issues are but on my win2003 servers we've not had a single problem.

You've been lucky then. We just started to have issues with our ASP applications that *only* manifest themselves with 2003.

Re:IIS vs J2EE Servers

[eakerin]

SourceSafe is free with VS and will be even better integrated in Whidbey.

He wasn't talking about source code management, he was talking about deployment packages.

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.

Re:IIS vs J2EE Servers

[badriram]

You do realize in the Windows world with ASP.NET all you do is drop a set of files, and maybe the bin folder into the target directory. There is nothing else to it.

For ASP.NEt Session management does have a variety of options, in-proc, out of process in a state server, or in a SQL database (which includes the free MSDE).

Re:IIS vs J2EE Servers

[knitterb]

The out-of-process state server is a *single* machine/process that can't be replicated or clustered. Furthermore, in order to make it fast (in memory cach) you would need to do sticky sessions on your load balancer.

Re:IIS vs J2EE Servers

[CoolMoDee]

.net shits all over everything else for pure developer productivity.
I disagree. I am much more productive with Objective-C and Cocoa then with C# and .NET. While C#/.NET or Java are both *halfway* decent, they still seems like an ugly hack of an API to me.
As for Visual SourceSafe, I don't think MS even uses it. I heard they use cvs or something of that nature.

Re:IIS vs J2EE Servers

[Johnno74]

You're completely correct... which is why MS provides SQL server session state.

I've read that using the SQL server state service is 80% as fast as in-process state.

Thats not a lot of overhead...

Re:IIS vs J2EE Servers

[badriram]

I have not seen this being solved very well outside of sticky sessions in java app servers either, most of them also hit a point when performance degrades considerably when the cluster reaches a certain size. Also replicating sessions also causes a great performance degradation.

We use sticky sessions with Application Center 2000, and the solution has worked out very well.

Re:IIS vs J2EE Servers

[Bake]

So, instead of deploying a single file, ... or perhaps two files (one a basic configuration telling the application server where the hell the database machine is at). You actually prefer deploying a bunch of files, which can all be inconsistent (since they're most likely put in place by a human on the server, and humans have sometimes forgotten to include just-this-one-file when deploying), instead of minimising the inconsistency down to a couple of files?

I suppose you also keep a list of phonenumbers written down on several bits of paper in your pocket instead of having them in your phonebook in your mobile phone, or a mini-phonebook at worst?

I hope you do enjoy this work-method.
I, and many others however, wouldn't be cought dead working like this.

Important differences between Java and C#

[daveho]

While neither Java nor C# is truly free of being controlled by an Evil Corporation(tm), Java at least has multiple vendors, runs on a wide variety of platforms, and has an open standardization process.

Re:Important differences between Java and C#

[ferratus]

AFAIK, C# itself runs on multiple platforms (Windows, Linux (mono, dotgnu), etc.) and is also standard. The problem with .net is not the language itself, but rather the "standard library" that comes with the SDK. The whole Windows.Form framework is very much plateform specific.

On linux, you can at least use GTK# which is really nice. Still, Java has an advantage there since even the UI is platform independant.

Re:Important differences between Java and C#

[rabtech]

Funny, I always thought having the ECMA control and adopt a standard was "more open" than Sun's "we're open, as long as you don't propose something we don't like" process.

Re:Important differences between Java and C#

[julesh]

Correct me if I'm wrong, but I thought the ECMA standardisation only applied to the core C# language, not the .NET apis, whereas the Java community process is involved in both areas. Also, the Java community process is more open in the sense that anyone can become involved in it, I believe ECMA only accepts comments from accepted industry 'experts'.

Maybe I'm an oldtimer, but...

[Tony]

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.

Oh, how I pine for the days of vi vs. Emacs.

- Tony

Re:Maybe I'm an oldtimer, but...

[samberdoo]

But do you use Pine to read your /.?

Re:Maybe I'm an oldtimer, but...

[balster neb]

Oh, how I pine for the days of vi vs. Emacs.

Errr...no.. it was Emacs vs. vi you know.

Re:APIs

[ckuske]

MD5 is part of the java.security package:

byte[] theTextToDigestAsBytes = "The quick brown fox jumped over the lazy dog's back".getBytes( "8859_1");
MessageDigest md = MessageDigest.getInstance( "MD5" );
md.update( theTextToDigestAsBytes );
byte[] digest = md.digest();

An XML parser has been built into Java since 1.4.

See this.

With C#, stuck in windoze

[JPyObjC Dude]

so if you're doing C# and you're foundations in OOP is rock-solid, there really isn't any difference whether you're coding C# or Java.

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

[pesc]

You are right. One main feature that Sun designed for Java was WORA (Write Once Run Anywhere). M$ thought this sucked. They tried to destroy that feature and got sued over it. So the invented C# instead. C# isn't WORA, it is WORM (Write Once Run on Microsoft). With C#, you are locked in again. That's the whole point with C#.

Re:With C#, stuck in windoze

[fitten]

LoL... Write Once, Run Anywhere.... good one there... Java is Write Once, Debug Everywhere. Once you commit to one JVM, you are pretty much locked in because of the incompatibilities in other JVMs. A number of groups are using C# developed apps on both Windows and Linux without any issues at all (as long as the code uses GTK#).

There are C# development environments on other platforms... Linux for example (Mono) and one can even use Rotor on other platforms. And... at least C# is an open standard.

Re:With C#, stuck in windoze

[cmorriss]

LoL... Write Once, Run Anywhere.... good one there... Java is Write Once, Debug Everywhere. Once you commit to one JVM, you are pretty much locked in because of the incompatibilities in other JVMs.

You haven't been writing many cross platform applications in Java recently have you? I've been writing large, complex applications that must run on Windows, Linux, HPUX, AIX, OS/400, and Solaris for 6 years now. When I started, your statement was true. However, this has largely become a non-issue. Throughout testing we rarely come across a bug that is specific to a single platform or JVM as long as you use a robust JVM like Sun's or IBM's.

While you still need to test on all platforms just to be sure, 98% of the bugs found are in the Java code, not the JVM.

Re:With C#, stuck in windoze

[jrumney]

This is complete misinformed bullshit. I've seen large Java applications that run perfectly in every JVM since 1.1.8. There are a few version specific bugs in Java, but they are easy for any competent programmer to work around.

Re:With C#, stuck in windoze

[Uber Banker]

FOAD

Re:APIs

[AKAImBatman]

Let me know when stuff like an XML Parser and MD5 are native in Java.

They ARE.

XML package
MD5 and SHA support

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:Sounds a lot like religion

[Glock27]

Java is not any more closer than C# to open source technologies. Sun doesn't like open source, just as Microsoft.

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:APIs

[iabervon]

An XML Parser and stuff like MD5.

"One Person"... "One C# Developer"

[Black-Man]

opinion. broken link... poor grammar... this guy is a joke. He pulls out 7 new features!! What about built-in queue support?

Only thing I agree with is generics has been long overdue.

Re:"One Person"... "One C# Developer"

[gauchopuro]

Broken link? It seems like most of the links posted on Slashdot are broken. (And if not, just wait a while.)

Re:APIs

[GileadGreene]

Well, let's see, javax.xml.parsers and the related packages that are part of the Java API for XML have been standard since Java 1.4. Meanwhile, javax.crypto (which includes a Message Authentication Code class that supports MD5 hashing) has also been standard since Java 1.4. Java 1.4 is the major release that preceded the one the current article is talking about, and has been out since around 2002.

So, were you trolling, or did you just not bother to keep up with Java?

Java C# porting - Lucene as example

[otisg]

It is this similarity and 'compatibility' of Java & C# that is now making it easy to port various applications between the two languages. For instance, the very popular Lucene (Information Retrieval library from Jakarta (i.e. Java)) has a very solid .Net port written in C# called dotLucene. The Lucene -> dotLuene port is fairly automated, it appears, which allows developers of the .Net/C# port to keep up with the original software written in Java.

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
dotLucene

Re:I hope so.

[jallen02]

Hmmn,

Doesn't mean a large project has to USE all of these features. There are plenty of different ways to accomplish a particular task in ANY programming language. Just because a way exists doesn't mean a project can't standardize on a particular method. Its pretty easy problemto solve and it goes something like this: "Please see Chapter 3, Section 8 of the project coding style manual for information on using import aliasing. Thanks".

The same rules apply were you to use Perl on a large scale project. It takes a degree of discipline to ensure everything gets done the right way. Regardless of the language it is ultimately a people and management problem :)

Jeremy

Re:APIs

[AKAImBatman]

Now, now. Keep it civil. Taking the same route of insults as the original poster is only going to exasperate the situation. Keeping things calm gives him the opportunity to say, "Hey, that's pretty cool! Maybe I'll go try it out."

His bias does seem obvious, but it never hurts to try. :-)

hear here

[dAzED1]

The world was a kinder, more simple place. And "news" didn't get edited after being published.

Meanwhile, C++ goes nowhere

[Animats]

C++ is in deep trouble. The C++ committee is focused on additional features for templates to the exclusion of almost everything else. Strostrup has said that there's nothing really wrong with C++, and the committee buys that. So none of the huge safety problems get fixed. And buffer overflows continue to plague computing.

This problem is the primary reason that C# exists. If the C++ committee had fixed their language, we wouldn't need C#.

It's a big issue for the open source community. The publicly standardized languages have major problems, and the newer languages are controlled by single large vendors.

Re:Meanwhile, C++ goes nowhere

[sriram_2001]

This isnt exactly true. On the Microsoft front, there are a ton of features being added to the compiler in VS 2005 - including checking for buffer overruns,etc. Also included are new operators to help you work with the .NET framework

Re:Meanwhile, C++ goes nowhere

[scotch]

What do you propose changing in C++, exactly? A general purpose smart pointer is going to be added, BTW.

C# doesn't really compete directly with C++, it competes with Java.

Re:Meanwhile, C++ goes nowhere

[StrawberryFrog]

here's the thing: C# and C++ is not a boxing match. C# and Java, maybe foes, but C++ and C#/Java are compilimentary technologoes, horses for courses if you will.

Re:Meanwhile, C++ goes nowhere

[cpghost]

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

[joib]

Luckily Fortran, with the advent of the new Fortran 2003 standard, is stronger than ever. ;-)

Re:Meanwhile, C++ goes nowhere

[yamla]

I'm curious, why do we still get buffer overflows in C++ code? I mean, the C++ string type and the vector container have been around for the better part of a decade now, and a standard part of the language for, what, six years? Seven years? And you can grab smart pointers from boost.

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 make use of C-style strings, unchecked arrays, etc., so perhaps we can blame C++ because it allows you to shoot yourself in the foot, you just have to be very explicit these days. Or perhaps the problem actually lies in the hideously outdated libraries that people are using, libraries such as the ones Microsoft gives you (I'm not talking .Net here, haven't looked at that) which still inexcusably use C-style strings and generally unsafe memory management. Not that Microsoft is solely to blame, of course.

Re:Meanwhile, C++ goes nowhere

[ultrabot]

C++ is a great language, but it's choosy about its friends.

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 for C++, which is used for embedded development etc.

For fast prototyping, I'd stick to Python, but when performance really matters, C++ is still king!

Make that "when performance really matters, and C++ can significantly improve the performance". C++ won't make your network interface or hard drive faster, for example.

Often the smart thing to do is to first write everything in Python, and rewrite speed-critical parts in C/C++.

Re:Meanwhile, C++ goes nowhere

[spirality]

What is a good replacement for sprintf? strstream? My use of sprintf is the only place my code would (I believe, I suppose one never really knows) be susceptible to a buffer overflow.

Re:Meanwhile, C++ goes nowhere

[Gr8Apes]

The same can be said for COBOL. I bet somewhere in the world there is a guy that likes COBOL.

Hey - I work with that guy!!!! (and girl!)

Re:Meanwhile, C++ goes nowhere

[mypalmike]

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).

I agree. Recently, I had a job that introduced me to the ACE (Adaptive Communication Environment) toolkit, which has portable classes for sockets, threads and thread pools, message queues, processes, and higher-level communications contructs. It's an excellent library that cut development time and resulted in high-quality code. The main drawback was that it has its own classes for containers, streams, strings, etc. It would be great if the C++ standard libraries brought in at least some of the core functionality of ACE in a way that made it seamlessly interoperable with the existing library classes.

-_-_-

Re:Meanwhile, C++ goes nowhere

[Anonymous Coward]

C++ is a great language, but it's choosy about its friends.

I love you.

Re:Meanwhile, C++ goes nowhere

[deadlinegrunt]

Wow. I am amazed at your opinion and wish to understand it but I have to admit I reserved to just think that you do not know what you are talking about.

[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.

Re:Meanwhile, C++ goes nowhere

[ultrabot]

[on ACE]

It's an excellent library that cut development time and resulted in high-quality code. The main drawback was that it has its own classes for containers, streams, strings, etc. It would be great if the C++ standard libraries brought in at least some of the core functionality of ACE in a way that made it seamlessly interoperable with the existing library classes.

I think you'll agree that it would be reasonable to change ACE to accommodate standard C++ and not the other way around.

Re:Meanwhile, C++ goes nowhere

[tyrantnine]

Sockets, as an operating system specific issue, don't really have a place in the language standard. Especially for C++, which is used for embedded development etc.

I guess you might say the same thing about something like Swing? I guess it's a difficult call - though I certainly hope the impending C++0x standard isn't conservative about increasing the size of the STL. Personally my biggest hope is for a decent threading implementation.

As for "being used for embedded development". I sit here with a dual boot Linux/W2K system loaded with zillions of applications large and small. Of the stuff I haven't written myself, I run exactly 0 C# applications and 1 Java application - Eclipse. Thats it - virtually everything else running on my computer from the bottom up is either C or C++ (save python, which forms the base of package mgmt in Gentoo). So I am always confused when people start talking as if C++ is some "low level" or even legacy language that only EE's touch. Marketroids and zealots have really quite a sales job on exaggerating the death/"inferiority"/utility of C++. That and college-age folk who've learned Java as their primarly language and are in the process of trying to assure themselves, through everyone else, that Java's the best thing since the wheel. Anyway eople not only still use it C++, but still *choose* it, for far more than embedded development.

Re:Meanwhile, C++ goes nowhere

[mitch0]

I haven't seen it mentioned in this discussion (not so surprising, 'cos it's about java and c# after all), but anyway: take a look at boost. This is the stuff they hope will be in the next standards. Very nice libs (mostly template magic)

cheers,
mitch

Re:Meanwhile, C++ goes nowhere

[Animats]

At least use "snprintf". (Or, in Microsoft's warped world, "_snprintf"). That prevents buffer overflows.

All the buffer overflow prone C library functions (sprintf, strcat, ...) should be deprecated and moved to something like "unsafe_strings.h". That would make potential buffer overflow points stand out.

Meanwhile, try adding something like this to any major open source project:

#define sprintf UNSAFE_SPRINTF_CANNOT_BE_USED
#define strcat UNSAFE_STRCAT_CANNOT_BE_USED

Compiles will fail until the code is fixed.

Re:If sun dies...

[Anonymous Writer]

If sun dies... IBM will then pick it up... it's so clear.

Or perhaps Kodak will.

And multiple inheritance is due when...?

[Anonymous Coward]

Sorry, guys but as long as you don't have that, you're not really OO.

Re:And multiple inheritance is due when...?

[peterpi]

Java has had multiple inheritance since the start (interfaces and the 'implements' keyword). You just can't multiply inherit instance variables.

Re:And multiple inheritance is due when...?

[Anonymous Coward]

Bzzzzzzt.... Wrong answer!

Interfaces are _not_ multiple inheritance. They're virtual classes. You can emulate multiple inheritance with interfaces and a stub for every inherited method, but this is _extremly_ tedious.

Re:And multiple inheritance is due when...?

[tim_bissell]

Never, please...

Neither Smalltalk nor Self have multiple inheritance and Smalltalk practically defined OO.

Worst?

[McLoud]

In deep, in deep, in the very deep... if you dig a bit... /. maybe not look so bad as a news source.

Limitations of Generics in Java.

[miguel]

There are some important limitations of generics in
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.

Re:Limitations of Generics in Java.

[nuggetboy]

I used to say that about properties, but am really finding them window dressing. Just provide accessors and/or mutators.

Re:Limitations of Generics in Java.

[pjt33]

Java has events and iterators - or does C# mean something different by them to Java?

Re:Limitations of Generics in Java.

[Tim C]

Java has had anonymous methods for as long as I've been using the language (approx 5.5 years), while C# is (as I understand it) only gaining them in 2.0.

(Not to denigrate C# at all, it's my other language of choice)

Re:Limitations of Generics in Java.

[mrright]

Java has anonymous *classes* since 1.1. But that is not the same as anonymous methods. And C# 2.0 has real closures and none of the limitations of java inner classes. No need for the "final array of one element" hack, if you know what I mean.

Re:Limitations of Generics in Java.

[fforw]

And C# 2.0 has real closures and none of the limitations of java inner classes. No need for the "final array of one element" hack, if you know what I mean.

no.. what is this hack?

Re:Limitations of Generics in Java.

[mrright]

An anonymous inner class in java can only refer to final variables from the local scope. So you define a final array with one element to copy something out of the inner class context.

Here is a good example:
http://c2.com/cgi/wiki?ClosuresThatWorkAroundFinal Limitation

Re:Limitations of Generics in Java.

[fforw]

Closures in java are generally a hack in java and this example IMHO crosses the border of ugliness. so I would more likely just use an inner class instead of an anonymous.

Re:Limitations of Generics in Java.

[Tim C]

My mistake; you are indeed correct. I seldom have cause to use an anonymous class, and in those rare occasions when I have done (generally creating an anonymous Comparator), I have of course been doing it to implement a single method.

Re:Only Microsoft

[Timesprout]

Nice troll.

C# supports a full exception handling model, it just does not force you to declare and handle checked exceptions, an issue of strong contention within the Java community. Its left to the developers discretion when to check and handle errors. The orinal exception will still be available no information is lost.

For my own opinion I prefer unchecked exceptions as the code is far cleaner. Enforcing checked exceptions can be extremely clunky to handle and its highly debatable whether exceptions should be part of an interface. I also noticed a recent trend among java developers to use a single catch all exception in many cases to simplify coding.

Java poor design choices

[mmusson]

My biggest beef with java right now (well Sun, really) is that they are make design decisions in the name of backward compatibility that are leading to poor design choices. Backwards compatibility is an important consideration, but it should not be used as an excuse to make poor design decisions. I use a variety of java programs day to day that only work with certain VM versions due to bugs, features, etc. It seems silly to give this one aspect such heavy consideration as if the current java versions are perfectly backward compatible today when they clearly are not.

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.

Re:Java poor design choices

[Vultan]

Agreed. Even more frustrating is that all the collections classes have been rebuilt to be based on generics. I teach at a liberal arts college, and have found Java 1.5 to be a supreme headache. It's much harder to teach than Java 1.4. I'm finding that I have to either teach intro CS students the complexities of Java generics, or I need to teach them to ignore warning messages. It's painful.

Re:I hope so.

[Anonymous Coward]

Coding standards are a waste of time to have to write and read and you know there will be plenty of people who won't follow them, or will at least gripe about their superiors having sticks up their asses for making those decisions. A language should be succinct enough that there should be no need to create a coding standard that has to specify which features to avoid.

Re:APIs

[AKAImBatman]

Quick correction:

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 to back up my statement that MD5 support has been around that long.

Netcraft confirms.

[Anonymous Coward]

It is official.

Netcraft confirms: C++ is dying

One more crippling bombshell hit the already beleaguered C++ distribution community when IDC confirmed that C++ market share has dropped yet again, now down to less than a fraction of 1 percent of all programming language distribution versions. Coming on the heels of a recent Netcraft survey which plainly states that C++ has lost more market share, this news serves to reinforce what we've known all along. C++ is collapsing in complete disarray, as fittingly exemplified by falling dead last in a recent programming language distribution study.

You don't need to be a Kreskin to predict C++'s future. The hand writing is on the wall: C++ faces a bleak future. In fact there won't be any future at all for C++ because C++ is dying. Things are looking very bad for C++. As many of us are already aware, C++ continues to lose market share. Red ink flows like a river of blood.

Bloodshed C++ is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: C++ is dying.

Let's keep to the facts and look at the numbers.

Bloodshed C++ project leader Theo states that there are 7000 users of Bloodshed C++. How many users of Borland C++ are there? Let's see. The number of Bloodshed C++ versus Borland C++ posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 Borland C++ users. Bloodshed C++ posts on Usenet are about half of the volume of Borland C++ posts. Therefore there are about 700 users of Borland C++. A recent article put Bloodshed C++ distribution at about 80 percent of the market. Therefore there are (7000+1400+700)*4 = 36400 Bloodshed C++ users. This is consistent with the number of C++ Usenet posts.

Due to the troubles of half-baked C++ apps, abysmal sales and so on, many development companies is going out of business and will probably be taken over by another company who will sell another troubled product. Now C++ is also dead, its corpse turned over to yet another charnel house.

All major surveys show that C++ has steadily declined in market share. C++ is very sick and its long term survival prospects are very dim. If C++ is to survive at all it will be among dilettante dabblers. C++ continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, C++ is dead.

Fact: C++ is dying

API talk...

[Chuck Bucket]

Funny, we were talking about the 1.5 APIs last week here at work, while talking about migrating our apps over from 1.4.x. This site Official Java Programming Documentation gives you a ton to think about. I rem when we were on 1.2...

CB*($#@

Enterprise development

[drgroove]

Last time I checked, few industries were doing enterprise development with J2SE, regardless of the version. J2EE is the preferred platform for enterprise application development (hence the 'EE', or 'Enterprise Edition', after the 'J2' bit). J2SE 1.5 is a great release, but it means little currently for J2EE developers.

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.

Re:Enterprise development

[Fulcrum of Evil]

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.

Why can't you use j2se1.5 with j2ee 1.3?

Re:Enterprise development

[ievans]

You probably can, but you're missing the point. Only J2EE 1.5 will use the J2SE 5/1.5, language features.

For example, in J2EE 1.5 you'll use annotations in your EJB implementation class to declare it a remote stateless session bean and the container will figure out the required interface definitions on its own. You can't do this in J2EE 1.3 or 1.4, regardless of the J2SE version used.

Re:Only Microsoft

[clamatius]

I've read the arguments on the topic, but I don't agree.

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 would most likely have been a checked exception in a Java implementation). Now, often if you were smart you'll be lucky and the exception falling through to a general handler won't break anything too badly, but other times something unfortunate will happen.

In my book, when Microsoft's fast-to-develop-cut-all-the-corners methodology meets the real world of SLAs where software actually has to work, something has to give. And yes, you can say "just use Java/Python/Cobol/whatever instead" but the point here is debating whether using checked exceptions is a good idea or not.

I'll be honest - I like a lot of things about C#. It's a good language and their IDE is also good. But deciding that checked exceptions were bad was very unfortunate.

Java is not only a language

[hurricane_sh]

The comparison only lists some baic language features, it makes no any sense! Java is NOT only a lanuage, it's a platform, it's a system, it provides all kinds of solutions for your desktop, network, micro device and enterprise web service.

Re:Java is not only a language

[winfx]

Java the platform doesnot have generics, doesnot enforce checked exceptions, has not autoboxing etc.
They are all enabled by the java "compiler" and not by the Java "the platform" or "the system"

April 1st?

[cthrall]

> should be the support it has behind it, in terms
> 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 .NET.

> 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 ---

You misspelled "FUD."

Re:Only Microsoft

[teromajusa]

"For my own opinion I prefer unchecked exceptions as the code is far cleaner. "

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.

Java checked exceptions suck, but how to fix them

[The Pim]

I've written a lot of Java and agree that checked exceptions lose. (Not stating the reasons because it's been discussed to death and I'm lazy.) What I don't understand is why C# didn't adopt the following simple design: Make the cheked-ness of exceptions not a property of the exception class, but of the function throwing it. Then, the FileNotFound exception could be checked in openFile (where it is an expected case) and unchecked in readDataIJustWrote (where it is unexpected). Then, readDataIJustWrote could call openFile without either 1) declaring that it throws FileNotFound (breach of abstraction) or 2) wrapping FileNotFound in an unchecked exception (tedious and obfuscatory). IMO, this solves the biggest problems with mandatory exception checking.

In implementation, there should be some syntax to say, I know that this function I called throws a checked exception, but I want it to be unchecked for me. This could be part of the method declaration, or (even better) part of the expression that trips the exception.

Re:Only Microsoft

[Kingpin]

I prefer unchecked exceptions as the code is far cleaner - Clean code vs. predictive application behaviour.. let me think...

its highly debatable whether exceptions should be part of an interface - Why? If it's part of the behaviour that can be expected from method, why not? Example: public void sendMail(Mail mail) throws IOException;

I also noticed a recent trend among java developers to use a single catch all exception in many cases to simplify coding - A recent trend you say? Noticed? Where? Bad programmers exist in any community, but I would be interested if you can find a succesful open source Java project where this stuff is considered acceptable.

Re:Only Microsoft

[winfx]

Sorry but the only reason i rejected Java some years ago was checked exceptions.
IMHO that was a major design fault of the Java designers to abuse the structured exception mechanism to provide semi-cooked validation of contracts.
That alone turned every simple operation in Java to a try/catch block

Ravioli Code

[Ian Bicking]

I think the problem you are seeing is Ravioli Code; a (perhaps excessive) reaction to spaghetti code. Also Java (and probably C#) programmers seem to take Patterns too seriously as well, patterns should be descriptive, not prescriptive.

Re:Ravioli Code

[metamatic]

Similarly, object orientation should be used as a tool, not enforced as a religion. If an object-oriented API to some functionality is the cleanest and most useful, implement that way; otherwise, don't. If the best way to build something is using functional programming, do that; don't try and force the code into an object-oriented paradigm.

Re:Ravioli Code

[angel'o'sphere]

If the best way to build something is using functional programming,

Well, the rest of your post triggers me to clap my palm at my fore head and murmore something unpolite ... but that sentence above makes me wonder:
a) do you know what functional programming is? or do you mix it up with so called "imperative programming"?
b) if you know what it is, would you kindly explain the difference in respect to OO programming?

IMHO in a language liek C++ the difference blures .... in Java its harder to do "functional" programming as it is syntacticaly uglyer.

angel'o'sphere

Re:Ravioli Code

[metamatic]

No, I didn't mean imperative programming, though that's also sometimes the right tool for the job.

Sometimes an algorithm is best expressed using curried functions, functions-as-arguments, recursion, and other functional techniques, and Java iterators are pretty clumsy when you're used to Lisp.

I don't know whether C# supports functional programming or not. I do know that whenever I have to use a language that doesn't treat functions and objects as first class values, sooner or later I end up cursing it.

Re:Ravioli Code

[Matje]

patterns should be descriptive, not prescriptive.

Why would you want them to be descriptive ? who's going to be interested in that description? Another programmer perhaps?
Why would that other programmer be interested in patterns as a descriptive device?

Exactly, because they make the code easier to understand.

So why should you use patterns as a prescriptive device? well, simply because they will make your code easier to understand for another programmer.

In the end, their value as a descriptive device is exactly the reason why patterns should be prescriptive.

That doesn't exclude the need for fingerspitzengefuhl (? my german is dated) to know when and when not to use a pattern.

Re:Ravioli Code

[angel'o'sphere]

Nope, none of the modern OO or hybrid languages support true functional programming. E.G. you can not define and return a function on the fly. However C# has some variants of pointers to methods (delegates) and in Java you can use reflection to create method objects or nested classes (inner classes) as kind of closures.
But both ways are very verbose in typing.
In C++ you usually overwrite operator () for a class and now the objects can be used like functions. But again you can not define closures or lambdas on the fly.
Look at the groovy language (codehouse.org), probably you like it or Ruby (I hate Ruby ...,because they stopped at the point where it gets interesting and it has some ugly design flaws).
angel'o'sphere

Re:Ravioli Code

[metamatic]

I'm waiting for Ruby to get Unicode compliant so I can stop using Perl...

Re:Ravioli Code

[timts]

I totally agree with you, but sadly, those kids who went into college or community school who only has Java knowledge have been brainwashed with those java OOP books, which claim that people need to FORGOT WHAT THEY KNOW ABOUT C and only write stuff in OO... that's just sad, I see tons of useless refactoring of code and over engineered architure with NOT FUNCTIONG result.

BS C# is an open source standard

[Billly Gates]

ITs IEE and ansi certified and used for gnome development via mono. Java is more restrictive in terms of licensing and control.

Re:APIs

[mcbevin]

No, he probably means like C#'s XML serialization / de-serialization, which is a hell of a lot nicer for most situations than either JAXP/JAXB (I've used all these technologies and I found JAXB so awful (and JAXP is just too much work for most situations) that I wrote my own utility for Java which works very similarly to C#'s XML serialization).

I won't even get into the speed of Java's XML parsers.

There are of course better solutions than JAXP/JAXB for Java (some similar to C#'s), they're just not standard and not quite as nice (in particular, because Java didn't have anything comparable to C#'s attributes until 1.5, and the attributes are quite useful in controlling XML serialization).

Biggest problem here:

[rts008]

"...in my NSHO..." Sheesh, give us a break!

Re:Obligatory

[kundor]

Why....why would someone who thinks OO is a bad methodology work in OO?!?

That's like saying "When I see a PETA member personally slaughter meat animals, I'll pay attention to his critique."

still very different

[jeif1k]

Don't be fooled by syntactic similarities; C# and Java are still very different languages:

• C# has value classes
  
• C# has operator overloading
  
• C# has multidimensional arrays
  
• C# has unsafe modules; in unsafe modules, you can call C functions directly (no JNI) and manipulate C data structures and pointers
  
• C# does not force you to declare exceptions
  
• C#'s generics are efficient for unboxed types while Java boxes in many cases
  
• C#'s generics are type-safe across compilation boundaries (I believe Java's are not)
  

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.

Re:still very different

[rabtech]

You are correct re:generics. The java complier just wraps all the type casts behind the scenes - the JVM doesn't actually understand generics and the bytecode can't represent them either. Generics gain you nothing except some syntax sugar. This is a direct result of Sun's refusal to modify the JVM to support generics.

C#, VB.NET, and all dotnet languages that support generics behave differently in that the MSIL can represent and consume generic types and the runtime also understands them.

For value types, a unique native version of the class is generated per each value type used. (by the JIT). Reference types share one implementation. Constraints also allow for compile-time safety to be enforced wrt generics.

Re:still very different

[pjt33]

If by "compilation boundaries" you mean code compiled at different times, then you're wrong. The VM doesn't use information about generic types, but it is stored in the class files and used by the compiler when you import those classes.

Re:still very different

[jeif1k]

The VM doesn't use information about generic types, but it is stored in the class files and used by the compiler when you import those classes.

That's what I remembered and that isn't statically type safe, since you can compile against one version of a library and load another version of it (that's a pretty common mistake to make). If you do that with non-generic code, you are guaranteed that you will get a type error at load time at the latest. But with generic code, if the VM doesn't check the generic types, you won't get a load time type error but you may instead get a runtime type error at an arbitrary point later in time.

I believe Sun's attempt at backwards compatibility with existing Java class libraries may introduce additional possibilties for type errors.

Re:still very different

[Elwood P Dowd]

C#'s event model is also different. Dunno if it's better, but I like C# event handlers and I hear it's different for Java.

Can anybody with more experience comment?

Re:still very different

[DrXym]

Calling unsafe modules is straightforward to do in Java. Okay, so JNI isn't as immediate but it's fairly trivial boilerplate - define an interface with native methods, generate a header, implement the methods the header emits and compile. In other words if you have to do it, it's there.

Anyway, it is arguable that making it easy to call unmanaged code is an extremely bad thing to do. Call me a cynic, but I reckon MS is delighted to see people use unmanaged DLLs, COM interop and other unportable stuff since it locks them into MS Windows. What was the point of coding with .NET again?

Other points. Java as multidimensional arrays - I used one today in fact. Also, declaring exceptions is a good thing. It might be a minor pain to declare that your method throws an exception, but it sure beats calling something and having no idea whatsoever if it throws an exception.

Re:still very different

[Bob9113]

C# does not force you to declare exceptions

Correction: C# does not give you the option of using checked exceptions. Java has both checked and unchecked.

Checked exceptions, when used properly, are a very good thing. The point of a checked exception is: "Pardon me developer, but did you ensure that precondition X is satisfied before calling this method?" If there is a precondition that is not apparent from the API itself, the checked exception is a good compile-time method for getting the developer's attention.

That said, I have seen (and even committed) overuse or misuse of checked exceptions. Thus I can understand Microsoft's assumption that programmers aren't smart enough to use them properly.

Re:still very different

[jeif1k]

Calling unsafe modules is straightforward to do in Java. Okay, so JNI isn't as immediate but it's fairly trivial boilerplate - define an interface with native methods, generate a header, implement the methods the header emits and compile. In other words if you have to do it, it's there.

JNI isn't even close:

• with JNI you need to compile and distribute separate version of your unsafe code for every target CPU, with C#, it's just like any other C# code (the JIT compiles it into native code as needed, on each target platform)
  
• doing any kind of native operation has at least a C function call overhead, and more, while unsafe C# compiles unsafe operations inline; so, an unsafe array access in C# is actually faster than a safe array access, while with JNI it is much slower
  
• everything inside a C/C++ JNI module is unsafe (it's C/C++, after all), while with unsafe C# modules, only the specific operations you need to carry out need to be unsafe
  

Anyway, it is arguable that making it easy to call unmanaged code is an extremely bad thing to do. Call me a cynic

No, I just call you someone who has overdosed on Sun marketing.

but I reckon MS is delighted to see people use unmanaged DLLs, COM interop and other unportable stuff since it locks them into MS Windows.

So? Windows programmers apparently don't care; they are just delighted to be off of C++. And as a C#-using Linux programmer, I don't mind being locked into Linux. In fact, as someone who supports and uses open source software, I don't like using Java because Sun is trying to lock me into Java.

And, yes, C# let's me call unmanaged Xlib, unmanaged Numerical Recipes, unmanaged Tcl/Tk, and a lot of other unmanaged code, and I am not ashamed that I'm doing it--it's a good thing.

What was the point of coding with .NET again?

We are talking about C# here, not .NET. And the point of C# is to give you a powerful language that's easier to use than C++, something C# accomplishes well.

Other points. Java as multidimensional arrays - I used one today in fact.

Not in standard Java. Ragged arrays and the class-based Array definitions are not the same as having true multidimensional arrays in the language.

Also, declaring exceptions is a good thing. It might be a minor pain to declare that your method throws an exception, but it sure beats calling something and having no idea whatsoever if it throws an exception.

In Java, you still don't have any idea if any code you call throws an exception. That is, just because code doesn't declare an exception doesn't mean it doesn't throw one. In fact, in Java, code you call may even throw undeclared exceptions that the language requires you to declare because the VM doesn't check exception declarations. So, you have to write Java code as if any code can throw any exception anyway.

Exception declarations in Java just don't work. Maybe someone with more brains than the Java language designers can make them work, but after many failed attempts, it doesn't seem likely anymore

Re:still very different

[jeif1k]

Correction: C# does not give you the option of using checked exceptions. Java has both checked and unchecked.

Yes, and it's the existence of checked exceptions, any checked exceptions, in Java that is a problem.

Checked exceptions, when used properly, are a very good thing. The point of a checked exception is: "Pardon me developer, but did you ensure that precondition X is satisfied before calling this method?"

Checked exceptions are a way to force a programmer to deal directly inside the caller with error conditions that might arise inside a method, nothing more and nothing less.

If there is a precondition that is not apparent from the API itself, the checked exception is a good compile-time method for getting the developer's attention.

That's what we have types and return values for. Exceptions are there for the opposite purpose: to avoid distracting the programmer at compile-time with irrelevant and useless detail related to error handling.

Re:Sounds a lot like religion

[AvitarX]

If I am not mistaken MS helped Mono out on their C# implementation.

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:Only Microsoft

[Gr8Apes]

I generally prefer unchecked exceptions. Mainly because the entire process of declaring a thrown exception through mutliple layers is an asinine waste of my time.

Plenty of differences

[flakac]

Sorry, but there are still some major differences in the two. I've looked at the new features in Java 1.5 and agree that yes, they are definitely a plus.(Note: I code nowadays almost exclusively in Java):

• No unsigned integer type in Java -- if you need an unsigned long, you're SOL. So it's pretty difficult to code certain numerical algorithms (compression and encryption, anyone?)
  
• Java the language is inextricably tied to the JVM - C# is just another option for developing for .NET.
  

For enterprise-grade work I still prefer J2EE over .NET, but that really more depends on what client I'm working for at the time. At the end of the day, both get the job done.

Re:Plenty of differences

[Deadbolt]

Behold BigInteger and its evil twin, BigDecimal. They laugh at silly-big numbers.

Re:Plenty of differences

[slyckshoes]

"Java the language is inextricably tied to the JVM - C# is just another option for developing for .NET."

Personally, I'd rather be tied to a JVM than an OS. There are JVMs for AIX, Linux, Windows, Mac, HP-UX, and others. Last I checked Windows was only available for IA32/64. Sure there's mono, but that's not yet a realistic option for enterprise development.

Re:Plenty of differences

[fforw]

• No unsigned integer type in Java -- if you need an unsigned long, you're SOL. So it's pretty difficult to code certain numerical algorithms (compression and encryption, anyone?)
• Java the language is inextricably tied to the JVM - C# is just another option for developing for .NET.

a) well if you have to take java.lang.BigInteger after 63 or 64 bits is of no real importance to me.

b) there are many other languages which run in the java VM (e.g. Jython, Groovy ) Some even run C# in a java vm .

Re:Plenty of differences

[pjt33]

No unsigned integer type in Java -- if you need an unsigned long, you're SOL. So it's pretty difficult to code certain numerical algorithms (compression and encryption, anyone?)

Care to explain? I can see three differences between signed and unsigned types:

1. The way they're printed. Irrevelant to coding compression / encryption algorithms.
2. The behaviour of the >> operator. Simple: use >> for signed ints and >>> for unsigned.
3. Widening operations. I agree that here you have to take care, but requiring care isn't the same as being difficult.

Re:Plenty of differences

[pjt33]

Extracting bytes from an int and composing bytes into an int are both operations which can be tidied behind a library call, so you only have to get it right once. Pointers are extremely pervasive in C, and claimed to be responsible for 90% of bugs.

Re:Java 1.5 vs c# 2.0? Full of shit

[Anonymous Coward]

You state that .NET development implies having to purchase VS.NET which makes .NET inferior to Java where you can download the SDK for free and a third-party IDE for free. However you completely ignore that the .NET SDK is also freely downloadable and that there are free third-party IDEs, such as SharpDevelop. As such both stand on equal footing despite your FUD attempt.

As for docs, you find it easier to use JavaDoc because that is what you learned. Those who learned MSDN find that much easier. It has little/nothing to do with the completeness or organization of either documentation.

Re:Obligatory

[William Tanksley]

Given his quote, wouldn't that be rather like waiting for a good roman-number computation from Einstein? I mean, given that Pike has proven his skill and has stated that he doesn't like OO (in so many words), you're just faking it if you claim to be waiting for an OO design.

Either respect what he's done, or don't.

Personally, I have a limited agreement, and I suspect he meant it in the same sense that I agree. I believe that like roman numerals, OOD has a limited utility, but when used for purposes outside of that, other things work better. I will say that I also belive that unlike roman numerals, OO doesn't seem to have any _huge_ weaknesses.

-Billy

Re:APIs

[EmperorKagato]

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

Wow. That sounds very familiar. And to think people wonder why there is a large fanbase for linux.

Re:If sun dies...

[cpghost]

try {
// blah blah blah...
}
catch ( sun.dies.Exception e ) {
System.out.println("Sorry, we don't exist anymore!");
System.out.println(e);
System.exit(1);
}

you're confused

[jeif1k]

Neither are open source.

Languages can't be "open source", only their implementations can be. Both Java and C# nominally have open source implementations. However, the open source Java implementations may be legally encumbered because Sun owns a lot of intellectual property in Java. The open source C# language implementations conform to an open standard (ECMA/ISO C#), and they seem to be completely unencumbered. The .NET platform may be encumbered by a patent, but you don't have to use .NET in order to use C#--there are, in fact, better toolkits and libraries available for C# already.

Despite being marketed as portable, but have portability issues. Java is not backward compatible with older versions. C# has problems with porting some of the graphics stuff to Linux.

You're confusing language and libraries. .NET is not fully supported on Linux and probably never will be. But the C# language is fully supported on Linux, and there are multiple sets of libraries available for it, several of them even cross-platform (Gtk#, wxWindows#, etc.). In fact, C# does not aspire to guarantee the same degree of cross-platform support, and many people view that as an advantage.

We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.

We need a replacement for C++ because people just don't seem to be able to code safe, secure, reliable applications in it. Java isn't a feasible replacement for C++ because it completely insulates the programmer from the underlying platform. But C# is a plausible successor: it gives programmers access to the underlying platform when they ask for it, but otherwise protects them from accidents.

IT...

[johnhennessy]

Hmmm, In a way I'm happy this was placed under "IT" instead of "Developers".

Re:Only Microsoft

[teromajusa]

It may seem like a waste of time to you, but to the guy who's going to be using your API or modifying your code it will be a godsend. In any case, you might want to try using a good ide like Intellij. It'll will wrap a statement in an exception handler or add a throws to the method with a single keystroke.

Can you please clarify..

[Anthony Liguori]

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 --- I'm having trouble parsing this. Here's what I *think* you're trying to say. If I'm wrong please correct me.

The three factors deciding factors in whether a language should be used in an Enterprise environment are the IDE, toolset, and richness of API. The vendor that champions the language also plays a key role.

Now, as for IDE/toolset/API, I think Java and C# are pretty evenly matched. You can say one's better than the other but they're more or less close enough (especially when considering you're other options like C or C++). When speaking about the vendor, please remember, that IBM invests just as much (if not more) into Java as Sun. IBM isn't going anywhere soon. Eclipse, in fact, was donated by IBM in the first place. I think another argument you could make in terms of Enterprise adoption is availability of skilled workers. Java has a clear advantage here over C#. Very few college students are learning C# these days and an increasing number of Universities are moving away from C/C++ to Java (for better or worse). Now, what did you want to discuss here, which language is technically superior or which language is more appropriate for Enterprise adoption? They are vastly different things... And BTW, f you over the Open Source comment. Ruby... geeesh.

Welcome stranger!

[Oestergaard]

Welcome to planet earth - we also have a language called 'C++', but it is rather different from what you describe.

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:Welcome stranger!

[Anonymous Coward]

>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

Yes... until you forget a blank between several lowerThan or greaterThan operators when instantiating a template... then suddenly, all hell breaks lose and you'll get 600 lines of error messages, leaving you absolutely no chance of finding the place where you actually made the error
(well, the only way of finding the guilty piece of code is by guessing.).

> 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.

Indeed... of course, C++ programmers like learning their language so much, that that's everything they'll do. Sure, for the first 3 years it's necessary, because whenever you've mastered one concept, you'll get bitten by all of it's little problems and exceptions and special cases.
And after that, C++ programmers always get so hot about templates and generic programming, that they'll write 1000s of lines of code just to use
that feature, thereby turning their code into something unmaintainable... except maybe by Bjarne Stroustrup, Alexandrescu or themselves... And after 10 years of that, they suddenly realize, that there's more to programming than just calculating the factorial at compile time (using templates) or
thinking about the PIMPL idiom (yes, that's a real thing, google for it, and yes: it's basically a hack to get around some C++ problems, and yes: it's bascally a neutered bridge pattern).

In short: Java (and, in turn C#) were created, to cut off the cruft of C++. Java is a simple language, that can be learned in a short time because the sheer number of language features and syntax ambiguities is considerably lower (do you know what "C++ digraphs" are? Yes? OK... so how many lines of code have they saved for you or how much safer have they made your code?).
Oh... and BTW: I prefer using a language, where I can actually get more than one fully compliant compiler; C++ doesn't have that. (Think I'm talking trash? Try using the "export" feature for templates in GCC or Visual C++... the only compiler frontend that supposedly knows them (haven't checked) is Cormeau).

murphee

Re:Welcome stranger!

[Anonymous Coward]

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.

I'd be tempted to buy into your argument if I didn't know someone who codes VOIP applications in C++.

There are books out there (Effective C++ series) that discuss how to write code so the compiler generates intelligent errors messages when it barfs on templates instead of the usual gibberish. Books that teach crazy, convoluted macros and #defines that allow you to do compile-time checks on template code, etc. Plus, the STL is buggy when used in concurrent applications.

You can learn the basics of C++ in a few weeks with Stroustroup's book. The advanced stuff takes years to learn and even longer to learn how to use effectively. I won't even get into the issues you run into with a build system for C++ code.

The problem with C++ is that it's too fscking complicated to use. Granted, there are a lot of idiots that think they're C++ coders because they could compile a Hello World! application, but they're not the sole issue.

Re:Welcome stranger!

[t'mbert]

I think you've pointed out exactly why MS and Sun have gone to other languages and away from C++: it was so perfect that nobody was making any money! Yeah, so they had to come up with something worse in order to generate revenue!

And..and..and corporate IT shops left C++ because they didn't want stable apps with no memory leaks and an extensive and rich API. Things were getting boring afterall, best to spice up that drudgery and reduce productivity with new languages!

Re:Welcome stranger!

[Elote]

I second this. There is very little that the more "modern" languages offer that can not be done nearly as easily as in C++, and you will get a huge benefit in terms of memory usage if not runtime speed.

There are some serious annoyances in the language however. Passing a pointer to an nxn array is not handled easily. STL performance sucks badly. I get tired of casting pointers to char* or whatever the heck is being used at the time for every other standard function call. The syntax for certain actions is really funky...with different meanings for certain keywords in different contexts. Look at the syntax for initializer lists, inheritance, declaring abstract/pure virtual methods. Most complilers don't give very informative error messages. Standards are not implemented uniformly between compilers(look at scoping in VS 6.0 which behaves as expected in GCC).

All of these can be fairly easily worked around. I believe what really bites C++ in the butt compared to languages such as Java is the available of standard libraries. In Java, for pretty much any task you can perform there is already a class in the standard library that will perform that task. Additionally, since all of these classes come from a single vendor, they all behave similarly, are documented similarly, and use familiar interfaces, patterns, and idioms. This is what kick my ass when writing C. Not only must you know the core language very well, you must also decypher what whoever wrote the libraries you happen to require was doing when they wrote it. The only really large and fairly consistent libraries I can think of are MFC and QT which both suck for very different reasons. With MFC you get all the performance of Java with the portability of VB, and with QT you must pay quite a lot to use it for development on Windows(not on linux though). If minor tweaks were made to the core language and better libraries were freely available noone would have any reason to migrate away from C++

Re:Welcome stranger!

[Oestergaard]

Thanks, really.

That would explain a lot of things.

Sometimes, one just needs to take a step back and have a look at the big picture. But then, sometimes, when you're deeply involved in this whole thing yourself (making money, building rock-solid software), even the most obvious of explanations will elude you.

I fell victim to that. Thank you for the enlightenment!

I can now go on doing what I've done every day so far, but now, now I understand.

Thanks :)

Re:Welcome stranger!

[Oestergaard]

To the bone girl. To the bone :)

Re:Welcome stranger!

[sploxx]

ACK.
People TOO OFTEN compare C++ to C. But C++ IS NOT C.

It's funny to see how C# and Java converge more and more to C++. Things like properties may be added to the language in C#, but you can do them with templates in C++. Without changing the language. A great thing for _portability_ and _stability_ of your designs. No Java 1.0,1.1,1.2.3.4.5.6xxx. (Sorry for being polemic, but I have yet to see how changing the language every couple years adds anything to portability or stability - too often I had to download some specific set of libraries or JRE)

For C++, I have either a commercial, statically linked binary (works out of the box) or OSS which I can compile with my choice of C++ compiler.

Granted, you have some nice additional features by using a VM (easier reflection comes to mind), but that is also doable in C++. And you have the whole platform with all the libraries at hand (not that they do not exist in the C++-World, not at all, there are many libraries to choose for a certain task). Therefore, Stroustrup et al. concentrate on the library part of C++.

The marketing department of Sun apparently did their job very well. By inventing a whole new platform and praising it as the best thing since the invention of the computer, they lured many developers into their platform and now they are
spread all over /. and dominate the opinion :)

But the arguments they put forward for Java could be reduced to the VM part. A VM for C++, and this is no problem in principle, would have sufficed. But the JVM is specifically tailored to Java, i.e. it is hard to run C++ on the JVM.

And... I have yet so see someone who is proficient in C++ (not C!) but not Java or C#. If you master C++, you master them all.

Re:Welcome stranger!

[archeopterix]

This is why there is actually not anything fundamentally wrong with our C++.

Except that you can actually program a GPF in C++. I call this fundamentally wrong.

Re:Welcome stranger!

[Oestergaard]

?

You can write malfunctioning software in all languages.

I can make a Haskell program that deletes my home directory, either intentionally or by accident.

I can make PostScript consume all memory in my printer.

I can make Java or C# drop a database on the SQL server. And I can make them consume all memory on the machine where they run. Actually, their lack of memory management control (forcing GC on the programmer) makes it difficult for all programmers *not* to OOM the system, somewhat in the same way that C++ makes it difficult for the novice programmer not to cause GPFs.

The difference being; no matter how good you are, you cannot (portably) work around the inherent problems in a forced GC environment. So no matter how skilled you are, you will eventually run into memory problems with large scale software systems on Java and C#. With C++ you can actually become skilled enough to not cause GPFs.

Heck, if you're the kind of person who believes 'HTML' is a programmin language, you can even write HTML that will segfault your browser (again by consuming all memory in the system).

Re:Only Microsoft

[Gr8Apes]

Pretty much any place where the action to multiple exceptions is the same log statement. Kind of silly to use multiple catch blocks in that scenario. (Technically correct, yes, but a waste of effort, when all you're doing is logging the exception)

More Features != Better Language

[Anonymous Coward]

Just because C# has more features does NOT make it a better language. Infact most of these Java 1.5 java changes annoy me. You could almost all these things in 1.4 there was just a certain way of doing it. If you have every programmed in C++ before with lots of different people who program things differently you will know that having different ways of doing things can be a VERY bad thing. This is way Java was so strong because there was 1 right way and 1 wrong way. Where in C++ you have like 3 right ways (that don't mesh together) and about 15 wrong ways to do something. Java is simpiler and faster to write code because you don't have 5 or 6 different ways of doing the same thing!

C# and Java are so similar....

[Manitcor]

that I dont care which a client wants anymore. Its like asking for 6 of one and a half dozen of the other. I had been afriad of learning Java for ages but knew C# very well. Then I forced myself to learn Java and as soon as I got into it I kept saying "Wow MS copied Sun!"

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.

Re:Java checked exceptions suck, but how to fix th

[Gr8Apes]

This actually sounds like a good use of annotations.

Re:APIs

[DevolvingSpud]

> like C#'s XML serialization / de-serialization

Well, there's XMLEncoder and XMLDecoder in Java, which handle simple cases really easily. Now to be fair I don't know the first thing about C# XML serialization. Also I've found XMLBeans (an open-source XML parser) to be way way better than JAX* for dealing with just about everything XML related.

And I agree - I think the attributes/metadata will be a big deal for handling XML in future Java endeavors.

Re:Only Microsoft

[jeif1k]

Yes, and Microsoft happens to be right on this one: "enforced checked exceptions" are a lousy idea.

As for copying, there was very little in Java that was original--languages like it go back to the 1960's. And in the few areas where Sun tried to "innovate", they often screwed up.

Re:APIs

[jchoyt]

I sincerely apologize for feeding troll. :oD

Re:Only Microsoft

[GreyWizard]

Only Microsoft could steal a language and do away with enforced Checked Exceptions (making try blocks optional) because it was "too confusing" to bother to check for errors.

Nonsense. Checked exceptions are bug not a feature. An exception is useful because it allows a programmer to handle an error or unusual condition in the place on the stack that makes the most sense. Checked exceptions force intermediate code that has no sensible way to address the condition to declare a throws clause. That's nothing more than pointless drudgery.

Worse, the entire concept breaks down when interfaces are involved. An interface can't predict what kinds of exceptions its implementations might want to throw, so there is no correct way to define them. Checked exceptions do more harm than good and should be removed from Java. I'm not a .NET user but I'm glad Microsoft had the good sense to leave them out.

Re:APIs

[AKAImBatman]

No, he probably means like C#'s XML serialization / de-serialization

You mean, something like Java's XMLEncoder? Nope, Java was still there first. Perhaps you're referring to the way DOM nodes can be queried directly via XPath?

That's certainly a nice feature that's not part of the core. No matter, we've been using libraries like JDom to XPath for quite a long time. :-)

How exactly is Java "OO from the ground up"?

[argent]

Java's primitive types are not objects. There's no reason they couldn't have been (compilers that generated efficient arithmetic code from high level components date back to the '70s) but they're not... which means you have to drop down to C-style types over and over again.

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".

Re:Only Microsoft

[mcc]

it just does not force you to declare and handle checked exceptions, an issue of strong contention within the Java community

Um, Java supports both checked and unchecked exceptions.

SunOS/Solaris

[perdu]

Well, this is the company that gave us the SunOS 5.8 === Solaris 2.8 rigamarole...

Re:SunOS/Solaris

[Nexx]

No, Solaris 7, Solaris 8. Last of the Solaris 2's was Solaris 2.6 :)

there is a difference

[RoninSix]

I've looked at most of the posts, and I haven't yet seen someone mention about the pointers and memory allocation that can be used in C#.

This is where Java and C# differ.

Java doesn't have these features and most likely will not have them any time soon.

Of course when using them in C#, you have to label the those areas of code using those features as unsafe.

"Two wrongs don't make a right, but three rights make a left."

not cross platofrm

[SQLz]

...there really isn't any difference whether you're coding C# or Java.

If you count not being able to run the program on any other platform than Windows. With JAVA, you could easily deploy a program for Win, Mac, and Linux.

I'm just amused

[mcc]

That he trashes C#/Java for requiring virtual machines, then suggests instead people use PHP/Perl... both of which are interpreted languages.

...

What?

Re:I'm just amused

[PierceLabs]

Stop it - you'll make him cry :)

Re:I hope so.

[Anonymous Coward]

Actually I think Jeremy had it right (I'm SexyFingers, the one who wrote the grammatically incorrect news - but my idea was to get some points across) --- A coding standard is a requirement for any development team - you can't trust the developers to abide by it all the time, but they will most of the time. And for those times when they're not, there's the code review process.

In the same light you're also correct - although idealistic - it would be nice to have a language out there that you wont need to to document, annotate, enforces coding style, etc. --- but that's an ideal (i think) - Knuth is making a stab at it with CWeb, his literate programming stuff (just google: Literate Programming), and in the meantime, the world keeps turning...

Quick summary of the comments

[raider_red]

I haven't paged through the comments yet, but I'll bet I can tell what will be posted:

1. Java Sucks
2. C# sucks more, and it's put out by microsoft, which is evil.
3. Java's not so bad
4. C# is better than Java
5. Perl is better than either of them
6. Python rules!
7. "But I prefer [C/C++, Lisp, Fortran, Forth, etc.]"
8. In Soviet Russia...
9. I for one welcome our new [java|c#] overlords

And of course, this post will be modded as flamebait.

Re:Quick summary of the comments

[fimbulvetr]

Actually, it seems as if /. has cut down on mod points given out. I (personally) haven't seen any lately and any more, it seems as if the story is older than 30 minutes, you're not going to see much.

So much for the /. of 2 years ago (or even a long time ago:)).

It's not so much the moderators fault, it's just that /. sees very volatile mods because there are not enough mod points given out to "normalize" the moderation.

Re:Quick summary of the comments

[blue trane]

I haven't seen mod points since the first slashdot troll post investigation...(according to this, I've been banned from moderating for life. sucks to be me!

What about competition?

[dpw2atox]

Well people are here now saying oh java is better and people are saying that c# is better. In my opinion both are good and just like competition should do (assuming MS plays by the rules this time) both products will end up the better because of it. For the longest time java had no real competition (in my opinion) and its development slowed down greatly but now that C# is starting to be used more and more often javas development has finally started to take off again. Nothing but good can come from this so rather than flame each other over this I think we should simply consider what features might improve either language and attempt to talk to communicate with the developers when possible to request these features and improve competition all around.

Parent is wrong

[mortenmo]

You can freely download Java 1.5/Java 5 for no charge. It's available now.

Re:There is a huge difference!

[TrancePhreak]

You sound like you've been visiting Timecube.com too much. C# has memory allocation routines available, but by default it's also got garbage collection. The rest of your post is just drivel.

Among other things

[mcc]

I'm curious, why do we still get buffer overflows in C++ code? I mean, the C++ string type and the vector container have been around for the better part of a decade now, and a standard part of the language for, what, six years? Seven years? And you can grab smart pointers from boost.

Widespread support for the STL-- meaning standard support, meaning your code's portable, not meaning "it works sort of similar as with the other compilers"-- was really, really slow in coming, and didn't really become universal until, well.. after Java.

Meanwhile very, very little of the associated literature for C++ really covers the STL. Many introductory C++ texts don't even indicate the STL's existence outside of cout, and I've never, ever seen any sort of teaching institution use a text for learning C++ that introduced things like STL strings and vectors immediately as something that coders should be using as soon as they know what strings and arrays are. If the STL is introduced by C++ textbooks at all it's introduced very late, as an "oh you can do this as well" sort of thing, after the reader's already become accustomed to using C strings and arrays.

As a result the "standard" C++ classes never really caught on as such. When people use C++ generally either they're locked entirely in to some vendor's APIs, or they're just doing C programming with classes. Most C++ libraries you'll come across will expect data passed to them as a C string or a C array or some kind of library-specifc homerolled string/vector class-- which doesn't particularly encourage developers to use the STL container classes since they'll just have to convert them to some other format in order to interoperate with anyone else.

I think basically the problem here is that even after all these years C++ just doesn't have a standard class library. It does have a class library that's endorsed by the C++ standards body, and you can claim that's the same thing if you like. But I'm not sure I'd agree.

Re:Only Microsoft

[rewt66]

Let me make sure I've got this right. The point of checked exceptions is to force you to think about the error cases. But they are a bad idea because having to think about the error cases gets in the way of meeting deadlines?!? Is that really what you are saying?

Yeah, the moderators were right - that's an interesting opinion, all right... Free clue: Yes, some people want to ignore error conditions in the face of deadline pressure. That's their problem. Forcing people to explicitly think about exception cases is a good thing.

The java generics system is a joke

[mrright]

The java generics system just saves typing and ensures type-safety for collections. But it does nothing about the problem of excessive boxing and unboxing that plagued java collection classes from 1.0 on.

For example if you have an ArrayList<Integer> in java, it internally uses an object[] to store the elements of the array. So everytime you write a new value to the ArrayList<Integer> by e.g. calling list.Add(i), a new object is allocated on the heap.

A List<int> in C# on the other hand uses an int[] internally, so adding or changing an element in the List<int> will result in no boxing/unboxing at all. A List will be just as fast as an int[] since the indexer method will be inlined.

The performance difference is dramatic: try creating an ArrayList<Integer>/List<int> and filling it with 1000000 numbers. The C# code will run 10 to 20 times faster, while the java version will use 20 bytes per Integer instead of 4 bytes per Integer like the C# version.

I am currently not at home, but if somebody is interested I will post a benchmark later.

Re:The java generics system is a joke

[mdemirha]

I did some tests and the benchmarks are really interesting. C# performs incredibly fast compared to Java. I didnt expect that much difference - may be I am doing something wrong...

Java Code:
public class Test1 {

public static void main (String [] args) {

ArrayList<Integer> l = new ArrayList<Integer> ();

System.out.println ("Started.");

for (int i = 0; i < 60; i++)
{
for (int j = 0; j < 1000000; j++)
l.add (new Integer (j));
l.clear();
}

System.out.println ("Ended.");
}
}

C# Code:
class Program
{
static void Main (string [] args)
{
System.Collections.Generic.List<int> l = new List<int> ();

Console.WriteLine ("Started.");

for (int i = 0; i < 60; i++)
{
for (int j = 0; j < 1000000; j++)
l.Add (j);
l.Clear ();
}

Console.WriteLine ("Ended.");
}
}

Java took 23 seconds to complete on an IBM Thinkpad T30 with Pentium 4M 1.8 Ghz.
C# took 1.5 seconds.

First, I want to say that I am not an expert C# or Java programmer. I use C++ mostly, and I really dont know which collections are best suitable for this job in each language. I used LinkedList and ArrayList in java and ArrayList performed 2 times faster than LinkedList. Similarly, I tried LinkedList and List in C# and List performed better than LinkedList - so I compared ArrayList in Java with List in C#.

Also, instead of adding 1,000,000 items in a list, I tried adding 10,000,000 - but java gave me an out of memory exception. I tried it with 2,000,000 and I got the exact same error. C# worked fine with larger numbers - I tried C# with 50,000,000 and it worked fine.

Re:The java generics system is a joke

[mrright]

List in C# and ArrayList in java are both backed by arrays, so they should have the best performance if you don't want to add or remove elements from the middle of the list.

The only way to get good performance in java would be to use an int[].

Re:The java generics system is a joke

[jekewa]

In your Java example you're making a collection of Integer objects, while in your C# code you're making a collection of int primatives. Not the same at all.

Of course, "inside" the Integer is an int, but it's got loads of other overhead, too. Inside each of your 60,000,000 loops, you're instantiating a new object in Java, while not taxing the C# similarly, additionally, 60 times you're tossing 1,000,000 objects for garbage collection.

I suppose one could use the autoboxing to put the little-I int in the collection, but I would speculate that the same thing would happen--behind your back Java would instantiate an Integer. A more fair test would be to create a small class and instantiate an equal number of them in C#, too.

I haven't got a C# environment on this system, nor a JDK 5 installation, so I can't verify that this makes a difference. I'm providing only a simple alteration that shows the intent of my statement, and offers a simple code change that similarly instantiates items.

Java:
public class Test1 {
private int i;
public Test1(int i){
this.i = i;
}
public static void main (String [] args) {
ArrayList<Test1> l = new ArrayList<Test1> ();
System.out.println ("Started.");
for (int i = 0; i < 60; i++) {
for (int j = 0; j < 1000000; j++)
l.add (new Test1(j));
l.clear();
}
System.out.println ("Ended.");
}
}

C#:
class Program {
private int i;
public Program(int i){
this.i = i;
}
static void Main (string [] args) {
System.Collections.Generic.List<Program> l = new List<Program> ();
Console.WriteLine ("Started.");
for (int i = 0; i < 60; i++) {
for (int j = 0; j < 1000000; j++)
l.Add (new Program(j));
l.Clear ();
}
Console.WriteLine ("Ended.");
}
}

Re:The java generics system is a joke

[mlk]

In your Java example you're making a collection of Integer objects, while in your C# code you're making a collection of int primatives. Not the same at all.

This is the point. In Java, you can not use Templates with primatives, with C++ and C# you can.

I really don't think it matters, if you need an growable array of ints, a few free implementations exist which follow the same blueprint as the java collections.

Re:The java generics system is a joke

[Big_Mamma]

Comparing ArrayList in java to List in C# is kinda nonsense, as you're always open to write your own classes implementing the java.util.List interface.

Depending where you're using the huge list of ints for, you can write your own implementation, if it ever becomes the bottleneck. While I haven't tested c#, in java (1.4.2b5), it spent 0.4 sec (-Xprof, so that's including some vm startup/gc) adding a million Integers(i) using the plain ArrayList, so it's not gonna be the bottleneck anytime soon.

Re:Java checked exceptions suck, but how to fix th

[rewt66]

Yeah, there's a syntax for this. It's called "put the try and catch in the function, with an empty catch block, and a comment that indicates why the exception can't happen." Then your function doesn't have to be declared as throwing an exception, and someone who looks at your code will understand that you didn't just eat the exception for no reason.

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).

Parent is right but referring to the wrong thing

[3770]

Java is free, MS VS Express products wont be.

pine? mutt

[flok]

Oh, how I pine for the days of vi vs. Emacs.

You must have meant, of course mutt.

Re:pine? mutt

[julesh]

mutt? MUTT?

elm, I'll have you know.

JNI

[Anonymous Coward]

Java has had a way to write "unsafe" code from day 1.2. It's called JNI. Write your unsafe code in an unsafe language and hook it in with a dll.

Re:JNI

[Anonymous Coward]

JNI is inefficient and cumbersome. Furthermore, it requires you to compile and ship separate versions for every single target CPU. In C#, unsafe code is portable and WORA (and that's not a contradiction in terms).

Re:JNI

[freshtonic]

JNI is inefficient and cumbersome. Furthermore, it requires you to compile and ship separate versions for every single target CPU. In C#, unsafe code is portable and WORA (and that's not a contradiction in terms).

Portable?! Um... yeah portable accross all Windows platforms if you are lucky, and even that depends on what you do inside the unsafe code

Re:JNI

[mlk]

I wish Sun used CNI.

I'm a pro-Sun/Java kind-of guy, but JNI is bad.

So is static import.

You can: kuro5hin.org

[freality]

Just when i start reading /. for a few days again, i'm reminded why it's so easy to drift........ away......

Rules on languages...

[feloneous cat]

I have a couple of rules when regarding languages:

1. Does it have wide industry support or is it merely another "we ship it until we kill it" single-sourced language.

2. Does the name sound like it could hurt you?

C# pretty much fills the bill (no pun intended) for both 1 and 2.

MS is no stranger to introducing something and then killing it some time later (hence my avoidance of both .NET and C#). And just when you get used to version XYZ, they come out with XYZ+1 which changes EVERYTHING. Sorry, I don't need my code to die at the whims of MS.

Then there is the whole "C#" name which, frankly, I think sounds retarded. To most Americans, the '#' symbol is pronounced "pound". Few people I know call it a "sharp" (actually, NO ONE that I know calls it that).

Finally, just the sound of it sounds dangerous and, if inserted in the wrong place (like my MIND) could cause harm.

Re:Rules on languages...

[shish]

Few people I know call it a "sharp"

I call it a hash - I'm not sure if that's the official english name or just mine though :/

Re:APIs

[SnapShot]

dom4j vs. jdom, the vi vs. emacs of the Pepsi generation ;-)

For me C# doesn't matter yet

[buttkick]

I don't code much for living, but I managed some projects, and programmers. But I put a list of priorities in a project. The most important thing for me in a project? RELIABILITY. Because it's cheaper for me and the client. I don't want to spend my time fixing things that shouldn't be fixed. So therefore, NON-PORTABILITY to ROBUST PLATAFORMS(UNIX etc) other than windows in C#, makes JAVA a superior language. I don't care if I code in C# in 20% less lines than JAVA(and that isn't true), running only in windows make it an option that I just can't accept. I hate both languages, C# and JAVA, both are slow, and resource hungry, but a never will put reliability, portability, in front of ease of use. So let's bring back VB? Maybe VB is C#... you know.

Re:For me C# doesn't matter yet

[buttkick]

Let me correct my other post. I don't code much for living, but I managed some projects, and programmers. But I put a list of priorities in a project. The most important thing for me in a project? RELIABILITY. Because it's cheaper for me and the client. I don't want to spend my time fixing things that shouldn't be fixed. So therefore, NON-PORTABILITY to ROBUST PLATAFORMS(UNIX etc) other than windows in C#, makes JAVA a superior language. I don't care if I code in C# in 20% less lines than JAVA(and that isn't true), running only in windows make it an option that I just can't accept. I hate both languages, C# and JAVA, both are slow, and resource hungry, but I never will put ease of use and code, in front of reliability and portability, and effience. So let's bring back VB? Maybe C# is VB... you know.

Re:I hope so.

[blowdart]

Generics? Ugh.. you mean we have to see that nasty template crap from C++ again?

I can only talk about this from a C# POV but no, hell no.

The template crap from C++ was nothing more than a preprocessor/compiler trick. It took the templates and expanded it out, making it heavy, fat and inflexible.

Generics are build into the CLR now, type safe and fast, especially when building things like primitive collections, where you no longer have boxing getting in the way of speed.

It's the installation stupid

[nzgeek]

I've done enterprise-level Java and C# implementations for financial institutions, and reckon there is one thing that people always miss when comparing the two languages: installation.

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.

Re:Parent is right but referring to the wrong thin

[Knetzar]

You don't need VS to write .NET applications. The compilers come with the framework, which is free, once you pay for the OS.

Re:Parent is right but referring to the wrong thin

[blowdart]

You're comparing the wrong things though.

The Java SDK and compiler are free. The .net SDK and compiler are free.

Visual Studio, the editing environment isn't, but provided you can write a make file (well, sorta) you're sorted. Of course there's always Sharp Develop if you must have a free IDE

Re:Java checked exceptions suck, but how to fix th

[The Pim]

I'm talking about cases where you cannot prove that the exception won't happen, so your technique (which I'm sure you are not recommending for those cases) would be reckless. It is actually rare that you can prove a checked exception won't happen, either because it is impossible in principle (eg FileNotFound), or because the specification doesn't guarantee the exact conditions in which it may be thrown.

You're going to name it what?!

[richever]

Sometime in 1999 after I'd worked at Sun for about a year, a routine all-hands meeting was held for all of the Java Software division. JDK 1.1.8 was the current version of Java on the street and JDK 1.2 was in the works, almost ready for release. We sat there and listened to the usual rah-rah speaches from the divison's head honcho (can't recall who it was at the time), and then he introduced us to a marketing guy to tell us about the launch for JDK 1.2. As he begun talking he displayed a new slide on the project and it read, in all its powerpoint glory, 'Java 2000!' And he went on to say that the new JDK would be called, not Java 2, but Java 2000. Everyone in the audience started laughing hysterically. We all thought it was a big joke. I mean, Microsoft was on the verge of releasing Windows 2000, so you don't really mean.... Turns out this marketing guy didn't have much of a sense of humor. "I'm not joking", he said. The laughs and knee slappings turned into boos and hisses. Head honcho guy says something like the marketing guys have worked hard on this and that's the name they've choosen. The Q&A session was next and, boy, did both of these guys get an earful! Anyway, I can't say for sure, but I think that had it not been for the outrage and disbelief at that all-hands we'd be stuck with even weirder Java naming convenstions today.

Rich

Re:You're going to name it what?!

[p2sam]

I would had prefer Java 2000 over Java 2. The first one is clearly meant to be used for marketing purposes ( I think you Sun guys call it branding ). The later is ambiguous. I can't tell if it's a marketing name or an engineering version name.

Re:Parent is right but referring to the wrong thin

[Cereal Box]

It doesn't matter because you can get VS Express for free (which allows you to write C# 2.0 code), and eventually C# 2.0 _will_ be released for free. You can just use the free VS Express to tide you over until then.

Bad coding habits

[21mhz]

Static Import, actually promotes bad coding habits IMHO
Ever seen bogus base classes or interfaces used to declare a bunch of constants? Those guys apparently missed static imports badly, if only to make their bad habits a bit more elegant.
Bad coding is possible in every language.

Re:Bad coding habits

[blue trane]

I've seen a class used purely to declare a bunch of constants used throughout the application...what's a better way? trying to learn here...

Re:Bad coding habits

[21mhz]

One thing is a class of, say, Globals, referred as such thoughout the program. It's clean and good.
What I said about is IConstants, "implemented" by every class that references the constants.

matryoshka programming

[4of12]

Seems related to my favorite pet peeve in OOP.

Spaghetti programming techniques can be reimplemented with a vengeance using matryoshka techniques (named after those Russian nested dolls).

This kind of programming does violate XP tenets suggesting that interfaces should be kept shallow. Methods that reach back into the third nested doll make me just cringe.

It's like spaghetti that wasn't properly rinsed and starts sticking together together...

Re:Only Microsoft

[toriver]

the entire process of declaring a thrown exception through mutliple layers is an asinine waste of my time
Interesting. Which other aspects of creating reliable code do you skip? Do you ever test for null values? Also waste of time, right? C# must suck because you need to add all those "override" whenever you override a method in a subclass - a clear waste of your time.

Partly agree

[Hortensia Patel]

Well, the safety problems are largely a result of having raw pointers in the language, which you can't really "fix". Major, backward-compatibility changes just ain't going to happen, and rightly so. There's room for a new language in the C++ space, but it will have to be just that: a new language.

My personal gripes:

- Being near-impossible to parse correctly and efficiently. Which mostly means the preprocessor, but also name lookup rules, template POI rules etc. This is why the state of C++ tooling is so dire; our IDEs are a sad joke compared to what's available for Java.

- Weak standard library. (cries of "Heresy! Burn him! Burn him!") Yes, the STL is terribly terribly clever, and elegant, and impressive. It's just not terribly useful. Most people use iostreams, vector, list, map, string and not much else. How often have you needed to stable_partition a deque? Compared to, say, needing to portably list the contents of a directory?

- As you say, obsession with templates. The original standard library was bad enough; std::string did not need to be templated, nor did the iostream library. The current metaprogramming craze has made things even worse; it's great as an intellectual challenge, and to discover through experiment which areas need better language support (*cough*typeof*cough*). But not for everyday production code. It's hard to maintain, hard to diagnose when it breaks, and multiplies compile times by orders of magnitude. Trying to do agile development in C++ is a painful experience at the best of times; when it takes MINUTES to compile a five-line file, it's flat-out impossible.

That said, there are still areas in which C++ beats everything else out there:

- Control. It's the only mainstream general-purpose language that supports deterministic destruction and RAII. The importance of this cannot be overstated. GC is all very well, but given the choice between leaking memory and leaking file handles, or DB connections, or mutexes, I know which way I'd go. Similarly, GC pauses still rule out Java/C# for many realtime apps, even soft RT.

- Programming-in-the-large. In my experience, a single C++ source file takes much longer to compile than a single Java or C# file. But a large C++ system can be incrementally rebuilt after a change to one (non-header) file much faster than a Java/C# system. Header files are a repulsive kludge and a royal pain, but they're there for a reason.

Re:Partly agree

[Animats]

That's a good analysis.

A major problem is that there's no major player pushing for higher reliability in the language. There's a high-reliability standards group for Java, but none for C++.

Re:Only Microsoft

[GreyWizard]

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.

First of all, checked exceptions are not the only, not the best and not even a particularly good way to get documentation about what exceptions might be thrown. Programmers can and often do declare "throws Exception" which completely defeats the purpose. An automated documentation tool like javadoc can and should enumerate the possible exceptions each method might throw.

Second, checked exceptions are an unacceptable burden on programmers for several reasons. They are a tedious obstacle to rapid prototyping, where a programmer cannot really know what exceptions are likely to be thrown and shouldn't be asked to enumerate them. You won't get a chance to write a server application that has to work 24/7 if you can't create an effective demo in time. Even when creating production code there is no reason to soak up programmer resources fighting pointless compiler errors. Some code simply should ignore exceptions, but checked exceptions don't allow that.

A good example of code that should ignore exceptions is interfaces. Checked exceptions make it impossible to correctly declare interfaces because there is no way a programmer can forsee every possible checked exception anyone might ever want to throw in an implementation class. Were all of this not true, why would Sun have officially enshrined swallowed exceptions in the JDK libraries with the "cause" method?

No other mainstream programming language has checked exceptions, and even languages that exist primarly to duplicate the good features of Java aren't adopting them. Why? Because they are a bad idea. It's that simple.

Next up on Slashdot...

[Liquid Len]

Religion: Which is the One True Faith?

(Stolen from snpp.com)

Re:Next up on Slashdot...

[mlk]

Religion: Which is the One True Faith?

Emacs. :D

With Java, stuck in Windows/Linux/Solaris

[RdsArts]

"I want C# on my *N*X/Window box"

http://www.go-mono.com/

"I want Windows.Forms support on my Mac/*N*X/Windows box"

http://www.dotgnu.org

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)

Re:With Java, stuck in Windows/Linux/Solaris

[shaper]

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.

Re:With Java, stuck in Windows/Linux/Solaris

[kaffiene]

Quite so. It's increadible how much the anti-java brigade fail to see the ammount of industry support for Java and claim that Java is just "Evil-Sun" (tm) 's Smash-OSS-O'Rama software.

Java is genuinely cross platform and genuinely open. FFS, the Apache foundation has as much influence on the direction of Java as does IBM, or BEA, or... Sun.

Re:With Java, stuck in Windows/Linux/Solaris

[Joseph_Daniel_Zukige]

I have a *BSD box. I have Java running on it. Took a day to compile while I did something else productive.

But if I want Windows.Forms (why, I wouldn't know.), I have to load a half-done mono and a half-done dotgnu.

I got burned on Microsfat C a long time ago, and I will never listen to their sales crew again.

Re:With Java, stuck in Windows/Linux/Solaris

[RdsArts]

Perhaps, but the point I was trying to make was that there are a number of complete, portable solutions for .Net and C# today, whereas if you want to port Java you're stuck hoping your/a vendor will license and port it, or hoping Sun will.

Hopefully this will end soon when GNU Classpath becomes more complete, and we have a even playing field (more or less) for the languages that are outside the scope of the "owning" company. But as I said this is all IMHO.

and how is this insightful?

[Matt Ownby]

The thread is hardly over. Visual Studio is one of the few applications Microsoft has released that I actually like. I still use VS6 at home, and I use VS.net at work. As another poster said, the debugging in Visual Studio is awesome. The two debuggers I use are visual studio in windows and gdb in linux. Gdb is powerful but, being text-based, isn't nearly as pleasant to use as visual studio's GUI debugger. Visual Studio's intellisense and auto-formatting also do what I want them to do, and I have yet to find an IDE in linux that "just works" the way visual studio does.

Microsoft IS evil, but Visual Studio is nice, and it is being developed by some very smart people.

Re:and how is this insightful?

[Anonymous Coward]

The two debuggers I use are visual studio in windows and gdb in linux. Gdb is powerful but, being text-based, isn't nearly as pleasant to use as visual studio's GUI debugger.

You're comparing apples to oranges. If you want to compare GUI front ends, you should at least use one of the gui front ends in your comparison. I used DDD in the past. There are others.

Personally, I use GDB-mode in emacs - my biggest frustration with Visual Studio is that there's no easy way to see the history of variable's values.

I'd want to run through a loop 100 times and have a buffer showing the values of the variables from each of those hundred times in a table. Trivial with gdb-mode under emacs. With Visual Studio it refreshs the values each time I hit a breakpoint so I can't see the history.

Re:and how is this insightful?

[spacecowboy420]

Basically because he makes the point Java is portable and c# is not - no matter what the niceties of c# are, it misses this basic feature. Java is comparable to, if not exceeding the features of c#, in addition to its portability. We can readdress this when mono is finished and both languages are on a level playing field, until then, it's a moot point, Java rules. If MS supported .NET on other platforms, this would be a different discussion and not so cut and dry.

Re:and how is this insightful?

[dtfinch]

Dotgnu is starting to look pretty good. Installed it last week.

Re:and how is this insightful?

[angel'o'sphere]

Yeah,

indeed, debuggin in visual studio is awesome. Granted. Hm, does anyone remember the company from wich MS bought that technology? I can reboot one of my very old 486 (year 1993) PCs where I have used the same debugger on Symantec C++ 6.0 (Larry Wall, D++, ever heared about?). Frankyl, I don't see much improvement in Visual Studio, but my latest version is from 1999 ... in respect to Symantec C++.

OTOH, I use Eclipse at my customer sides .... because they never heared about IDEA IntelliJ or about Omnicore CodeGuide :D at home I use CodeGuide for dayly work and Eclipse for CVS.

I would dare a statement:
*ALL* Java IDEs are *FAR* beyond any C++/Microsoft IDE. The only thing comming close to Eclipse is SNIFF+ from WindRiver (shit, forgot the old company name, was it Take Five?) ... well, the old SNIFF IDE was crafted by the same guy behind Eclipse. But thats a guy from GOF ... and most /.ers put OO and patterns into one basket and still think assembler rules :D

angel'o'sphere

Re:and how is this insightful?

[angel'o'sphere]

hm ... I allready posted, so it makes no sense to use my mod points here, can someone please correct teh TROLL rating on parent?

Re:and how is this insightful?

[ckaminski]

I'm not too found of Intellisense, actually. I've found that 99% of the time, it locks up my interface while it searches the browser database for a tag, and or it requires me to move my hands from the alpha keys to the arrows to complete a task. It's mentally exhausting to deal with when all I want to do is stream-of-consciousness programming.

I won't even deal with auto-format which is much worse in my opinion...

But to each his own. Best of luck to you!

-Chris
----
Visual C++ user since 2.0.

Re:and how is this insightful?

[ckaminski]

tell me more about this gdb-mode swami?

Re:and how is this insightful?

[chefren]

the debugging in Visual Studio is awesome

Only in vs.net. How do you stop a VB6 program running and endless loop in the debugger? Besides killing VB?

Re:and how is this insightful?

[generalpf]

You press CTRL-Break. It's undocumented but it works, even when you're surrogate-debugging a COM object.

Re:Parent is right but referring to the wrong thin

[3770]

That's what I'm saying.

VS Express _Beta_ is free. The released product will cost money. Microsoft has said that it will be cheap, but VS Express 2005 _will_ cost money.

Language differences?

[Jugalator]

So if you're doing C# and your foundations in OOP are rock-solid, there really isn't any difference whether you're coding C# or Java."

Yeah, except the entire API!

At least for me, it takes far longer time to learn and adapt to Microsoft's .NET API or vice versa than to learn a few simple language syntax differences.

C#?

[NeoGeo64]

I'm still faithful to C++ (just upgraded to Microsoft Visual C++ .Net 2003 Standard Edition) and I'm wondering what the differenes between C++, C++ .Net and C# are?

Re: Generics

[rreyelts]

You are correct re:generics.

No, he's wrong. The Java 1.5 compiler stores the generic type attributes in the class file in what are called "Signature attributes". Generic types are perfectly safe across compilation boundaries. Where they aren't safe is when they are combined with raw types. That behavior is by design, and it is the tradeoff paid for having mostly seamless compatibility with an existing codebase. Whether that was an appropriate decision is an entirely different discussion.

tunnel vision

[Anonymous Coward]

From a developer perspective, one would think the wise thing to do is to learn both and encourage MS and SUN to duke it out. In reality, neither one is going to rule the world. It's just not possible at this time and probably won't be for another 20 years.

For all those who keep saying java is dying, Unix is dying, and mainframes are dying. Fact is, they aren't dying. Are the roles changing? Well yeah! Nothing ever stays the same and things will always change.

A professional developer should always think about the needs of the clients first. that means using C# and .NET if they are a Microsoft centric shop. It also means being up front and honest about everything. No one language is perfect and no one platform will ever be perfect. Most of the platforms today are sufficient for the majority of the businesses. Blindly believing marketing and PR material is both retarded and silly. Languages and programming shouldn't be a religion. It's a tool god damn it.

If you aren't willing to spend the time to learn the tool, freaking get out of the IT industry so the rest of us can focus on getting work done. </rant>

Where can I get C#?

[SamSeaborn]

Okay, I'm convinced. I've been programming in Java for years but C# sounds cool enough to try ... where do I download it?

You mean, I have to buy it first before I can even try it?

I can get JSDK 1.5 and J2EE and a great IDE in Eclipse all for free. Heck, I can even download a free version of JBuilder. Why should I pay for C# when I don't even know if I like it yet?

Sam

Re:Where can I get C#?

[ChatHuant]

Free C# compilator? Right here: .NET Framework SDK

Or here: Mono project

Free IDE? Here: Sharp Develop

Or, if you want to test .NET 2.0, go here:
.NET Framework 2.0 SDK

As you see, you don't have to pay anything to try C#; since you say you're convinced, go for it!

Exceptions anybody?

[Anonymous Coward]

One thing that makes me nuts in C# is its lack of compile-time enforcment of Exception handling. When I made the switch from C++ to Java, I fell in love with Java's compile-time checks for appropriate try/catch blocks.

In my C# development over the past year, I've been repeatedly frustrated by exceptions popping up in unexpected catch blocks because they were thrown and not caught deep down in the bowels of my code.

To me, that's more or less a deal-breaker in choosing C# for large-scale development. Unless developers are exceptionally disciplined (and that's hard to guarantee across a large/distributed team), lack of compile-time enforcement limits Exceptions' usefulness.

ENUMS!!!!

[CaptainPinko]

Am I the *ONLY* that thinks Enum support is the biggest and most important change in Java 1.5? Really they make writing code --especially when writing your own protocol-- much cleaner and save you having to check for gofy input in your methods themselves.

I too would love a Java 2.0 (no, not Java2 1.2) where we break backwards compatibility and toss out the old crap. It should probably come with a 1.x jvm to mkae the transition easier but it would at least provide a path to a scaled down API. I think after 4 years of 1.x and 2.x the 1.x could be dropped with little ill effects (even today's x86 aren't compatible with the 8088). And yes I do know what deprecated code is and how that works.

Not sure wht you were getting at but...

[SuperKendall]

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.

I can't decide if you are talking about C# (true if so) or Java.

If Java, then your argument has no merit - as Sun does not control what goes in the language, and has not for some time. That is decided by the JCP, Java Community Process - a board of people from LOTS of different companies (like IBM).

If Sun controlled Java Generics would have been in 1.4 already. They have been around in the wings for a LONG time now.

Except you got exceptions wrong

[SuperKendall]

My facts are perfectly accurate; what you wrote does not contradict what I wrote.

Your original post proclaimed Java must declare exceptions, which is false. How is it not false?

I agree that unechecked exceptions are the way to go for projects of any size, and have been using them in Java for years now.

Re:Except you got exceptions wrong

[jeif1k]

Your original post proclaimed Java must declare exceptions, which is false.

No, it didn't even proclaim that. But, just for the sake of argument, let's say it did: if you tell me that you eat cookies, does that mean that you eat every cookie in existence?

I agree that unechecked exceptions are the way to go for projects of any size, and have been using them in Java for years now.

The problem with Java's declared exceptions is that libraries are full of exceptions you do have to declare, and those cause problems. That is, the existence of an exception declaration mechanism in the language is the problem.

An additional problem is that Java doesn't even type-check the declared exceptions it has correctly: something can throw java.io.IOException even though it doesn't declare it.

You seem to be...

[^BR]

...either a troll or a really incompetent programmer. Expect your job being shipped to India, where somebody with a functionning brain will take over....

Care to name that 1.3 only IDE and those numerous API changes?

Apples and Oranges

[deuterium]

As other posters have said, I don't think that C# is meant for big enterprise apps, but littler 'toy' apps. Still, you'd be surprised how many of such apps are in use right now. The biggest strengths of C# are:

1)Simplicity. Everyone loves to argue about how purists should code things, but in the real world, a lot of code is written by people who are blissfully ignorant of theory. VS allows them to make obvious progress, reusability be damned. A crude, but working app is more impressive to a clueless manager than a collection of nascent classes.
2)Integration. This goes along with #1. Much of the heavy lifting in creating desktop apps is rolled into .NET, so that a user can program to a higher level library. Documentation is all there. It also provides all of the tools and files needed in one tidy install, without the need for combining different packages. It all comes from one vendor, and it's easy to get your mind around.
3)ASP.NET. I would argue that ASP.NET is the easiest way to accomplish application-like behavior in a web site. Session state works well, database access is a couple lines of code, and you can even draw the page on a coordinate system if HTML stymies you. Scorn it if you must, but it's a good step toward standardizing web/application development.

varargs is *not* an enhancement

[hopethishelps]

5. Varargs (C# 1.0's params construct, ellipsis construct in C++)

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:varargs is *not* an enhancement

[rreyelts]

varargs is *not* an enhancement

Although I'm not incredibly fond of varargs, you mischaracterize them greatly. Varargs in Java are entirely type safe. For example take,

void foo( String... values ) { }

The compiler will only allow me to call that function with a list of Strings, which then gets boxed as a String[] on its way into foo.

There is no equivalent to varargs in C++. When a function uses an ellipsis, it has absolutely no idea what data is actually being passed to it. The compiler does no enforcing of types upon invocation, and you have no type information at runtime. If the programmer goofed, you are fubar.

Re:varargs is *not* an enhancement

[anarxia]

gcc has an attribute to allow for type checking for printf-style functions.

If Sun creates a method to define expected types at compile time then the type-checking argument becomes void.

Re:varargs is *not* an enhancement

[barrkel]

Varargs is a problem in C/C++ because it isn't type-safe. It is type-safe in C#, and thus isn't a problem.

Re:Only Microsoft

[clamatius]

Programmers can and often do declare "throws Exception" which completely defeats the purpose.
So you shouldn't have checked exceptions because people might be dumb? Programmers can and often do totally ignore the possibility of exceptions (for example, in a lot of Microsoft example code) which can cause complete system failure. I could use the "people are dumb" argument to say that you should have checked exceptions as well.

An automated documentation tool like javadoc can and should enumerate the possible exceptions each method might throw.
Uh-huh. I haven't seen one that does this automatically for C#, it relies on the programmer to list them. Microsoft's own libraries have some documented exceptions that can be thrown but not all of them.

They are a tedious obstacle to rapid prototyping, where a programmer cannot really know what exceptions are likely to be thrown and shouldn't be asked to enumerate them.
Use a rapid prototyping language if that's what you want. By the same argument, maybe C# should get rid of strict type checking too - that's a tedious obstacle as well, right?

Checked exceptions make it impossible to correctly declare interfaces because there is no way a programmer can forsee every possible checked exception anyone might ever want to throw in an implementation class.
Sure. But as a client of the interface, if the new implementation you dropped in throws some random exception that I don't catch because I didn't know you could throw it, it's impossible for me to catch the exceptions I cared about and pass up the ones I didn't. So then it makes it impossible to correctly write a client class, since I can't forsee every possible exception anyone might want to throw in an implementation class.

Double Duh!!

[Nom du Keyboard]

Enhanced For-Loop (the foreach construct in C# 1.0, duh!)

How about Double Duh? For...Each goes back to when Visual Basic still had version numbers, as opposed to .NET release years and product names, and C# wasn't even a gleam in Bill's eye.

Go Read This

[cthrall]

http://blogs.msdn.com/cyrusn/archive/2004/10/11/24 0673.aspx

Then tell me how much you want to push C# to production.

What really sucks...

[argent]

What really sucks is people who write [Java|C#|C++|Lisp|...] programs that run slower than shell scripts because they get lost in a twisty maze of inherited methods and end up with their view object having a method that forces a refresh of a list of objects in a box that ends up calling that method on the original object unless the object's position hasn't changed, so every time you resize the box it does a very slow and painful iterative balancing act to get the layout right... but they never notice because they're developing it on a 3 GHz Pentium IV...

Not that I'm bitter or anything, I just want an object system that includes a mandatory test on a Pentium 100 before the packaging tool will link it in with the production runtime. If it also involves painful but not dangerous voltages applied to sensitive organs if they try to skip this step it'd be a bonus.

The libraries will make/break a language

[chiph]

The included libraries will make/break a language, and right now, the .NET libraries are much easier to use. Partly because they were designed "as a whole" and don't have a lot of cruft in them (yet). And partly because the MS on-line help is vastly superior to JDoc (does Sun not believe in code samples?).

The biggest weakness I see in the .NET framework is that 90% of it uses concrete implementations. Because they didn't use an Interface-driven design, they now have to fall back on the Win32 style of appending "-ex" to class names when they want to improve them, rather than letting a dynamic loader find the class the developer needs.

Even so, the Visual Studio IDE is so far ahead of any of the Java IDEs (Eclipse comes closest), that it's probably Microsoft's single best competitive advantage.

Chip H.

Java:JVM != .NET:C#

[DoubleReed]

C# is just one option for .NET eh?
Hmm... if only there were some other languages that could be compiled to JVM bytecode.

does c# have the concept of RMI?

[the-build-chicken]

Anyone?

Re:Obligatory

[cakoose]

Rob Pike has done some really cool stuff, but he's also kind of a weirdo. He doesn't believe in putting any "#include" directives in ".h" files. He says you should figure out what the dependencies are and put all the includes in your ".c" file.

Rob Pike's Notes on Programming in C (go to the bottom of the page).

Re:Reflection?

[jekewa]

Yes.

import java.lang.reflect.*;

Re:Sounds a lot like religion

[puddpunk]

Looking at your other posts, kfg, I figure this post is actually on topic.

What he means is that out of Java and C# he cares for neither of them and cares even less about what happens to them. That explains his little analogy :D

Am I right, do I win a prize? :)

Re:Reflection?

[jekewa]

I suppose this is better. Or this, for the JDK 5 documentation...

C#2.0 and IDEs

[shodson]

DISCLAIMER: I develop heavily in both C# and Java, more C# than Java, about 80% C#, 20% Java, not by choice but based on client demands.

I don't think it's fair to compare Java 1.5 (released) vs. C# 2.0 (beta, who knows when it'll actually be released). That's like comparing Linux to Longhorn.

And re: IDEs, while programming so much in VS.NET, I missed all of the cool features of my IDEA IntelliJ Java IDE that I was excited to buy ReSharper, bringing some of IDEA's cool features to VS.NET.

One of the main things I like about .NET, though, is that the libraries seem to be more consistent, whereas the Java APIs have evloved and been added to by different developers using diffferent programming styles and approaches to patterns, each package seems to implement different programming styles and constructs, but you get used to it after a while. Plus, Java has so much deprecated code, they need to clean those out once and for all and clean up the APIs, see this for more details of what I'm talking about.

Copy & Paste

[AngryScot]

I have spent a little time using C# and it seems that all sun/microsoft are doing is trying to beat each other by adding features to their language that other one has just added/will be adding.

I thing this is good for the coders out there who can take advantage of these improvments in both the languages.

Anyone who has heard of Glenn Rowe, thats his opinion too and he doesn't hide it :P

Re:Obligatory

[DrSkwid]

you read it wrong

Simple rule: include files should never include include files.

it means that if one has

#include "plan9.h";

then plan9.h shouldn't have any #includes

*not* that you push them into the .c

then when you include plan9.h in *your* program you can choose which libs plan9.h & plan9.c can have access to.

main.h :

#include "9p.h";
#include "plan9.h";

you can then plug in your *another* implementation of 9p.h

main2000.h :

#include "9p2000.h";
#include "plan9.h";

thus plan9.h doesn't bind you to an implementation

in your plan (as I am reading it) you would suggest

main.h :

#include "plan9.h";

plan9.h :

#include "9p.h";

then how to write main2000.h ?

Re:Only Microsoft

[ClosedSource]

"The point of checked exceptions is to force you to think about the error cases"

Any language feature that is intended to force a programmer to think about what the language designers thought was important will fail. Checked exceptions are no exception to this.

The hammer shouldn't be selecting the nail.

Re:APIs

[Rudeboy777]

where do I find the "don't suck" feature?

Found it!

Re:I hope so.

[jallen02]

Well, typically you want senior development staff to write the standards. If you pick senior staff (sucha s your architects or what not) to write the standard it works much better. You get people who code day in and day out to pick what works best for a particular project (with perhaps some company standard that each projects starts out with and modifies as is needed, if the firm is big enough to warrant it).

I don't know of a programming language out there that you can't abuse and torture and write unreadable code. Its simple, in any environment where more power is put in the hand of developers the more care must be taken. With assembly you can do ANYTHING, and fast, but its hard to write structured code. The point is that you can still write a program that can do just about anything your mind can conceive (that can be executed by todays computers). With the ability to write any program comes an inherent degree of complexity. If you don't manage the complexity your project will fail.

So, any one language that is "just" right for one project may not be "just" right for another project. As it is Java does not give a lot of latitutde in how you can do a great many things. For the rest there are coding standards. If standards are not followed them Team 1 may not understand Team 2's code as easily. It is managements job to educate and get everyone happy with the idea of a standard (perhaps someone doesn't like THIS standard, but they must at least be made to agree upon it regardless). Thats why programmers who work for money are paid, they are supposed to do what they are told :)

For the record I have never had any trouble (ultimately) getting my coding standards followed. It may take some discussion and tweaking to get everyone happy, but thats what being a senior staff developer is all about: mentoring, educating, and writing good code ;)

Jeremy

Operator overloading

[evilpenguin]

Say Amen!

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:Operator overloading

[evilpenguin]

BigDecimal doesn't a Currency class make. I'm talking about something that will do currency exchange and financial calculations. Mine uses BigDecimal inside.

But even if you just handle one currency and can thus use BigDecimal directly, you still can't overload the algebraic operators.

Re:Sounds a lot like religion

[kfg]

Am I right. . .

Yes. I guess I need to start using Zen tags or something.

. . .do I win a prize?

Absolutely. You win an hour, all expenses paid by you, in beautiful, downtown Troy, NY.

Second prize is two hours in Troy.

KFG

Re:Sounds a lot like religion

[kfg]

While offtopic. . .

See above.

. . .this is easily the most interesting comment in this story. Thank you.

You're welcome. That entitles you to second prize, as per above. My condolences.

KFG

Re:Parent is right but referring to the wrong thin

[Cereal Box]

OK, and what I'm saying is that you don't NEED VS Express to write C# 2.0 code (you only need it for now because that's the only thing shipping with a C# 2.0 compiler at the moment). Soon enough, C# 2.0 proper will be released FOR FREE, including its own compiler.

Hence, it doesn't matter if VS Express someday costs money. You can still code C# 2.0 for free.

In praise of C++

[Baudelaire76]

C is too low
Java too slow
Fortran is... well, Fortan
C# has mono
Perl has gono(rrhea)
None can do what C++ can!

Java is a 32-bit language; C# is a 64-bit language

[mosel-saar-ruwer]

SexyFingers: So if you're doing C# and your foundations in OOP are rock-solid, there really isn't any difference whether you're coding C# or Java.

GCP (122438): And I was a member of one of the JCP expert groups that brought you Java 5.

The single biggest disadvantage of Java is that it is inherently 32-bit in nature, and is utterly unsuited for use in the emerging 64-bit marketplace [x86-64, anyone?].

For instance, the following code will NOT compile [or "javac", or whatever you want to call it] in Java 1.5:

public class SixtyFourBit
{
public static void main (String args[])
{
long theLong = 1;
theLong <<= 32;
System.out.println("theLong = " + theLong);

double [] theDoubleArray = new double[theLong];
}
}

Java is a language designed to run on the hardware of the 1980's. C# is a language designed to run on the hardware of the next two decades.

For this reason alone, I cannot recommend that any new project start from the ground up with an obsolete 32-bit language like Java. [Obviously existing projects may need to remain mired in an obsolete language, owing to the inertia of legacy code.]

Topic?

[nitehawk214]

Shouldn't this be under "Developers" not IT. Believe it or not, more then just it people use these two languages. Well, im not sure about C#, but I am certian about java.

Bias article?

[AstroDrabb]

I use both Java and C# professionally and this post smells of bias.

in my NSHO, the Java API has become bloated...

Huh? The Java 5 JRE download is 14 MB, while the .Net 1.1 runtime is 24MB. The Java 5 SDK download is 44MB while the .Net 1.1 SDK download is a whopping 109MB! Which one has bloat again? Java by far beats out C#/.Net as far as 3rd party modules goes. Anything you can think of programming, there is something available in Java. I cannot say the same yet about C#/.Net.

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

Does this guy know _anything_ about the Java community? The fortune 500 where I work had a few meetings trying to figure out which vendor we would use for our JAVA IDE. There was no choice with our C# IDE, it was just MS. For Java, we looked at IBM, Sun, BEA, JCreator, Eclipse, IntelliJ and Borland. If SUN died, we would still have _PLENTY_ of choice.

I like both Java and C# from a language perspective, however, working for a large company, I would recommend Java over MS's .Net. Java has been _very_ stable and _SECURE_ while the .Net security holes have already started at only version 1.1. We also appreciated the fact that we were able to switch our Java server apps to Linux over Solaris, we could even use MS Windows if we wanted to for our Java app servers; we don't have that same choice or luxury with MS .Net.

101 reasons why Java is better than dotNet

[Anonymous Coward]

this guy wrote an interesting list.

read the 101 reasons
here

Computer science = abstract + conquer!

[j.leidner]

since both languages are built to support OOP from the ground-up, their constructs become almost identical

Since the two languages have striking similarities, one wonders when people will begin to develop source code translators to shield problem-oriented developers from the idiosyncrac differences between the two languages.

For instance, ISI's STELLA is a LISP dialect which compiles to Common LISP, C++ and Java(R). Along the same line, it would be nice to have a compiler for a "JaC#" language that compiles to both, utilising tons of Java APIs and C#'s ability to do native compilation (I am aware there are portability limits, but I'd much rather be able to be confined to a common subset while able to easily move between the C++/Java/C# worlds than using obscure language features that others can't decipher anyway).

--
Try Nuggets , our mobile answer search engine. We answer your questions via SMS, across the UK.

Awesome stuff

[randymorin]

I'm still praying that Java survives.

Exceptions...

[r6144]

In C++ the decision whether or not to make use of exceptions is hard to make. If you don't use exceptions, the results of many function calls have to be checks, which is considerably more of a hassle than Java. If exceptions are used, writing exception-safe code is really quite limiting (It often means significantly more little objects when "new" can't be used freely, and much of the existing code have to be rewritten, and I hate comments like "func() can't throw, so this is safe"). Seems that an garbage-collecting language like Java/C# is very helpful if one want to use exceptions.

Re:Exceptions...

[Oestergaard]

No. Destructors make dynamic allocations safe, when you are using exceptions. Example:

void foo()
{
auto_ptr p(new my_big_class);
p->do_stuff();
p->do_more_stuff();
bar(p); // may throw exception
p->yet_more_stuff();
}

When foo() is exited, either when it completes, or because an exception is thrown in bar(), the auto_ptr destructor is called, and this will cause the dynamically allocated my_big_class object to be destroyed.

Simple, safe, and very very efficient.

typedefs of course can be used to make those awfully long names easier to type.

Re:Fair and Balanced

[slickwillie]

I guess you haven't seen this movie.

BTW, the article says something like "Then it doesn't matter if you code in C# or Java."

When did they port C# to Linux, BSD, OSX, VxWorks, Symbian, etc, etc?

Re:Java is a 32-bit language; C# is a 64-bit langu

[kaffiene]

Pure and utter FUD

from http://www.manageability.org/blog/stuff/why-cant-m icrosoft-deliver-64-bin-dotnet/view

Despite having a research and development budget that is almost 7 billion dollars a year, Microsoft apparently can't deliver .NET for 64-bit Windows 2003. Infoworld in a recent analysis explains:

The lack of a 64-bit implementation of the .Net Framework means that the hard work many Windows developers have put into migrating to the .Net development model is for naught on Windows on Itanium.
In the meantime, IT shops that wish to employ 64-bit Windows as an application server or Web services platform will be forced to revert to the older, Windows DNA (Distributed Internet Applications) environment.

In stark contrast, BEA Systems and Sun have been shipping JRockit and J2SE with Itanium support ever since JDK 1.4.1 was released. Furthermore, according to the reports 64-bit Opteron support is expected at the same time JDK 1.5 is released.

Ah, I see.

[Trejkaz]

So exactly like add*Listener and remove*Listener methods, just with different syntax.

Irrellevant

[kaffiene]

Those certifications do not prevent it being patent encumbered.

Vi for Eclipse

[Trejkaz]

There is a VIM Emulator Plugin for IntelliJ IDEA.

There is also a Vi Plugin for Eclipse.

Also, KDevelop has happily embedded KVim for ages now.

Is that enough?

C# vs Java vs Python vs whatever

[NullProg]

Java vs C# wars is like watching two fleas fight over who owns the dogs back. Or for the immature /. readers, Its watching two script kiddies fighting ownership over the same honeypot

I forget which movie thats from, but props to the person who wrote it.

Neither language is right or wrong. Both are subject to the whims of MS and Sun. Neither is ANSI so you will never see different vendors (Borland, Watcom, Lattice etc) compete. Neither language grows outside of the CPU scope of the chosen VM platform.

Answer one question to yourself. Will the language grow with me as the hardware changes? Will I have a job twenty years from now?

Enjoy

Innovations?

[descubes]

There is not enough innovation either in C# nor in Java, and what is there is often not implemented in the best possible way.

Generics (C# 2.0 already supports this)

Both Java and C# generic are quite limited, compared to C++ templates. And they are easier to use with expression reduction, since you can give them a nice-to-use form.

Enhanced For-Loop (the foreach construct in C# 1.0, duh!)

It is much better if you can define your own for loops, as in XL.

Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)

Autoboxing means you have boxing in the first place, which means your language doesn't support stack object. Nothing to be proud of. And _auto_boxing is only a form of implicit conversion. In XL, any implicit conversion can be implemented using expression reduction.

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)

Ooooh! Enums! Innovation!

Varargs (C# 1.0's params construct, ellipsis construct in C++)

Still no type-safe, instantiation based varargs.

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)

Yes. (XL had import aliasing for a while, see examples above...)

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)

What you really want is metaprogramming, to actually enhance the language as you go.

Re:Only Microsoft

[mcc]

Well, that is an API issue, not a language issue.

If you wish to address it as an issue with the Java API, the problem there is that it ignores the question of: if exceptions could be just ignored, what other changes to the Java API would be necessary in order to accommodate this? The API designers could no longer assume exceptions thrown by API methods would be caught. This would certainly have a serious impact on how the APIs are constructed and interfaced with.

Re:Obligatory

[cakoose]

That's a neat way of swapping around pluggable modules. However, there is still the problem of forcing the client programmer to be aware of the specific implementation dependencies in cases where things weren't designed to be modularly swapped out.

Not that any of that is relevant because Rob Pike's note on include files doesn't mention any of that stuff. He says that the problem is repeated inclusion of files. He also explicitly mentions that he is aware of include guards and his only stated objection is that they make the compilation take longer (which is not even neccessarily true; GCC uses a clever trick to detect the include guard pattern and avoid redundantly tokenizing files).

The C include system is fundamentally flawed and so even include guards have problems. But Rob Pike seemed to dismiss the technique outright, which is why he came off as a little bit of a weirdo.

Re:Java checked exceptions suck, but how to fix th

[Deef]

Folks, this really isn't that hard. If an exception is supposed to be impossible to trigger, then just propagate it to the caller like this:

try
{
doSomething();
}
catch (ImpossibleCheckedException ex)
{
throw new RuntimeException("This is impossible", ex);
}

Note the ",ex". That was added in JDK 1.4. It allows you to later retrieve the original exception from the "wrapping" exception.

With the above code, if the impossible exception actually occurs for some reason (because you made a coding error), the exception gets propagated up the call stack encased in a RuntimeException, which is unchecked. At the top of the call stack, you can, if you like, catch all the RuntimeExceptions, call their 'getCause()' methods to retrieve any possible ImpossibleExceptions or others stored within it, and do whatever you like with them (including rethrowing them). Or just print them out and exit, which is what is most commonly done.

In any case, please don't just catch and ignore an exception that you weren't expecting. This hides errors, and makes programs REALLY hard to debug later. If it's not supposed to ever happen, and it can't be propagated to the caller because it's a checked exception, then please catch it and throw a RuntimeException, AssertionError, UnsupportedOperationException, IllegalStateException, IllegalArgumentException, or whatever (all of which are unchecked) rather than silently hiding the error and pretending that nothing bad happened.

Re:Obligatory

[DrSkwid]

I think perhaps the modularity argument fell out of the new view of working with includes.

I don't think it add's much burden on the programmer in return for simplicity.

If you ship a new library you will list the dependencies in the docs / example file.

I've done quite a bit of programming in plan9 c which uses this particular method of inclusion and not run into any problems with it (not that my programming is a significant sample size).

In plan9 top level includes make porting to different architectures much simpler. Instead of a bunch of #ifdefs in the included files to decide what to do for each architecture, they use architecture appropriate headers. (at least I think I remember it that way, I don't have the source handy to check :)

Clever tricks, hmm. There's *always* a "cleverer" programmer.

I'm in the section that distrusts clever things :

Debugging is twice as hard as writing the code in the first place. Therefore,if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

-- Brian W. Kernighan

One Word

[The Grassy Knoll]

And that word is "DataGrid".

For web applications, it's a godsend. I know it's a horrible mung (look at the source it creates on a web page), but for ease of use and speed of development, it knocks JSP into a cocked hat.

Re:One Word

[LnxAddct]

Have you ever used JSP? or the JSTL tag libs? Or Java Servlets? Java is probably the best and most efficient way of doing 90% of web apps. And if you use third party software to help, such as Apache Struts, then there is no competition.
Regards,
Steve

The deciding factor - crap.

[DavidTurner]

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...

Crap.

C is the most successful language in history, and vendor support for it was fragmented at best. If you've got a good compiler, you understand the language and you have all the tools you need, who cares if the vendor goes under? Your assertion that the "longevity" of the vendor counts in the slightest has no substantive argument or evidence backing it up. Defend your position! Just because the store that sold me my deluxe high-powered all-in-one combo jigsaw/drill/planing tool has gone out of business doesn't mean that the tool is worthless, and that I should therefore use a hammer.

My position is this: when you're starting a project, you have several goals, with different relative importances. Often the primary goal is to get the job done quickly, in which case a so-called "scripting" [emotive and inaccurate term] language is your best choice. At other times interoperability with certain other products is more important, and that drives the choice of language. Sometimes speed counts. Choose your tools to fit the job!

Most of the time what I see in reality is programmers choosing languages not because of their technical merits, nor even necessarily because they're popular, but because they've had a lot of press. What kind of a criterion is that? How many of you (programmers) can honestly say you've mastered more than three languages? Speak up now. No? Then wouldn't it be fair to say that your toolbox is a little empty? And if that's the case, isn't it just maybe possible that you don't always use the best tool for the job?

Re:APIs

[mcbevin]

In a word - no.

XMLEncoder will never be useful for example for taking an existing XML schema and writing code to read/write to it. C#'s XML serialization/deserialization on the other hand is.

I'm also not referring to XPath - also nice but very limited as soon as you want to handle heirarchical data.

Re:Java is a 32-bit language; C# is a 64-bit langu

[Pieroxy]

Wow. Either you're a MS zealot, or greatly misinformed. Or both.

At my former company, we switched to JDK 1.4 and tried to run with the 64 bit JVM. Not one line of code (out of millions) had to change for the entire application to run as smooth as ever on the 64 bit JVM (Sun's one at least).

This is true because Java doesn't provide a way to mess with pointers. Pointers are an abstract concept and they don't convert to numbers as in C/C++. Hence the total transparency of switching to 64 bits.

The code you provided doesn't compile because arrays do define their length in integers, not in long. Hence, Java arrays are 32 bits.

Not a very big limitation, by any means, except of course for some very specific niche purposes. But most of them can be worked around trivially anyways.

And I am not even mentionning the fact that C# has yet to see its first 64 bits implementation.

IntelliJ IDEA!!!

[node159]

This is best refactoring IDE out there. Nuf said.

And I must concure, VS is about as functional as textpad, dono what the fuss is about, no clue for the clueless.

Ohh yeah, try IDEA!

http://www.jetbrains.com/idea/

Still not convinced?

http://home.iprimus.com.au/trinexus/idea.html

Its called compromise :)

[node159]

This is why marketing and eng's shouldn't mix :)

Any place for both of them ?

[dweeves]

It's too easy to give C# an advantage about what it adds to Java and forgetting it's a 95% Java clone.

Don't forget It took 7 years of Java and a Borland expert to produce C# !

During this time, Java did conquer most of the enterprise application development market and defined a technology model based on application servers handling component lifecycles.

C# as a language,has taken most of java state of the art paradigms and added some new features which are neat but, despite its huge base library is far from Java versatility and degree of maturity.

Java 1.5 advantages

• Language Features/Libraries:

• Server side Programming:
• Defined server side technology paradigms, with lots of implementors to handle them (open source and free ones are competing with the best commercial ones).

• Client Side Programming:
• Applets (which aren't dead technology if you know how to use them)
• Web Start

• IDE/Tools
• Eclipse (which is free and open)

• Management aspects
• Lots of available skilled developers
• Can run on any platform with a compliant JVM (if well coded)
• All big database vendors have JDBC drivers
• Mature technology

Java 1.5 Drawbacks

• Server Side:
• Web Service support are expensive to implement and non-standardized.
• Very poor JSF controls

• Client Side:
• Swing (but SWT / Eclipse rocks)

C# advantages

• Language Features:
• Benefits from the .Net Jitter.
• Events/Delegates model

• Client Side:
• Future Windows Development preferred language (along with XAML which is more about powerful UI macro-scripting)
• DirectX integration
• Speed (on Windows)

• Server Side
• ASP.Net Controls model

• IDE/Tools
• VS .Net (most productivity boosting IDE IMHO)

• Management aspects
• Still time to have plenty of Microsoft support if you have a interesting project.

C# drawbacks

• Language Features
• No Observable/Observer (but achievable through Events/Delegates)
• Serialization limitations

• Client Side
• No Windows independent GUI framework. (WebForms are server-based controls)
• No applets equivalent (don't event think about ActiveX)

• Server Side
• No detailed Infrastructural model, No best practices, No fine grained control.

• IDE/Tools
• No free IDEs compares to VS .Net and is really useable when you're used to commercial IDEs features. (Borland C# Builder CE is too restricted and not open source)

• Management aspects
• Young technology
• Not that much real experts available out of Microsoft
• Windows deployment only (Mono's out, but still work in progress ,can't be a professional choosen .NET deployment platform yet IMHO)

So, my conclusion is that by now, both technologies are interesting but Java is the most versatile.

I would prefer C# for:Windows Programming ,Attractive Web based interfaces (if an acceptable target platform is Mono or Windows), Porting existing windows applications to Web, Simple Self-Contained Web Services

I Would prefer Java for developing:Enterprise Applications,Complex Web Services,Highly interactive web interfaces (through applets),Multi OS client application.

For me, both languages are relevant, it's only a matter of what work has to be done and what resources are available to make it.Most of the time, technology is chosen based on a company resources capabilities!

Re:Sounds a lot like religion

[tijsvd]

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?

What has providing runtimes to do with being open? Quite a few commercial, closed applications are available for linux (Oracle anyone?), does that make them open?

Re:Common sense prevails again!

[Blitzenn]

Rating my post as flamebait when it is just praise for posting the article? I guess people didn't like that article much then did they? Why take your dislike of the article out on me? I was only stating that I thought it was fair!

Courage is not rewarded here, but squashed like a stinkbug into the carpet of unwantedness!

As Babbage might have said...

[gidds]

I am not able to rightly apprehend the kind of confusion of ideas that could provoke such an article!

Tuples? I Haven't Heard That in Years...

[LifesABeach]

I just had a Post Grad Flash Back 20 years ago of a class in the Tuple Calculas. At the time, for me, it would have been better named, "Set Theroy, Gone Bad".

I'm thinking there are several languages that can return a Tuple. "C" programmmers call it a "Structure". Object Oriented programmers refer to the rules of a "Object Returned", or "Get, and Set". My personal favorite is PERL's "my ( x, y, z ) = someFunctionResult;"

I see a time when there will only be one language that will be used. This new language will not come from the ones who give tribute to Redmond; Because it is not the way of the dwellers of Redmond. But from the morphing of our existing languages to a syntax that will be more easily understandable by both man, and machine.

Re:Tuples? I Haven't Heard That in Years...

[cakoose]

In programming languages, "tuple" usually means a record with anonymous fields that can be constructed on the fly. So Perl does have support for that (though things are a little different in dynamically typed languages because they don't even really have records in the first place).

In C, when you call functions, you are allowed to pass in tuples. That's why you can write:

// Declaration
void CopyChars(StringBuffer src, StringBuffer dst, int length);

// Invocation
CopyChars(buf1, buf2, 100);

Instead of:

// Declaration
struct CopyChars_Args {
StringBuffer src;
char* dst;
int length;
};
void CopyChars(CopyChars_Args args);

// Invocation
CopyChars_Args args = new CopyChars_Args();
args.src = buf1;
args.dst = buf2;
args.length = 100;
CopyChars(args);

Isn't that fun? Currently, this is what you have to for multiple return values.

You implied it

[SuperKendall]

Your original post proclaimed Java must declare exceptions, which is false.

No, it didn't even proclaim that. But, just for the sake of argument, let's say it did: if you tell me that you eat cookies, does that mean that you eat every cookie in existence?

Sorry, you implied it with the line:

C# does not force you to declare exceptions

What am I supposed to think you are saying?

If I am talking about Jim and Mary, and state "I like Jim and Mary, but Jim hates cookies" would you not at least assume that Mary has tolerance for them?

The problem with Java's declared exceptions is that libraries are full of exceptions you do have to declare, and those cause problems. That is, the existence of an exception declaration mechanism in the language is the problem.

An additional problem is that Java doesn't even type-check the declared exceptions it has correctly: something can throw java.io.IOException even though it doesn't declare it.

Let me correct you once more:

* Libraries full of exceptions you have to declare - false. Some libraries have exceptions (though not all) and they do not FORCE you to declare them. they force you to DEAL with them, which usually means catching and re-throwing, or catching and ignoring. In my case library exceptions are converted to runtime exceptions so I don't have to declare them at all. And that's what you should be doing anyway, as the points that are dealing with things like files are also the points where it's best to handle error conditions and convert the IO errors into some more semantically meaningful exception - which can be unchecked.

Note that some libraries do take an elightened approach to exceptions and use unchecked exceptions instead of checked (the Collections API, which C# has a weak copy of). As Collections are some of the most used classes, this reduces the burden for the common case.

* Something can throw java.io.IOException even though it doesn't declare it.

How would that happen? Give me some Java code that will compile and do exactly that.

If you say "throws" then you have to declare it throws that exception, unless of course its a runtime exception. So you get the best of both worlds in that you can use hard exceptions if you like, or use soft ones for larger systems where it makes sense (though I do think there is a place for checked exceptions at some API boundaries).

Re:You implied it

[jeif1k]

Sorry, you implied it with the line: "C# does not force you to declare exceptions" What am I supposed to think you are saying?

You are supposed to merely be reminded of a difference between the two; a few words like that are not inended as a comprehensive description of exception handling systems. What it points out is that C# never forces you to deal with exceptions, while Java sometimes does force you to deal with exceptions.

Some libraries have exceptions (though not all) and they do not FORCE you to declare them. they force you to DEAL with them, which usually means catching and re-throwing, or catching and ignoring.

You are right, that was somewhat sloppy writing; I think we both agree on the technical details, we just disagree on their implications.

"Something can throw java.io.IOException even though it doesn't declare it." How would that happen? Give me some Java code that will compile and do exactly that.

It happens when you compile against one version of a class but link against another; while the VM checks all other types at load time, it does not check exception signatures either at load time or even when an exception happens.

So you get the best of both worlds in that you can use hard exceptions if you like, or use soft ones for larger systems where it makes sense

Trouble is that I have to deal with checked exceptions in my code that other people decide to throw in their libraries. Worse, I have to live with the mistakes other people make when trying to deal with checked exceptions that they should simply have let alone. In any case, I think Java's checked exceptions by themselves are not enough to condemn the language; they are just one of a number of nagging technical problems with the language, some of them far more serious.

Half a dozen of one...

[SuperKendall]

Well, I was being a little pedantic but you're right we were generally in the same area.

I will say that the compiling against a class that does not throw an exception and linking against a version that does strikes me as unlikley!

You're right that checked exceptions are a tool that can be easily misused, especially since for a while so many people seemed fond of them. But I feat that .Net has it's own form of that in operator overloading support, from experience of what people do when they discover overloading I would say that prefer a little abuse of checked exceptions, which I can at least wrap and toss.

Java does have a few technical quirks but that's what comes of being a widley used platform! At some point you have to consider the benefit of helping support older platforms, which .Net has the luxury of ditching when moving forward. Myself I think it's quite handy that I cen develop code using generics and send the bytecode off to a device that has never even seen generics. I would like the reflective capabilities .Net offers, but I can see a pretty sound reason for choosing the path they have and the benefits are still pretty good.

Re:Only Microsoft

[GreyWizard]

So you shouldn't have checked exceptions because people might be dumb? [...] I could use the "people are dumb" argument to say that you should have checked exceptions as well.

No, one shouldn't have them because they complicate programming and provide no useful benefit in exchange. Someone *did* use the "people are dumb" argument to say checked exceptions are good. I was answering the claim that one could rely on throws clauses to document the exceptions a method might raise by pointing out that in practice those dumb people are too clever. Checked exceptions don't solve the problem. In context your reply is irrelevant.

Uh-huh. I haven't seen one that does this automatically for C#, it relies on the programmer to list them. Microsoft's own libraries have some documented exceptions that can be thrown but not all of them.

So? I made no claims about C# or any language other than Java. I said that the right way to ensure that exceptions get documented is to use an automated tool to collect that information without burdening programmers with busywork. Your comment does not address that.

Use a rapid prototyping language if that's what you want.

Rapid prototyping is important in any language. Sun agrees: see http://java.sun.com/docs/white/langenv/Intro.doc2. html for example. Nevertheless, I was not claiming that this is the only criteria by which a language should be judged. I was giving an example of one ways in which checked exceptions cause problems. Strict typechecking has disadvantages, but unlike checked exceptions it has advantages too.

if the new implementation you dropped in throws some random exception that I don't catch because I didn't know you could throw it,

Client code can use "catch (Exception e)" and have some default behavior for dealing with unanticipated exception types. This is the correct thing to do, because it gives library implementations maximum flexibility while still permitting exceptions to be caught and handled specially where necessary. Many times the interface implementation is effectively a callback mechanism for the client code, so they belong to the same codebase and there is no question about what exceptions can be thrown.

Nothing you've said can obscure the fact that checked exceptions offer no benefits but do impose substantial costs.

Re:Only Microsoft

[GreyWizard]

I've been using Java for five years and forcing checks on exceptions is my number 1 most favorite feature of Java.

All that proves is that you have bad taste. I expressed clear reasons why checked exceptions are a bad idea and all you can come back with is, "yeah, well I like them"? Whatever.

I currently monitor sixty developers, fyi.

I'm glad I'm not one of them. You don't seem terribly bright.

Re:Only Microsoft

[Gr8Apes]

That's what documentation is for. You do document your code, right? Besides, most of the API's I write tend to handle errors internally, or they're runtime errors. I find declared errors to be a pain for all involved and generally unnecessary. I do not seem to be alone in this viewpoint.

As for IntelliJ, I'm sure it's a good IDE, but I prefer Eclipse by far. (last time I used IntelliJ it was pretty clunky, although Eclipse 2.0 wasn't great either at that time....

Re:Only Microsoft

[Gr8Apes]

In what way is using undeclared exceptions even slightly similar to checking for nulls? One is design, the other is a naive or unskilled programmer's error.

C#'s "override" is a language construct necessary for C#, much like adding "final" to any java class you do not wish overridden. What exactly is your point? Neither of your topics relate in even the smallest way to "reliable" coding in my book, at least not as presented. (hint: it's not my job to make your point for you.)

Re:Only Microsoft

[Gr8Apes]

This is a laugh. I work with Java.

Checked exceptions are a compiler time check. Exactly how does using checked exceptions result in higher quality code than unchecked exceptions? I'll readily admit there's a lot more cruft in there, and god help you if you have to change the exception thrown, or add one, through all the layers.

I think this point has been relatively belabored by others. In short, checked exceptions look good in theory by immediately letting you know that there's an exception. The above statement about maintenance is a major negative.

I also feel checked exceptions actually hurts the novice/intermediate programmer in that now they'll never have to think, or read the actual documentation, because things are spelled out for them. It reminds me of using a calculator in first grade. What's 1 + 1? ... (Not that I believe using unchecked exceptions automatically forces coders to learn what they're coding, but at least it'll be easier to weed out the smarter ones from those that should be sent elsewhere)

Re:Only Microsoft

[ultranova]

The API designers could no longer assume exceptions thrown by API methods would be caught. This would certainly have a serious impact on how the APIs are constructed and interfaced with.

Um, why ? Either the exception is caught at some level, in which case the application does something predictable (handles the error), or it goes all the way up, in which case the application does something predictable (it exits). You can already do this just by declaring every method in every class as throwing "Exception" (or maybe even "Throwable" :). All you'd need to do was make this the default case, just like extending "Object" is the default case.

Given what the java API does

[mcc]

The API designers have special obligations that other programmers don't. The program exiting may be something that developers would consider "predictable", but the end users would NOT.

Swing interfaces

[ChunderDownunder]

And what pray tell do you use to populate a JTable (or equivalent) in Java? A Vector of row data and a Vector of column names.

Or, you could populate it using models.

Most have abstract implementations that only require that you specify the data; providing event support for you.