Java 1.5 vs C#

I code C# for a living by carpe_noctem · 2004-10-11 04:36 · Score: 4, Insightful

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

--
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K

Re:I code C# for a living by danheskett · 2004-10-11 04:38 · Score: 1

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 by carpe_noctem · 2004-10-11 04:45 · Score: 4, Interesting

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

--
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Re:I code C# for a living by Westley · 2004-10-11 05:01 · Score: 4, Insightful

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 by LnxAddct · 2004-10-11 05:13 · Score: 5, Interesting

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 by Anonymous Coward · 2004-10-11 05:19 · Score: 0

Maybe I just don't grok OO design, but the whole language is really abstract.
That's proof you don't :) Seriously, if you want to learn about it, look for books on design patterns, and do some pair-programming with an experienced OO dev. Language unimportant, as long as it's OO. After a while, things that took hours will be faster than in other languages because you'll understand the conventions used by others in APIs.
Re:I code C# for a living by spacecowboy420 · 2004-10-11 05:22 · Score: 1, Insightful

Thread is over, 'nuff said.

--
ymmv
Re:I code C# for a living by Anonymous Coward · 2004-10-11 05:39 · Score: 0, Redundant

I also code both Java and C# and agree with you 100%. I don't understand why people like VS.Net. It pales in comparison to Eclipse and other IDE's. There is simply better tools available for Java. In a few years .Net/C# may be comparable in tools support, but it certainly isn't right now.
Re:I code C# for a living by Anonymous Coward · 2004-10-11 05:42 · Score: 0

Shouldn't this be in the developers section?
Re:I code C# for a living by CaptnMArk · 2004-10-11 05:55 · Score: 2, Informative

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 by fitten · 2004-10-11 06:04 · Score: 2, Insightful

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 by gooser23 · 2004-10-11 06:13 · Score: 3, Informative

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.

--
"Dying tickles!" -- Ralph Wiggum
Re:I code C# for a living by iezhy · 2004-10-11 06:13 · Score: 3, Informative

Java has checked exceptions

exception management in c# is so painful without them
Re:I code C# for a living by Bloater · 2004-10-11 06:23 · Score: 1, Funny

> 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 by Anonymous Coward · 2004-10-11 06:29 · Score: 0

Delegates are a mis-feature imo. But maybe that's just me.
What are these events you're talking about, btw? Some concurrency thing?
Re:I code C# for a living by WebfishUK · 2004-10-11 06:33 · Score: 2, Insightful

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.

--
-- "Can't sleep, clowns will eat me!"
Re:I code C# for a living by swilver · 2004-10-11 06:40 · Score: 5, Informative

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 by rnd() · 2004-10-11 06:46 · Score: 1

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

--
Amazing magic tricks
Re:I code C# for a living by Three+Headed+Man · 2004-10-11 06:46 · Score: 3, Funny

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

--
I'm probably at the karma cap. Mod up a funny troll instead, it lightens the mood :)
Re:I code C# for a living by fitten · 2004-10-11 06:49 · Score: 1

Why do you think delegates are a mis-feature?
Re:I code C# for a living by shatfield · 2004-10-11 06:52 · Score: 2, Insightful

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.

--
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
Re:I code C# for a living by Westley · 2004-10-11 07:02 · Score: 1

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 by Anonymous Coward · 2004-10-11 07:03 · Score: 0

For me, it is the intermitant crashing and freezing of VS.NET. And the completely unstable build and applying of code changes during debugging in VS,NET.

I find the only reliable way to make changes to code in VS,NET is to do a clean solution and rebuild solution everytime. Otherwise, the results are completely unpredictable.
Re:I code C# for a living by MrScience · 2004-10-11 07:15 · Score: 1

But it does need some
tags...

--
You quitting proves that the karma kap worked. The most annoying of the whores shut up. --CmdrTaco
Re:I code C# for a living by cakoose · 2004-10-11 07:15 · Score: 5, Informative

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 by cduffy · 2004-10-11 07:24 · Score: 1

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 by rnd() · 2004-10-11 07:39 · Score: 1

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.

--
Amazing magic tricks
Re:I code C# for a living by tyrione · 2004-10-11 07:39 · Score: 1

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 by IIEFreeMan · 2004-10-11 07:58 · Score: 1

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 by Anonymous Coward · 2004-10-11 07:59 · Score: 0

Because it deletes Gates ;)
Why Java has not uint (i.e. for DLX simulator)?
open4free ©
Re:I code C# for a living by SnprBoB86 · 2004-10-11 09:17 · Score: 2, Insightful

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

--
http://brandonbloom.name
Re:I code C# for a living by GCP · 2004-10-11 09:50 · Score: 4, Insightful

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

--
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Re:I code C# for a living by Anonymous Coward · 2004-10-11 09:54 · Score: 0

SharpDevelop has crashed more on my machine than Visual Studio. In fact, the number of times VS has crashed for me is exactly zero. Not to mention SharpDevelop doesn't do intellisense as well as VS does.

IMO, VS's only obvious flaw is that it's so slow and memory hungry (it's not slow once it's moving, but it takes a goddamn long time to GET moving).
Re:I code C# for a living by Anonymous Coward · 2004-10-11 09:55 · Score: 0

There is a C# plugin for eclipse:

http://www.improve-technologies.com/alpha/esharp/
Re:I code C# for a living by panaceaa · 2004-10-11 11:21 · Score: 1

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

--
my blog
Re:I code C# for a living by Warhaven · 2004-10-11 11:36 · Score: 1

...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 by angel'o'sphere · 2004-10-11 11:51 · Score: 4, Informative

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:I code C# for a living by Anonymous Coward · 2004-10-11 12:04 · Score: 0

Suppose you have:
A --> Generic<A> ^ | | B --> Generic<B>
So B is a subtype of A, and Generic is some generic that can take either A or B as a type parameter. The question is which way should the arrow go between Generic<A> and Generic<B>. If the arrow is in the same direction as the one for A and B then you have covariance, and if the arrow is reversed then you have contravariance. In other words, if Generic<A> is a subtype of Generic<B> then you contravariance, and the other way around you have covariance.
Re:I code C# for a living by cakoose · 2004-10-11 12:07 · Score: 1

"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 by CanadianCrackPot · 2004-10-11 12:15 · Score: 1

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

--
Good programmers drink beer to relieve job stress.
Great programmers drink hard liquor and work best hungover.
Re:I code C# for a living by Anonymous Coward · 2004-10-11 12:40 · Score: 0

I'll use an IDE when vim is built in. This shouldn't be tough for Eclipse or one of the other open source ides, but I haven't gotten around to trying it. Until then, other than gui crafting, no IDE is good enough and every IDE is not good enough.
Re:I code C# for a living by SlightOverdose · 2004-10-11 12:48 · Score: 1

Personally I can't stand checked exceptions, but to each his own.
Re:I code C# for a living by elgaard · 2004-10-11 13:21 · Score: 2, Informative

>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 by GCP · 2004-10-11 13:26 · Score: 1

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

--
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Re:I code C# for a living by k8to · 2004-10-11 14:56 · Score: 2, Funny

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

--
-josh
Re:I code C# for a living by Anonymous Coward · 2004-10-11 15:02 · Score: 1, Insightful

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 by kaffiene · 2004-10-11 15:09 · Score: 2, Insightful

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 by Anonymous Coward · 2004-10-11 15:09 · Score: 0

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.
One thing, however, Java DOES have going for it, are dynamic languages designed to be running on JVM: specifically Groovy. Since Java programmers have learnt to make decent use of automatic code generation, there's lots more dynamicism to come from those projects, instead of core language. And while it'd be good if JVM supported few more things, I'm not sure lack of such support is (at this point) impediment to further progress.
I fully agree in that delegates are perhaps the single biggest improvements C# offers over Java.
But in the end, it all comes down to this: will there be non-Microsoft implementations of CLR and C#. If there will, it has a chance at overthrowing Java; if not, it will not. At least on server-side , that is THE question Microsoft has to consider. Should they try to allow or even create competition: lose some control, but gain bigger following... or do what Apple did with MacOS.
Re:I code C# for a living by Trejkaz · 2004-10-11 15:31 · Score: 1

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.

--
Karma: It's all a bunch of tree-huggin' hippy crap!
Re:I code C# for a living by Anonymous Coward · 2004-10-11 16:05 · Score: 0

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.

Not correct! C# requires you to specifically match delegate types - inheritance does not come into play. So for example myfunc could be used by a delegate like:

delegate void MyObjectReceivingVoidReturningDelegate(object o);

and you could have:

delegate void OnActionDelegate(ActionEvent ae);

You could then do:

OnActionDelegate oad = new OnActionDelegate(this.ActionPreformed);
MyObjectR eceivingVoidReturningDelegate morvrd = new MyObjectReceivingVoidReturningDelegate(this.myfunc );

but you could not do:

MyObjectReceivingVoidReturningDelegate morvrd = new MyObjectReceivingVoidReturningDelegate(this.Action Performed);

OnActionDelegate oad = new OnActionDelegate(this.myfunc);

So it's not as bad as you'd make it out to be. The nice thing you'll notice though is that whenever a delegate is used it always involves the construction of the delegate - so it's not so hard to find if something's being used (findstr /s OnActionDelegate *.cs | findstr ActionPerformed - I leave the grep version as an exercise for the reader :) ).

On the downside (and you may just not care :) ) in C# 2.0 you're no longer required to construct the delegate - C# will do it for you automagically.

For example:

Thread t = new Thread(this.MyThreadStart);

is legal where you used to need to do:

Thread t = new Thread(new ThreadStart(this.MyThreadStart));

And this brings us to the point where delegates really shine: Delegates allow one class to have multiple handlers for a single delegate. Imagine a click event - you could have up, down, drag start, drag end, double click, etc... different handlers that are all "click events". This could require many different classes (DragStartObj, MouseDownObj, etc...) or you could have a bunch of functions (OnMouseDown, OnMouseUp) on a single class that is handling all the events.

So in summary it's not as bad as you make it out to be, but it is getting worse as far as your argument is concerned, but still, like all programming constructs, there are legitimate uses for it that improve the development process. And if it needs to be said, yeah, people can abuse it too.
Re:I code C# for a living by Anonymous Coward · 2004-10-11 16:19 · Score: 0

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

I think you're right and wrong. Microsoft liked Java. There's a reason Microsoft embraced Java. But it wasn't enough, and they wanted to extend it to make it adequate. If Sun hadn't sued them we'd probably see a lot of MS's energy directed towards Java. Maybe we'd have Caffinated VB, and C++/J, and other attempts to push Java in new and strange directions... But no, Sun wanted their $2 billion dollars...
Re:I code C# for a living by Anonymous Coward · 2004-10-11 16:47 · Score: 0

I see the Microsoft employees are out in force tonight :-)
Re:I code C# for a living by rtayek · 2004-10-11 16:58 · Score: 1

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

--
vice chair orange county java users group (ocjug.org).
Re:I code C# for a living by maxwell+demon · 2004-10-11 20:46 · Score: 1

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.

--
The Tao of math: The numbers you can count are not the real numbers.
Re:I code C# for a living by maxwell+demon · 2004-10-11 21:26 · Score: 1

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.

--
The Tao of math: The numbers you can count are not the real numbers.
Re:I code C# for a living by kaffiene · 2004-10-11 22:23 · Score: 1

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 by fitten · 2004-10-12 02:13 · Score: 1

It was an honest question.
Re:I code C# for a living by SnprBoB86 · 2004-10-12 02:45 · Score: 1

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.

--
http://brandonbloom.name
Re:I code C# for a living by cakoose · 2004-10-12 05:39 · Score: 1

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 by rnd() · 2004-10-12 09:25 · Score: 1

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

--
Amazing magic tricks
Re:I code C# for a living by jenesuispasgoth · 2004-10-12 10:29 · Score: 1

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 by jenesuispasgoth · 2004-10-12 10:34 · Score: 1

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 by cakoose · 2004-10-12 14:40 · Score: 1

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 by cakoose · 2004-10-12 15:23 · Score: 1

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 by Anonymous Coward · 2004-10-12 16:17 · Score: 0

I'll second that... IntelliJ IDEA isn't just the best IDE out there... it completely obliterates anything and everything (Eclipse included). Absolutely the finest IDE I've ever used.
Re:I code C# for a living by kaffiene · 2004-10-12 16:39 · Score: 1

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 by kaffiene · 2004-10-12 16:45 · Score: 1

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 by maxwell+demon · 2004-10-12 19:25 · Score: 1

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

--
The Tao of math: The numbers you can count are not the real numbers.
Re:I code C# for a living by Anonymous Coward · 2004-10-13 00:59 · Score: 0

Writing a wrapper function for every function in the math library is hardly a "couple of extra characters".
Re:I code C# for a living by hotpotato · 2004-10-13 08:39 · Score: 1

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 by cakoose · 2004-10-13 09:09 · Score: 1

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 by cakoose · 2004-10-13 09:38 · Score: 1

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 by Anonymous Coward · 2004-10-14 12:11 · Score: 0

...but you can still use interfaces in C#.

I have to disagree with properties. For 9/10 instances, being able to do:

X := MyProp;
MyProp := y;

where MyProp is defined as:
property MyProp: integer read getMyProp write setMyProp; (sorry, Delphi-ish syntax)

just makes for better code style.
Re:I code C# for a living by carpus · 2004-10-21 09:12 · Score: 1

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 by Westley · 2004-10-21 10:01 · Score: 1

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 by carpus · 2004-10-22 06:52 · Score: 1

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 by Westley · 2004-10-22 07:05 · Score: 1

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 by carpus · 2004-10-22 08:38 · Score: 1

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 by Westley · 2004-10-22 10:55 · Score: 1

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 by carpus · 2004-10-23 01:08 · Score: 1

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 by Westley · 2004-10-23 03:25 · Score: 1

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 by carpus · 2004-10-23 05:19 · Score: 1

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 by Westley · 2004-10-23 05:33 · Score: 1

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 by carpus · 2004-10-23 11:58 · Score: 1

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

supported overtime? by gregarican · 2004-10-11 04:36 · Score: 0, Offtopic

Does this mean the code developers get paid for working overtime?

Varargs? by American+AC+in+Paris · 2004-10-11 04:37 · Score: 5, Funny

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

--

Obliteracy: Words with explosions

Re:Varargs? by Anonymous Coward · 2004-10-11 05:14 · Score: 1, Informative

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? by worst_name_ever · 2004-10-11 05:34 · Score: 1

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

--

In Soviet Rush, today's Tom Sawyer gets high on you.
Re:Varargs? by Anonymous Coward · 2004-10-11 06:09 · Score: 1, Funny

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 by Doc+Ruby · 2004-10-11 04:37 · Score: 5, Interesting

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?

--

--
make install -not war

Re:All in it together by pjt33 · 2004-10-11 04:41 · Score: 1

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 by Anonymous Coward · 2004-10-11 04:43 · Score: 0

OK well now you want too much ;)
Re:All in it together by Gherald · 2004-10-11 04:44 · Score: 2, Funny

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

--
The unofficial /. digest
Re:All in it together by Cannelbrae · 2004-10-11 04:46 · Score: 2, Funny

Quick, someone email Bill. Slashdot wants Java.NET. ;)
Re:All in it together by databyss · 2004-10-11 04:48 · Score: 1

Isn't that what we have J# for?

--
Hmmm witty sig or funny sig? Maybe elitest techy sig!
Re:All in it together by arkanes · 2004-10-11 04:52 · Score: 1

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 by jungd · 2004-10-11 04:52 · Score: 4, Informative

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

--
/..sig file not found - permission denied.
Re:All in it together by carpe_noctem · 2004-10-11 04:52 · Score: 1

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

--
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Re:All in it together by counterplex · 2004-10-11 04:59 · Score: 0, Offtopic

Best.. sig.. in a long time!

--
$x = ($x * 10) % 10 >= 5 ? 1 + int $x : int $x
Re:All in it together by VertigoAce · 2004-10-11 05:02 · Score: 5, Interesting

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 by PhrostyMcByte · 2004-10-11 05:05 · Score: 1

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 by mortenmo · 2004-10-11 05:07 · Score: 4, Informative

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 by bobbozzo · 2004-10-11 05:29 · Score: 1

Still no multiple inheritance in Java?

Does/will C# have it?

--
Nothing to see here; Move along.
Re:All in it together by achacha · 2004-10-11 05:54 · Score: 2, Interesting

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 by Doc+Ruby · 2004-10-11 06:03 · Score: 1

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?

--
--
make install -not war
Re:All in it together by Corngood · 2004-10-11 06:05 · Score: 2, Insightful

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 by Fnkmaster · 2004-10-11 06:21 · Score: 2, Insightful

Yes, but are you sure it's stepping you in the right direction?
Re:All in it together by Anonymous Coward · 2004-10-11 06:30 · Score: 0

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

I think he was referring to the "dreaded diamond" problem.
Re:All in it together by blowdart · 2004-10-11 06:39 · Score: 1

C# does not have it. For 75% of circumstances using multiple interfaces does the same trick anyway.
Re:All in it together by Anonymous Coward · 2004-10-11 06:53 · Score: 0

Yeah right.

What *exactly* do you mean by "circular inheritance"?

Have you even familiarized yourself with the arguments for MI, or are you just quoting from some CS101 notes?

Lastly, are you implying that Stroustrup and van Rossum didn't know what they were doing?
Re:All in it together by fitten · 2004-10-11 07:03 · Score: 2, Informative

Interfaces are your friends. Most of what people use multiple inheritance for can be achieved by using multiple interfaces.
Re:All in it together by aminorex · 2004-10-11 07:12 · Score: 1

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.

--
-I like my women like I like my tea: green-
Re:All in it together by Anonymous Coward · 2004-10-11 07:18 · Score: 1, Informative

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 by pjt33 · 2004-10-11 07:23 · Score: 1

Too late: Sun already has it.
Re:All in it together by DerWulf · 2004-10-11 10:13 · Score: 1

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

--

___
No power in the 'verse can stop me
Re:All in it together by Nautica · 2004-10-11 10:35 · Score: 1

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 by pjt33 · 2004-10-11 10:52 · Score: 1

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 by infinidim · 2004-10-11 11:08 · Score: 1

A interesting explanation is here.
Re:All in it together by kubrick · 2004-10-11 11:32 · Score: 1

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

--
deus does not exist but if he does
Re:All in it together by kaffiene · 2004-10-11 15:19 · Score: 1

I've used it.

I can tell you it does *not* work well.
Re:All in it together by Greg+Newton · 2004-10-11 16:02 · Score: 1

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

--
---- Backwards compatible -- If it's not backwards it's not compatible
Re:All in it together by pnatural · 2004-10-12 05:34 · Score: 1

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 by achacha · 2004-10-17 14:44 · Score: 1

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 by DerWulf · 2004-10-17 22:28 · Score: 1

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.

--

___
No power in the 'verse can stop me
Re:All in it together by achacha · 2004-10-18 08:50 · Score: 1

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 by eissimuf · 2004-10-11 04:37 · Score: 2, Informative

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 by eissimuf · 2004-10-11 04:40 · Score: 2, Informative

omg, it hates me... trying one last time Java 1.5
Re:Fix the link by AKAImBatman · 2004-10-11 04:41 · Score: 2, Funny

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)

--
Javascript + Nintendo DSi = DSiCade
Re:Fix the link by Fenresulven · 2004-10-11 04:42 · Score: 1

Like this you mean?

I'm confused by abrotman · 2004-10-11 04:38 · Score: 4, Insightful

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

Re:I'm confused by Tim+C · 2004-10-11 09:56 · Score: 1

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

--
It's official. Most of you are morons.
Re:I'm confused by Anonymous Coward · 2004-10-12 01:46 · Score: 0

the REAL (and only) news apart from the author being an idiot (which is hardly news) is that slashdot publishes something that shows a preference for a Microsoft tool over anything else :)

Learn to write? by Palshife · 2004-10-11 04:38 · Score: 5, Funny

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

--
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!

Re:Learn to write? by American+AC+in+Paris · 2004-10-11 04:46 · Score: 5, Funny

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

--
Obliteracy: Words with explosions
Re:Learn to write? by Otter · 2004-10-11 04:50 · Score: 1

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.

--
What I'm listening to now on Pandora...
Re:Learn to write? by Palshife · 2004-10-11 04:53 · Score: 1

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()!

--
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
Re:Learn to write? by Tumbleweed · 2004-10-11 05:12 · Score: 2, Funny

I'd love to see his version of Hello World. :)
Re:Learn to write? by mog007 · 2004-10-11 05:50 · Score: 2, Funny

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

--
Learn something new.
Re:Learn to write? by roror · 2004-10-11 07:27 · Score: 1

that would surely be

Hell World.
Re:Learn to write? by Hell+O'World · 2004-10-11 08:41 · Score: 1

You rang?
Re:Learn to write? by Anonymous Coward · 2004-10-11 14:49 · Score: 0

> I've never seen so many grammatical errors. You win.
The topic is: C# vs Java 1.5 - not English 101. Dumbass!

what about... by syrinx · 2004-10-11 04:38 · Score: 4, Funny

and you're foundations in OOP is rock-solid

What about our foundations in English?

--
Quidquid latine dictum sit, altum sonatur.

Re:what about... by JDevers · 2004-10-11 04:42 · Score: 1

What about this one too?

"since both language is built to support"
Re:what about... by yoyhed · 2004-10-11 04:44 · Score: 3, Funny

You missed another:
and you're foundations in OOP is rock-solid
Come on, people. Conjugate.

--
WHO NEEDS SHIFT WHEN YOU HAVE CAPSLOCK/ DAMN1
Re:what about... by dAzED1 · 2004-10-11 04:55 · Score: 1

they changed that..."both languages are" now.
Re:what about... by syrinx · 2004-10-11 08:58 · Score: 0

yeah, I noticed that one after I posted.

Why do we even have editors, if they don't edit?

--
Quidquid latine dictum sit, altum sonatur.

flamebait by Bert690 · 2004-10-11 04:38 · Score: 4, Insightful

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 by oniony · 2004-10-11 04:45 · Score: 3, Interesting

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

--
Powered by onion juice.
Re:flamebait by Anonymous Coward · 2004-10-11 04:49 · Score: 1, Insightful

What's a better java debugger for large applications?
Re:flamebait by jasonshortphd · 2004-10-11 04:52 · Score: 0

Yes, we do all the time. Why?
I don't get the Java naming convention. Why the complication.
C# 1.1, I know that that came after 1.0.
Java 2, SDK 1.5 what is that? Is it version 2 or NOT?
Java is a fine language, but I hate their naming conventions!!!!

--

Do not stare at the sun. It might hurt your eyes.
Re:flamebait by That's+Unpossible! · 2004-10-11 05:09 · Score: 1

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.

--
Ironically, the word ironically is often used incorrectly.
Re:flamebait by micromoog · 2004-10-11 05:09 · Score: 1

Large applications written in Java don't have bugs.
Re:flamebait by Anonymous Coward · 2004-10-11 05:22 · Score: 0

flamebait? This is what a serious question gets? So much for open source I guess.
Re:flamebait by 33degrees · 2004-10-11 05:33 · Score: 1, Interesting

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 by Anonymous Coward · 2004-10-11 05:47 · Score: 0

Every program has at least one bug.
Re:flamebait by p2sam · 2004-10-11 05:50 · Score: 1

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 by Anonymous Coward · 2004-10-11 05:51 · Score: 0

Except for one great bug glaring bug: Java itself.
Re:flamebait by jeif1k · 2004-10-11 05:58 · Score: 4, Informative

.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 by Anonymous Coward · 2004-10-11 06:10 · Score: 0

An experienced developer.
Re:flamebait by cablepokerface · 2004-10-11 06:15 · Score: 1

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 by mrogers · 2004-10-11 06:26 · Score: 4, Funny

Large applications written in Java are bugs. ;-p
Re:flamebait by ecotax · 2004-10-11 06:27 · Score: 1

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

Java2005
Java XP

--
"Money is a sign of poverty." - Iain Banks
Re:flamebait by Fnkmaster · 2004-10-11 06:28 · Score: 2, Informative

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 by Anonymous Coward · 2004-10-11 07:05 · Score: 0

(Visual Studio debugger on a large application, anyone?)

Hell, no. Not after that time when the VS.NET debugger repeatedly stepped into both the if and the else clauses in an if-statement! Or how about the time when a variable spontaneously became null, one line into an if(var!=null) block...
More value for your money, the M$ way...
Re:flamebait by aminorex · 2004-10-11 07:17 · Score: 1

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.

--
-I like my women like I like my tea: green-
Re:flamebait by cakoose · 2004-10-11 07:25 · Score: 1

And how many more job openings are there for Java than there are for PHP?
Re:flamebait by Yoda's+Mum · 2004-10-11 08:17 · Score: 1

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 by Tim+C · 2004-10-11 10:41 · Score: 1

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.

--
It's official. Most of you are morons.
Re:flamebait by Anonymous Coward · 2004-10-11 10:54 · Score: 0

So, what debugger do you use? which was the point of the question.
Re:flamebait by mabinogi · 2004-10-11 12:27 · Score: 2, Interesting

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

--
Advanced users are users too!
Re:flamebait by 33degrees · 2004-10-11 12:49 · Score: 1

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 by BlackStar · 2004-10-11 14:33 · Score: 1

*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 by kaffiene · 2004-10-11 15:22 · Score: 2

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 by Anonymous Coward · 2004-10-11 16:05 · Score: 0

I write C# code for a living working on a large application (100k+ lines of code). I just have to say that the VS debugger is amazing and has never failed me. If you want to complain about Visual studio I think you should have picked a better feature to rag on. For example, ASP.NET page design view tends to break syntax highlighting, code-completion and undo. The debugger rocks though. (Heck, if you're running MS SQL Server, you can even debug your stored procs).
Re:flamebait by Trejkaz · 2004-10-11 16:17 · Score: 1

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!

--
Karma: It's all a bunch of tree-huggin' hippy crap!
Re:flamebait by Anonymous Coward · 2004-10-11 17:48 · Score: 0

I've seen better trolls the this in comp.os.linux.advocacy!
What were the editors thinging when the let this one thru?
Re:flamebait by Anonymous Coward · 2004-10-11 23:07 · Score: 0

> And Sun even have libraries like JDNC and JDIC

ROTFL!

(oops, getting back on-topic)
Re:flamebait by goonerw · 2004-10-16 13:04 · Score: 1

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

--
LOAD ".SIG"
PRESS PLAY ON TAPE
Re:flamebait by kaffiene · 2004-10-17 18:03 · Score: 1

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 by goonerw · 2004-10-17 21:32 · Score: 1

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?

--
LOAD ".SIG"
PRESS PLAY ON TAPE
Re:flamebait by kaffiene · 2004-10-17 22:06 · Score: 1

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 by JUSTONEMORELATTE · 2004-10-11 04:40 · Score: 4, Insightful

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

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

Re:Cue the zealots on both sides by Anonymous Coward · 2004-10-11 05:53 · Score: 0

"Insightful"?... I do not think that word means what you think it means.
Re:Cue the zealots on both sides by markiii · 2004-10-11 06:08 · Score: 1

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!

If sun dies... by johansalk · 2004-10-11 04:41 · Score: 0, Offtopic

IBM will then pick it up... it's so clear.

Re:If sun dies... by fitten · 2004-10-11 04:43 · Score: 1

Actually... whoever buys the remnants of Sun will "pick it up" and do whatever they want with it.
Re:If sun dies... by Anonymous+Writer · 2004-10-11 05:02 · Score: 1

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

Or perhaps Kodak will.
Re:If sun dies... by cpghost · 2004-10-11 05:34 · Score: 1

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); }

--
cpghost at Cordula's Web.

Java 1.5 vs c# 2.0? by hpj · 2004-10-11 04:41 · Score: 5, Informative

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? by PhrostyMcByte · 2004-10-11 05:00 · Score: 0, Flamebait

C# 2.0 has a working implementation in Visual Studio Express and its generics are more than the syntax sugar Java gives you.
Re:Java 1.5 vs c# 2.0? by codepunk · 2004-10-11 05:03 · Score: 1

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

--

Got Code?
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 05:05 · Score: 0

Generics in Java and C#
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 05:05 · Score: 4, Insightful

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? by winfx · 2004-10-11 05:07 · Score: 1

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? by Anonymous Coward · 2004-10-11 05:22 · Score: 0

Purchase?

http://lab.msdn.microsoft.com/express/

Geez, I hate sun trolls ;]
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 05:26 · Score: 0

At least C# is an open standard...
Re:Java 1.5 vs c# 2.0? by 3770 · 2004-10-11 05:28 · Score: 0, Troll

The beta is free but they have said that they will charge money for the final product.

--
The Internet is full. Go Away!!!
Re:Java 1.5 vs c# 2.0? by traskjd · 2004-10-11 05:37 · Score: 1

.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

--
My blog [.net, rants, general IT]
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 05:50 · Score: 0

Mainly because of it's lack of support for generic classes which Java now supports

That's not generics, that's autocasting.
Re:Java 1.5 vs c# 2.0? by mrtrumbe · 2004-10-11 06:13 · Score: 1

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? by mentin · 2004-10-11 06:34 · Score: 1

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.

--
MSDOS: 20+ years without remote hole in the default install
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 06:35 · Score: 0

Java was ahead until they added Generics.

Adding yucky/lowvalue/error prone features to a language is not getting ahead, otherwise people would have never moved away from C++!
Re:Java 1.5 vs c# 2.0? by PierceLabs · 2004-10-11 06:42 · Score: 1

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? by swilver · 2004-10-11 06:55 · Score: 4, Insightful

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? by traskjd · 2004-10-11 06:58 · Score: 1

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

--
My blog [.net, rants, general IT]
Re:Java 1.5 vs c# 2.0? by AaronGTurner · 2004-10-11 07:25 · Score: 1

HTML doesn't run anywhere, it is simply a document type.
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 07:27 · Score: 0

It is a bit unfair because they are supposed to be different languages and what not but because a lot of people believe these features only made it into Java because of C#.

I think I am going to have to disagree with you on Java being ahead. Java's new features are too syntactic- namely Generics. Generic support is all done at compile time thus there is no support for it at runtime. Try using instanceof with Generics to see what I am talking about. Autoboxing is just more syntatic too, slightly more acceptable but plenty of people are sure to not understand what is going on there. As for enums and varargs I do not understand why they were needed- I suspect un-educated programmers. The only half interesting feature seems be meta-data only because I do not understand it yet and a lot smart people seem to like it- it is possible that it too is dog shit.
Re:Java 1.5 vs c# 2.0? by AaronGTurner · 2004-10-11 07:27 · Score: 1

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? by cakoose · 2004-10-11 07:45 · Score: 1

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? by cakoose · 2004-10-11 07:54 · Score: 1

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? by jeif1k · 2004-10-11 08:04 · Score: 2, Informative

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? by ClosedSource · 2004-10-11 10:37 · Score: 1

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? by Warhaven · 2004-10-11 11:52 · Score: 1

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? by mentin · 2004-10-11 11:55 · Score: 1

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.

--
MSDOS: 20+ years without remote hole in the default install
Re:Java 1.5 vs c# 2.0? by Anonymous Coward · 2004-10-11 16:49 · Score: 0

Just to give a potential concrete example of where this can be bad. Let's say you have code that's making a security decision based upon a call to equals. If you can inject an object that has an implementation of equals that inspects the corresponding object, and returns true for the object with highest privlegde.

Bam! You've circumvented the security system!

You can definitely code definsively here to prevent attacks like these, but having a bunch of language-magic that doesn't hold up in the VM may cause this to be a security problem for Java programs down the line - especially if having code loaded at multiple trust levels in the VM continues to become more used. (I apolgize for the paragrpah-sentence in advance, sorry, editing skills are temporarily unavailable).
Re:Java 1.5 vs c# 2.0? by Da+Fokka · 2004-10-13 02:30 · Score: 1

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 by gregarican · 2004-10-11 04:41 · Score: 1

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

Re:Hey by Majik+Sznak · 2004-10-11 06:23 · Score: 1

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

--
Karma: Chameleon (Mostly affected by the 1980s)
Re:Hey by Anonymous Coward · 2004-10-11 09:28 · Score: 0

Thank you Mr. Can't-See-a-Joke-if-it-Slapped-Him-in-the-Face

Obligatory by DrSkwid · 2004-10-11 04:41 · Score: 0, Offtopic

object-oriented design is the roman numerals of computing.

-- Rob Pike

others

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter

Re:Obligatory by Anonymous Coward · 2004-10-11 04:46 · Score: 0

No disrespect, but when I see a good OO design done by Rob Pike, I'll pay attention to his critique.
Re:Obligatory by Anonymous Coward · 2004-10-11 04:49 · Score: 0

That is beauty in 9 words.
Re:Obligatory by kundor · 2004-10-11 05:26 · Score: 1

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."
Re:Obligatory by William+Tanksley · 2004-10-11 05:29 · Score: 1

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:Obligatory by cakoose · 2004-10-11 09:34 · Score: 1

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:Obligatory by DrSkwid · 2004-10-11 10:39 · Score: 1

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 ?

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Re:Obligatory by cakoose · 2004-10-11 19:00 · Score: 1

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:Obligatory by DrSkwid · 2004-10-11 19:43 · Score: 1

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

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter

Re:Fair and Balanced by Anonymous Coward · 2004-10-11 04:42 · Score: 0, Flamebait

Seems like the author has a bias towards C#. Is slashdot becoming Fair and Balanced like Fox News.

Oh, you mean "Fair and Balanced" like the usual open source/Linux fanboyism that nomally occurs?

Only Microsoft by $RANDOMLUSER · 2004-10-11 04:42 · Score: 0, Troll

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.

This program has performed an illegal operation and will be shut down. If the problem persists, contact your program vendor.

--
No folly is more costly than the folly of intolerant idealism. - Winston Churchill

Re:Only Microsoft by Anonymous Coward · 2004-10-11 04:50 · Score: 2, Interesting

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:Only Microsoft by Timesprout · 2004-10-11 05:05 · Score: 1, Interesting

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.

--
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Re:Only Microsoft by clamatius · 2004-10-11 05:14 · Score: 2, Insightful

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.
Re:Only Microsoft by teromajusa · 2004-10-11 05:18 · Score: 4, Informative

"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.
Re:Only Microsoft by Anonymous Coward · 2004-10-11 05:18 · Score: 0

While checked exceptions in theory sound like a Good Thing in practice they suck. Some of the problems with checked exceptions are:

1) Client code must catch numerous exceptions it can't possibly recover from.
2) Client code and APIs become bloated with long lists of checked exceptions.

If you don't believe me check out what experts like Bruce Eckel have to say about checked exceptions http://www.mindview.net/Etc/Discussions/CheckedExc eptions

"Checked exceptions seem like a really good idea at first. But it's all based on our unchallenged assumption that static type checking detects your problems and is always best. Java is the first language (that I know of) that uses checked exceptions and is thus the first experiment. However, the kind of code you must write around these things and the common phenomenon of "swallowed" exceptions begins to suggest there's a problem. In Python, exceptions are unchecked, and you can catch them and do something if you want, but you aren't forced. And it seems to work just fine."

cheers
Re:Only Microsoft by Kingpin · 2004-10-11 05:19 · Score: 1

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.

--
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Re:Only Microsoft by winfx · 2004-10-11 05:19 · Score: 1

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
Re:Only Microsoft by Gr8Apes · 2004-10-11 05:28 · Score: 1

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.

--
The cesspool just got a check and balance.
Re:Only Microsoft by teromajusa · 2004-10-11 05:38 · Score: 1

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.
Re:Only Microsoft by Gr8Apes · 2004-10-11 05:41 · Score: 1

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)

--
The cesspool just got a check and balance.
Re:Only Microsoft by jeif1k · 2004-10-11 05:44 · Score: 1

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:Only Microsoft by GreyWizard · 2004-10-11 05:46 · Score: 1

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.

--
Not all those who wander are lost.
Re:Only Microsoft by mcc · 2004-10-11 05:53 · Score: 4, Informative

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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Re:Only Microsoft by rewt66 · 2004-10-11 06:13 · Score: 1

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.
Re:Only Microsoft by toriver · 2004-10-11 06:58 · Score: 1

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.
Re:Only Microsoft by GreyWizard · 2004-10-11 07:01 · Score: 1

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.

--
Not all those who wander are lost.
Re:Only Microsoft by Anonymous Coward · 2004-10-11 08:14 · Score: 0

I've been using Java for five years and forcing checks on exceptions is my number 1 most favorite feature of Java. It is the very first thing I note when I state my preference for Java to other languages. I currently monitor sixty developers, fyi.
Re:Only Microsoft by clamatius · 2004-10-11 08:29 · Score: 1

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.
Re:Only Microsoft by Anonymous Coward · 2004-10-11 09:24 · Score: 0

Argument that C#'s lack of checked exceptions are bad, backed up by a link and personal preference = 2 mod points.
Argument that Java's inclusion of checked exception is good, backed up by a link and personal preference = 3 mod points.
Mmmmm love that Slashdot anti MS goodness.
Re:Only Microsoft by ClosedSource · 2004-10-11 10:47 · Score: 1

"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:Only Microsoft by Anonymous Coward · 2004-10-11 14:48 · Score: 0

This is a laugh.
How do you prefer to transmit the info that an Error has occurred? Do you return Integers that must be checked by the caller? Or do U just Ignore errors?
Guess what, what ever method you use to convey the fact that an error has occurred, will Have to Go Thru Multiple Layers!

- On Microsoft's crack development team, by skipping checked exceptions in .Net, get's to go on Vacation while we Developers have to write Higher Quality Code then they do.

Why did Microsoft skip Checked Exceptions?
- It requires that you Actually Test Your Code to see what are the common errors! Hey Man, That's Work! Work they won't do.

You should do yourself a favor and instead of Believing everything you read from Microsoft, do a little thinking on your own. No disrespect intended.
Re:Only Microsoft by Anonymous Coward · 2004-10-11 14:53 · Score: 0

Checked Exceptions Harden an Application to Enterprise Quality.

Unchecking an exception means you won't handle it. And you don't. Here's another sarcastic clue: If clauses require Elses.

Checked Exceptions are great in that they teach a Java programmer to, after he gives up Fighting Them, a deeper understanding of how to write high quality programs.

You should give them some serious study.
Re:Only Microsoft by Anonymous Coward · 2004-10-11 18:12 · Score: 0

It sure does. But you can't say "nope, I just want to ignore this checked exception for now" - Java makes you deal with it, either by handling or propagating it. This was the original poster's point, which seems to have escaped you completely.
Re:Only Microsoft by mcc · 2004-10-11 18:25 · Score: 2, Insightful

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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Re:Only Microsoft by GreyWizard · 2004-10-12 15:10 · Score: 1

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.

--
Not all those who wander are lost.
Re:Only Microsoft by GreyWizard · 2004-10-12 15:12 · Score: 1

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.

--
Not all those who wander are lost.
Re:Only Microsoft by Gr8Apes · 2004-10-13 03:17 · Score: 1

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

--
The cesspool just got a check and balance.
Re:Only Microsoft by Gr8Apes · 2004-10-13 03:42 · Score: 1

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

--
The cesspool just got a check and balance.
Re:Only Microsoft by Gr8Apes · 2004-10-13 03:50 · Score: 1

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)

--
The cesspool just got a check and balance.
Re:Only Microsoft by ultranova · 2004-10-14 02:52 · Score: 1

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.

--
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

What Language by jcook793 · 2004-10-11 04:42 · Score: 3, Funny

What language was this post written in? Amazing.

Re:What Language by rts008 · 2004-10-11 05:11 · Score: 1

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

--
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
Re:What Language by logic+hack · 2004-10-11 05:35 · Score: 1, Funny

Shhh, you'll start a perl flamewar ;)
Re:What Language by Anonymous Coward · 2004-10-11 06:00 · Score: 0

Perl sucs! emacs forever!
Let the flames go wild! Yeah!!!

C# and Java by disbaldman · 2004-10-11 04:42 · Score: 1, Interesting

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 by Tablizer · 2004-10-11 04:43 · Score: 3, Insightful

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.

--
Table-ized A.I.

Re:I want functions by MemoryDragon · 2004-10-11 04:46 · Score: 1

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 by Anonymous Coward · 2004-10-11 04:50 · Score: 0

If you think the language is too OO, use another. If you don't have that luxury, the blame doesn't lie on OO zealots but on the reality of your work environment.
Re:I want functions by Tablizer · 2004-10-11 05:00 · Score: 0, Troll

If you think the language is too OO, use another. If you don't have that luxury, the blame doesn't lie on OO zealots but on the reality of your work environment.

The reality is that Java is becomming the New Cobol: you cannot escape it for most cubicle jobs. Also, with W's economy, there are not a lot of choices these days. For example, one may be forced to chose between a good language and a lousy boss, or a good boss and a lousy language.

--
Table-ized A.I.
Re:I want functions by e2d2 · 2004-10-11 05:07 · Score: 2, Funny

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 by Anonymous Coward · 2004-10-11 05:46 · Score: 0

I like how you managed to criticize Bush in an article about the relative merits of C# and Java. Here are some handy hints:

1. Political flames belong in political threads.
2. Programming language flames belong in programming language threads.

This is usually referred to as "being on topic." Just a heads up.

Mods, these kind of quips in comments are what incite offtopic flamewars. Please mod parent and this comment offtopic/flamebait/retarded.
Re:I want functions by Tablizer · 2004-10-11 06:27 · Score: 0, Troll

There are people still arguing against OOP? How quaint. Why not argue against managed memory while you're at it.

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.

--
Table-ized A.I.
Re:I want functions by metlin · 2004-10-11 06:36 · Score: 1

Dude, that was simply the best post I've seen in a long time. Thanks for a good laugh!!
Re:I want functions by TravisWatkins · 2004-10-11 07:16 · Score: 1

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

--

"But I'm still right here, giving blood and keeping faith. And I'm still right here."
Re:I want functions by Gossy · 2004-10-11 11:46 · Score: 1

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 by dcam · 2004-10-11 12:07 · Score: 1

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

--
meh
Re:I want functions by Tablizer · 2004-10-11 14:05 · Score: 1

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.

--
Table-ized A.I.
Re:I want functions by Anonymous Coward · 2004-10-11 18:58 · Score: 0

Almost everyone, except for the extreme OO zealots, agree

Ooops. Typo. Should be "agrees"
Re:I want functions by julesh · 2004-10-11 19:36 · Score: 1

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 by julesh · 2004-10-11 19:45 · Score: 1

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 by Tablizer · 2004-10-12 10:16 · Score: 1

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.

--
Table-ized A.I.

Too bad we can't mod articles by MojoRilla · 2004-10-11 04:43 · Score: 3, Insightful

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 by Slime-dogg · 2004-10-11 05:31 · Score: 5, Insightful

I wouldn't give Java the credit for C#. If anything, it was Delphi that C# was built upon. The only thing that C# "borrowed" from Java is the idea of a VM, and even that functions in a different way than the Java one.

--
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Re:Too bad we can't mod articles by rabtech · 2004-10-11 06:22 · Score: 1

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.

--
Natural != (nontoxic || beneficial)
Re:Too bad we can't mod articles by Anonymous Coward · 2004-10-11 06:36 · Score: 0

There should be no gloating on the part of C#, it was clearly built on Java's coattails.
And Java is now trying to build on C#'s coattails. If you can't see why this is a bad idea I recommend you find a friend and a couple of tailcoats and try it for yourself. ;-)
Re:Too bad we can't mod articles by Anonymous Coward · 2004-10-11 08:29 · Score: 0

Take LPC for example from muds... What year was that? 1989?
Re:Too bad we can't mod articles by Anonymous Coward · 2004-10-11 14:22 · Score: 0

Dreamland.
Must be nice to live there.
Completely ignore the fact that when Java came out developers left Microsoft in droves.
Re:Too bad we can't mod articles by Anonymous Coward · 2004-10-11 14:54 · Score: 0

Actually, the entire .NET Framework (I think) is modelled after Delphi's Architecture/Framework (I could be wrong, though), given that the same guy (Hjellsberg) is behind both tech.
Re:Too bad we can't mod articles by kaffiene · 2004-10-11 15:26 · Score: 1

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? by Qwertie · 2004-10-11 04:43 · Score: 1

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? by Anonymous Coward · 2004-10-11 04:54 · Score: 0

Static imports are nothing but evil, Period.
This is not about any OOP concepts or anything, it's purely about readability.
With:
Math.cos(x)
you know exactly where that cos() came from... whereas, when you see
cos(x)
in the code, you'll have to start a quest for the real point of definition ("Is it defined in this class? In a super class? Or... is it no instance method but a static method? Is is some statically imported method? ...").

There's no reason for static imports... if you're still using Dos Edit or edlin for coding... (where saving 3 keystrokes might seem a good idea) well, you should probably reconsider your career...
Re:Static Import Bad? by fishbowl · 2004-10-11 05:00 · Score: 2, Insightful

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

--
-fb Everything not expressly forbidden is now mandatory.

From the Horse's Mouth - might make more sense by Anonymous Coward · 2004-10-11 04:44 · Score: 2, Informative

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 by Dante+Shamest · 2004-10-11 04:44 · Score: 2, Insightful

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 by jonathanduty · 2004-10-11 04:50 · Score: 1

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 by lakcaj · 2004-10-11 04:54 · Score: 1

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 by SlashdotMeNow · 2004-10-11 04:56 · Score: 1

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 by Qwertie · 2004-10-11 04:57 · Score: 1

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 by scovetta · 2004-10-11 05:03 · Score: 4, Insightful

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.

--
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Re:Flaws in both Languages by nat5an · 2004-10-11 05:04 · Score: 4, Insightful

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.

--
Head down, go to sleep to the rhythm of the war drums...
Re:Flaws in both Languages by Kihaji · 2004-10-11 05:06 · Score: 1

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 by danharan · 2004-10-11 05:10 · Score: 1

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?

--
Information: "I want to be anthropomorphized"
Re:Flaws in both Languages by X · 2004-10-11 05:10 · Score: 4, Interesting

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.

--
sigs are a waste of space
Re:Flaws in both Languages by greg_barton · 2004-10-11 05:12 · Score: 2, Insightful

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 by Anonymous Coward · 2004-10-11 05:13 · Score: 0

I cannot believe this got a 5, Insightful. What the hell? Are 15 year old kids modding today?

"Both require virtual machines" - you idiot, how do you think Perl, Python, etc. run?

Can you tell me how Python 2.3.4 is backwards compatible with 1.5.2? Check out datetime for a clue.

Why am I wasting my time...I wish there was a popular forum where actual programmers and not dumb kids hung out. Slashdot should make people pass a test or something before they're allowed to post, to weed out cretinous bullshit like the parent.
Re:Flaws in both Languages by KZigurs · 2004-10-11 05:14 · Score: 1, Informative

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 by pjt33 · 2004-10-11 05:16 · Score: 1

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 by PCM2 · 2004-10-11 05:21 · Score: 2, Insightful

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

--
Breakfast served all day!
Re:Flaws in both Languages by Teckla · 2004-10-11 05:37 · Score: 2, Insightful

# Neither are open source.

How can you "open source" a language? Are you talking about compilers themselves being open source, or what? The language specifications for both Java and C# are trivially available for anyone that cares to look at them.

# Both require virtual machines.

This is simply not true. For example, there are at least two Java compilers that produce native executables.

# Despite being marketed as portable, but have portability issues. Java is not backward compatible with older 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 by Anonymous Coward · 2004-10-11 05:44 · Score: 0

ad 1.)
I agree totally... also see my Open Source Java FAQ:
http://www.jroller.com/page/murphee/20040426
Where I dismiss similar rumors.

ad 2.)
Kind off weird statements about JITs... Why would Sun avoid writing 1000 differen JITs? All current JVMs feature either JITs or the superior dynamic compilers (which use runtime profiling to be able to generate better optimized code than JITs). Javas bytecode has an additional advantage over the limited MS IL: it *can* be interpreted (one of MS' big marketing arguments is that the MS IL code is optimized for JIT compilation... and they try to sell this as an advantage... of course, totally ignoring the fact that this keeps .NET from being run on constricted environments where JIT compilation is not an option. These environments, though, can easily allow a Java Bytecode interpreter).

murphee
Re:Flaws in both Languages by X · 2004-10-11 05:57 · Score: 1

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

--
sigs are a waste of space
Re:Flaws in both Languages by Anonymous Coward · 2004-10-11 06:03 · Score: 0

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

You advocate Java and slam PHP in the same post? Both of these languages belong in the same beginners class.
Re:Flaws in both Languages by Anonymous Coward · 2004-10-11 06:07 · Score: 0

There's a saying about 'people who live in glass houses'...

If you got your wish, junior, we wouldn't be seeing posts like yours either!
Re:Flaws in both Languages by Anonymous Coward · 2004-10-11 06:09 · Score: 0

Can you tell me how Python 2.3.4 is backwards compatible with 1.5.2?
They have different major numbers and therefore shouldn't be backwards compatible. Java releases, on the other hand, have major numbers of 1 with varying minor numbers, and therefore should be backwards compatible. See, version numbers are supposed to actually mean something and not just be fucking marketing gimmicks.
Re:Flaws in both Languages by pjt33 · 2004-10-11 06:10 · Score: 1

That's forwards compatibility, not backwards compatibility.
Re:Flaws in both Languages by Tony+Hoyle · 2004-10-11 06:12 · Score: 1

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 by Anonymous Coward · 2004-10-11 06:13 · Score: 0

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.
I get the point that it can be done in assembly, but Perl and PHP are clearly an advance over assembly. What is the advantage of Java/C# over Perl/PHP?
Re:Flaws in both Languages by X · 2004-10-11 06:14 · Score: 1

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.

--
sigs are a waste of space
Re:Flaws in both Languages by Nukenin · 2004-10-11 06:45 · Score: 1

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 by Hakubi_Washu · 2004-10-11 07:03 · Score: 1

>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 by Anonymous Coward · 2004-10-11 07:11 · Score: 0

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.

Java's design sucks for portability yet it is one of the biggest selling points! I don't know what you consider perfect portability but there are bit identical runtimes out there.

Really, when you think about it, we only really need C. PHP/Perl/C++/Python are really all flawed languages as a consequence. ;-)

I noticed you did not mention Lisp but again you were showing flawed languages :)
Re:Flaws in both Languages by Anonymous Coward · 2004-10-11 07:16 · Score: 0

Hi!

you must be on crack.
1. the java interpreter is open source. the language specification and API are open source.
2. java requires the JVM, C# requires the .net runtime environment, ported with every distribution of windows.
3. I dont know where you work, but we have a serious need for OO-oriented languages for all of the web-based programming we do. saying all we need is C is like saying I can write a thick database client in assembly.
Re:Flaws in both Languages by Hezaurus · 2004-10-11 07:19 · Score: 2, Interesting

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!

--
No matter how fast light travels it finds the darkness has always got there first, and is waiting for it. (T. Pratchett)
Re:Flaws in both Languages by Anonymous Coward · 2004-10-11 07:38 · Score: 0

Really, when you think about it, we only really need C. PHP/Perl/C++/Python are really all flawed languages as a consequence. ;-)
I think what you meant to say is we only *REALLY* need machine language.
Re:Flaws in both Languages by scovetta · 2004-10-11 08:59 · Score: 3, Insightful

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?

--
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Re:Flaws in both Languages by goon+america · 2004-10-11 12:43 · Score: 1

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 by antoy · 2004-10-11 13:58 · Score: 1

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 by Hezaurus · 2004-10-11 20:12 · Score: 1

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.

--
No matter how fast light travels it finds the darkness has always got there first, and is waiting for it. (T. Pratchett)
Re:Flaws in both Languages by maxwell+demon · 2004-10-11 22:36 · Score: 1

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

--
The Tao of math: The numbers you can count are not the real numbers.
Re:Flaws in both Languages by Anonymous Coward · 2004-10-12 01:49 · Score: 0

well said. PHP and Perl (especially PHP) are useless for large complex applications.
Spaghetti code is mandatory, maintenance is impossible.
Re:Flaws in both Languages by Hakubi_Washu · 2004-10-12 03:45 · Score: 1

Now, THAT'S a geek to my tastes :-P
Re:Flaws in both Languages by Anonymous Coward · 2004-10-14 01:22 · Score: 0

> here. You need to create an account to be able
> to download.

This is nonsense. Please read the license terms.

Java is not open source in any way.
Re:Flaws in both Languages by Decaff · 2004-10-14 08:09 · Score: 1

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 by X · 2004-10-15 13:17 · Score: 1

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.

--
sigs are a waste of space
Re:Flaws in both Languages by Hezaurus · 2004-10-20 10:10 · Score: 1

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

--
No matter how fast light travels it finds the darkness has always got there first, and is waiting for it. (T. Pratchett)

Why is there a C# advertisement on /.? by Cloudgatherer · 2004-10-11 04:44 · Score: 5, Insightful

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 /.? by Anonymous Coward · 2004-10-11 04:50 · Score: 0

why is this comment rated so bad?

isnt it true?
Re:Why is there a C# advertisement on /.? by jrumney · 2004-10-11 05:27 · Score: 2, Informative

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 by minus_273 · 2004-10-11 04:44 · Score: 2, Informative

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.

--
The war with islam is a war on the beast
The war on terror is a war for peace

Re:templates by ArbitraryConstant · 2004-10-11 05:14 · Score: 1

Java 1.5 supports templates/generics/whatever.

--
I rarely criticize things I don't care about.
Re:templates by Anonymous Coward · 2004-10-11 06:16 · Score: 0

Java 1.5 supports syntactic sugar that automatically does casting for you. C# 2.0 will have real templates/generics/whatever as opposed to Java's half-assed attempt.
Re:templates by 21mhz · 2004-10-11 06:18 · Score: 1

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

--
My exception safety is -fno-exceptions.

Corrected URL by waynegoode · 2004-10-11 04:44 · Score: 4, Informative

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.

Seems like a good step if by BaconLT · 2004-10-11 04:45 · Score: 0, Troll

It might be a good step if Java becomes open source; then it's on a different playing field than C# because it seems that the authors of Java realized that C# is superior in many ways.
The playing field they would enter, however, already belongs to Mono.

So, who will survive?

I guess Java has started a revolution without an "exit strategy."

--
Who mediates your information?

I call bullshit by The+Bungi · 2004-10-11 04:45 · Score: 5, Insightful

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.

+1 INTERESTING !???! by Anonymous Coward · 2004-10-11 04:45 · Score: 0

I can understand +1 funny, but INTERESTING, hmmmm

the crap argument by iamchaos · 2004-10-11 04:46 · Score: 5, Interesting

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 by KZigurs · 2004-10-11 05:30 · Score: 1, Interesting

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 by killjoe · 2004-10-11 06:01 · Score: 2, Insightful

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

--
evil is as evil does
Re:the crap argument by cayce · 2004-10-11 07:42 · Score: 1

"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 by Peter+Harris · 2004-10-12 10:09 · Score: 1

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

--

-- What do you need?
-- Gnus. Lots of Gnus.

varargs by $RANDOMLUSER · 2004-10-11 04:46 · Score: 1

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

--
No folly is more costly than the folly of intolerant idealism. - Winston Churchill

Re:varargs by ultrabot · 2004-10-11 04:52 · Score: 1

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.

--
Save your wrists today - switch to Dvorak
Re:varargs by Qwertie · 2004-10-11 04:54 · Score: 1

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 by SlipJig · 2004-10-11 05:05 · Score: 1

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.

--
Read my keyboard review.
Re:varargs by CableModemSniper · 2004-10-11 05:05 · Score: 1

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

--
Why not fork?
Re:varargs by CountBrass · 2004-10-11 05:16 · Score: 2, Informative

I think you've completely misunderstood polymorphism and/or varargs.
I've never, ever had to write a Java method that would have been better implemented using varargs, but I've written plenty in C and C++ in the past that would have been better written without them...
I can only think of a couple of cases in Java where varargs would actually improve matters (have a look at MessageFormat, the work around it uses to emulate varargs is painful so varargs would be great there). But I just know varargs will get 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!

--
Bad analogies are like waxing a monkey with a rainbow.
Re:varargs by sbrown123 · 2004-10-11 06:27 · Score: 2, Interesting

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.
Re:varargs by Anonymous Coward · 2004-10-11 07:03 · Score: 0

Eck, I tend to disagree with you on what polymorphism is. Your definition sounds more like multi-methods. It is debateable what exactly is polymorphism but I would argue for a definition that talked about extending types and redefining type methods. Java people are liable to say, "What is a virtual function?"

I think the original poster was suggesting that with almost everything having a base class of Object you could just pass an Object array and a String with type hints. Casting is safe/checked so this is seems pratical.

I just do not really understand the need for varargs or enums in Java.

Version by xPhoenix · 2004-10-11 04:46 · Score: 4, Funny

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 by msuzio · 2004-10-11 05:40 · Score: 1

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.

--
It's a strange world -- let's keep it that way
Re:Version by CmdrMooCow · 2004-10-11 11:05 · Score: 1

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

one...
two...
FIVE!
Re:Version by jack_csk · 2004-10-11 12:18 · Score: 1

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

Optimization models by scumbucket · 2004-10-11 04:46 · Score: 2, Informative

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.

--
CMDRTACO CHECK YOUR EMAIL!

Re:Optimization models by Qwertie · 2004-10-11 05:01 · Score: 1

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 by Headius · 2004-10-11 06:29 · Score: 2, Informative

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 by Palshife · 2004-10-11 04:47 · Score: 4, Informative

XML Parser

You mean like JAXP and JAXB?

--
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!

Nevermind... by waynegoode · 2004-10-11 04:47 · Score: 1

It has been corrected now.

Mistake by ajs · 2004-10-11 04:47 · Score: 3, Insightful

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 by Sanity · 2004-10-11 04:56 · Score: 4, Insightful

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 by Anonymous Coward · 2004-10-11 05:20 · Score: 0

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.

Most of these language features are compiler features, a.k.a. "syntactic sugar", which do not affect testability or performance.

Java is a high-level language in my definition anyway.
Re:Mistake by Derkec · 2004-10-11 06:17 · Score: 1

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 by WaterBreath · 2004-10-11 06:27 · Score: 1

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 by WaterBreath · 2004-10-11 06:32 · Score: 2, Interesting

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 by Fnkmaster · 2004-10-11 06:35 · Score: 1

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 by scruffy · 2004-10-11 06:48 · Score: 1

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 by blowdart · 2004-10-11 07:05 · Score: 2, Informative

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 by Anonymous Coward · 2004-10-11 07:56 · Score: 0

It does feel like Sun was forced into adding these features. I think it funny how so many Java purists argued in favor or explicit casting and pointed how their language does not have it. Now since Java supports Generics you do not hear from them people. Just so people know, Gosling was not one of those people- in fact I believe I read once that he wanted to add operator over-loading to Java!

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.

Auto-boxing is just more syntactic sugar, which is not a good thing. I don't know such performance issues would be harder to track down- if you understand auto-boxing. My biggest complaint is that it is another exception to Java's so-called "clean" syntax.
Re:Mistake by mmusson · 2004-10-11 08:25 · Score: 1

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.

--
SYS 49152
Re:Mistake by Fnkmaster · 2004-10-11 08:26 · Score: 1

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 by Fnkmaster · 2004-10-11 08:41 · Score: 2, Informative

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 by ajs · 2004-10-11 09:26 · Score: 1

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

Were you responding to my comment about C?
Re:Mistake by ajs · 2004-10-11 09:58 · Score: 1

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 by WaterBreath · 2004-10-11 12:04 · Score: 1

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 by ajs · 2004-10-11 13:05 · Score: 1

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 by SvendTofte · 2004-10-11 13:39 · Score: 1

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 by horza · 2004-10-12 00:58 · Score: 1

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.

--
Property for sale in Nice, France
Re:Mistake by Derkec · 2004-10-12 03:48 · Score: 1

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 by cakoose · 2004-10-12 06:00 · Score: 2, Informative

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 by SvendTofte · 2004-10-12 06:50 · Score: 1

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. by MacDork · 2004-10-11 04:47 · Score: 1

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. by I+confirm+I'm+not+a · 2004-10-11 04:54 · Score: 1

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?

--
This is where the serious fun begins.
Re:Available application servers. by ClippyHater · 2004-10-11 05:37 · Score: 1

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. by Anonymous Coward · 2004-10-11 05:45 · Score: 0

So the answer is 0
Re:Available application servers. by rewt66 · 2004-10-11 05:55 · Score: 1

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.
Re:Available application servers. by Anonymous Coward · 2004-10-11 06:32 · Score: 0

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

Then why in the world are you using LINUX???
Re:Available application servers. by Anonymous Coward · 2004-10-11 14:38 · Score: 0

No, Microsoft Transaction Server, aka "COM+".

Whidbey by Anonymous Coward · 2004-10-11 04:49 · Score: 0

I wonder how Tiger compares to ASP.NET 2.0? http://www.asp.net/whidbey/

Heh by KoolDude · 2004-10-11 04:50 · Score: 2, Funny

SexyFingers writes "Sun released Java 1.5...

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

--
getSexySig(); /* returns sexy signature */

Re:APIs by SnapShot · 2004-10-11 04:51 · Score: 3, Insightful

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.

--
Waltz, nymph, for quick jigs vex Bud.

Re:APIs by Anonymous Coward · 2004-10-11 04:51 · Score: 0

XML:
http://xml.apache.org/xerces-j/

MD5:
a google search for "md5 java" throws
http://www.twmacinta.com/myjava/fast_md5.p hp

what are you talking about?

AVP by pizza_milkshake · 2004-10-11 04:52 · Score: 4, Funny

It's just like Alien vs. Predator:

whoever wins, we lose.

Re:AVP by ppz003 · 2004-10-11 05:37 · Score: 1

We lose approximately $7 to $10 per person to be exact.
Re:AVP by Coryoth · 2004-10-11 06:34 · Score: 1

It's just like Alien vs. Predator:

whoever wins, we lose.

Or Bush vs. Kerry for that matter.

Jedidiah.

--
Craft Beer Programming T-shirts
Re:AVP by dcam · 2004-10-11 12:09 · Score: 1

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

If you saw the movie you certainly did.

--
meh

Old school here, but is C# anything like C++ by Anonymous Coward · 2004-10-11 04:52 · Score: 0

for object oriented programming (never mind window dressing inheritance).

So this is what... by Sanity · 2004-10-11 04:52 · Score: 1

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... by teromajusa · 2004-10-11 05:02 · Score: 2, Funny

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... by Tumbleweed · 2004-10-11 05:06 · Score: 1

/. editors are for editing article submissions.

No, seriously!

You can stop laughing any time now.

slashdot changes stories?? by dAzED1 · 2004-10-11 04:52 · Score: 1

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 by jayminer · 2004-10-11 04:52 · Score: 5, Insightful

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 by Moe+Yerca · 2004-10-11 04:52 · Score: 2, Informative

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 by knitterb · 2004-10-11 04:52 · Score: 5, Informative

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! :(

--
-bk

Re:IIS vs J2EE Servers by SlashdotMeNow · 2004-10-11 05:07 · Score: 1, Troll

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 by nuggetboy · 2004-10-11 05:20 · Score: 2, Informative

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 by Anonymous Coward · 2004-10-11 06:06 · Score: 0

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.

But isn't it all worth the trouble if programmers can type "foo.bar=5;" instead of foo.setBar(5);"?
Re:IIS vs J2EE Servers by Anonymous Coward · 2004-10-11 06:18 · Score: 0

I find it funny that you say this because I have the exact opposite opinion. War and Ear files are such a fucking joke. With IIS I can simply deploy my files and every possible configuration is available to me in a easy to use MMC.
What the hell is up with websphere and having to use their edge server just to set you http cache control settings? Websphere isn't much better. Oh, and using Apache and Tomcat means two sets of configs. IIS wins in all these cases.

So I would put forth that your issues aren't that serious. More they are just you lack of comfortability with the platform. I'm sure that if I really worked at it I would get over my issues with the Java App server deployement.

One point I do agree with you on. Session management in IIS SUCKS! There are other solutions for it, but nothing great. I also think dot.net sucks at messaging, but that should be fixed in indigo.
Re:IIS vs J2EE Servers by eakerin · 2004-10-11 06:20 · Score: 4, Informative

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 by Anonymous Coward · 2004-10-11 06:39 · Score: 0

Nothing groundbreaking? What about DataGrid1.DataBind() or built-in viewstate management?.
LOL! You've got to be joking. You would classify those as ground-breaking? Ground-breaking is going from proceedural to OO. For some people it is things like aspects or dependency-injection. You are talking about a simple GUI component that could be written in a weekend or two as groundbreaking. What a sad small world you have.
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.
This is a problem when dealing with MS developers. They are so under-exponsed to technology that they cannot even understand that VSS has only a small part to play with release management and deployment. The fact that VSS sucks and MS can not even use it internally, and the fact that the MS .Net folks dont think of using anything else for SCM is telling. It is as if any gene that effects curiosity or pride in their work have been removed from these guys.
.net shits all over everything else for pure developer productivity.
I believe this poor misinformed soul meant to say
.net shits all over everything
For those who have actually used .Net and something else to do real development; I think we would all agree.
Re:IIS vs J2EE Servers by badriram · 2004-10-11 06:58 · Score: 1

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 by knitterb · 2004-10-11 07:20 · Score: 1

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.

--
-bk
Re:IIS vs J2EE Servers by CoolMoDee · 2004-10-11 07:47 · Score: 1

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

--
Jisho - A Japanese English German Russian French Dictionary for the rest of us.
Re:IIS vs J2EE Servers by Johnno74 · 2004-10-11 08:15 · Score: 1

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 by badriram · 2004-10-11 08:35 · Score: 1

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 by Bake · 2004-10-11 11:09 · Score: 1

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.
Re:IIS vs J2EE Servers by Anonymous Coward · 2004-10-11 14:17 · Score: 0

> there is nothing else to it.

Unless you are making like Java and using an "Enterprise Services" layer. Then you are back into COM-style registration.

Important differences between Java and C# by daveho · 2004-10-11 04:53 · Score: 5, Insightful

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# by ferratus · 2004-10-11 05:40 · Score: 1

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.

--
IP Therefore I am.
Re:Important differences between Java and C# by Anonymous Coward · 2004-10-11 06:14 · Score: 0

I can't see JVM running on a wide variety of platforms.
Re:Important differences between Java and C# by rabtech · 2004-10-11 06:19 · Score: 2, Insightful

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.

--
Natural != (nontoxic || beneficial)
Re:Important differences between Java and C# by julesh · 2004-10-11 19:54 · Score: 1

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

The language doesn't matters, it's the platform! by diegocgteleline.es · 2004-10-11 04:54 · Score: 0, Troll

So...who cares if java is better/worse than C#?

What Suns try to sell is Java and the Java platform. Sun tells you "Here you have Java, it's better than what you're using because we say so, and you should use it".

Instead, Microsoft sells you a *real* platform. Microsoft tells you "Here you have .NET, it's better than what you're using because we say so, we provide you a nice language likce C#, BUT YOU CAN USE WHATEVER LANGUAGE you want". Which is, to my eyes, looks much better.

Yes, I know, you can use other languages in java. But that's *not* what Sun wants to do, and it's *not* what it's really happening, and because Java is *not* a real standard (it's controlled by some weird committe) the picture doesn't seems like it's going to change. C# is a real open standard (the rest of the .NET platform, the APIs, etc isn't but...) with a open implementation (mono) which is good for people suffering from GPLitis and similar diseases. We can use C# in linux witout using the rest of the .NET platform (same goes for Java, but the sun's java VM license is so weird some distros can't even distribute it without pain...)

Plus, Microsoft has the power to say "here you have this lenguage, use it". Sun can try to say the same, but very few people will listen them.
In fact, they've been doing it for 10 years and still everybody uses C++ for things like browsers, AIM clients... (don't tell me Java wasn't targetted to do that, if I can't write normal programs in Java - not because you can't but because Java sucks for that - why I would want to use it in first place?!?)

Maybe I'm an oldtimer, but... by Tony · 2004-10-11 04:54 · Score: 4, Funny

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

--
Microsoft is to software what Budweiser is to beer.

Re:Maybe I'm an oldtimer, but... by vidnet · 2004-10-11 06:00 · Score: 0, Flamebait

Oh, how I pine for the days of vi vs. Emacs.
Yes, me too. It's a shame that Vim cut the debate so tragically short. Rest in pieces, Emacs!
Re:Maybe I'm an oldtimer, but... by samberdoo · 2004-10-11 06:03 · Score: 1

But do you use Pine to read your /.?
Re:Maybe I'm an oldtimer, but... by Anonymous Coward · 2004-10-11 06:09 · Score: 0

your days have gone, we are comparing gvim vs. xemacs, :-)
Re:Maybe I'm an oldtimer, but... by Anonymous Coward · 2004-10-11 06:23 · Score: 0

... pine ...

mutt!!!
Re:Maybe I'm an oldtimer, but... by balster+neb · 2004-10-11 06:32 · Score: 1

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

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

Re:APIs by ckuske · 2004-10-11 04:54 · Score: 1

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 by JPyObjC+Dude · 2004-10-11 04:54 · Score: 5, Insightful

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 by pesc · 2004-10-11 05:14 · Score: 5, Insightful

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

--

)9TSS
Re:With C#, stuck in windoze by fitten · 2004-10-11 05:41 · Score: 2, Informative

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 by cmorriss · 2004-10-11 06:32 · Score: 2, Informative

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.

--
10 minutes working on a sig. What a waste.
Re:With C#, stuck in windoze by jrumney · 2004-10-11 09:45 · Score: 1

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 by Uber+Banker · 2004-10-17 02:31 · Score: 1

FOAD

I hope so. by Anonymous Coward · 2004-10-11 04:54 · Score: 0

Having to deal with these new features, in large projects with many people, will be hell.

Why is the Java language adding all of the misfeatures of C#? Autoboxing causes more problems in the long run than having to explicitely boxing objects. I'd rather than do a little more typing (no pun intended) to avoid confusing idiosyncracies of autoboxing. Generics? Ugh.. you mean we have to see that nasty template crap from C++ again? Typesafe enums? I haven't had a chance to look at the implementation so I'm going to abstain commenting about them. Varargs-- why? It's so much easier (and more intuitive) to create an array of objects and pass them as a parameter. Static Import? I'll abstain talking about this one as I don't know much about it. All I know is the concept of aliasing imports sucks for large projects! Let's just say, that everyone and their dog will alias various libraries with their own abbreviations and cutting/pasting code snippits between other people will be a fucking pain to detangle! Metadata/annotations/attibutes: Ugh, more syntactic sugar that belongs in the trash. Pain. Agony.

Quite frankly, I'd rather work in the ((parenthesis) hell) of Lisp than having to deal with all these unwieldy features.

Re:I hope so. by jallen02 · 2004-10-11 05:01 · Score: 1

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:I hope so. by Anonymous Coward · 2004-10-11 05:06 · Score: 1, Insightful

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:I hope so. by Anonymous Coward · 2004-10-11 05:59 · Score: 1, Insightful

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...
Re:I hope so. by blowdart · 2004-10-11 06:36 · Score: 1

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.
Re:I hope so. by jallen02 · 2004-10-11 11:14 · Score: 1

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

Re:APIs by AKAImBatman · 2004-10-11 04:56 · Score: 5, Insightful

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?

--
Javascript + Nintendo DSi = DSiCade

Re:Sounds a lot like religion by Glock27 · 2004-10-11 04:56 · Score: 2, Insightful

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.

--
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait

Re:APIs by iabervon · 2004-10-11 04:57 · Score: 1

An XML Parser and stuff like MD5.

"One Person"... "One C# Developer" by Black-Man · 2004-10-11 04:57 · Score: 3, Insightful

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" by gauchopuro · 2004-10-11 06:51 · Score: 1

Broken link? It seems like most of the links posted on Slashdot are broken. (And if not, just wait a while.)
Re:"One Person"... "One C# Developer" by Anonymous Coward · 2004-10-11 09:48 · Score: 0

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

This is slashdot. Why are you clicking links and trying to read the articles? Just scan the blurb then post like a maniac. Duh!

Re:Let the flame wars begin! by Anonymous Coward · 2004-10-11 04:57 · Score: 0

Sun should work on the speed issues if they want Java to be used for anything else than academical and educational programs.

Common sense prevails again! by Blitzenn · 2004-10-11 04:58 · Score: 0, Flamebait

Hey a story written by another real world coder! Hurray for slashdot! This stuff matters to me. I have to code for corporate enterprise environments and HAVE to use the bohemoths for my studios.

Java has always given me the pieces of the puzzle that I have needed where MS languages left off. It is nice to see another vendor meeting the bar. I think now the question is becoming Java OR C# rather than MS augmented by mutterings of java code slipped in here and there to make up for what the MS's failings. Sure all languages will frustrate you in one area or another. It's just not possible to see how somethings will be adapted in the real world until it is actually out there. That is when the language builders stop back and say, hmmm, should have implemented that one differently. Problem has been that MS would never admit that they could have done something better and laughable to even think they would change it even if they did realize it. Java has more work to do, but at least it is getting really close to where they need to be for us corporate coders to look at it seriously as a platform of choice.

Now they just need to work on their web server a bit more.

Re:Common sense prevails again! by Blitzenn · 2004-10-12 01:02 · Score: 1

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!

Re:APIs by GileadGreene · 2004-10-11 04:58 · Score: 2, Informative

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 by otisg · 2004-10-11 04:58 · Score: 4, Interesting

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

--
Simpy

Re:APIs by jchoyt · 2004-10-11 04:59 · Score: 0, Flamebait

That should be, "Any other features you'd like me to find for you, dumbfuck?"

--
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.

Re:Fair and Balanced by Anonymous Coward · 2004-10-11 05:00 · Score: 0

around here we like to call it "an open source circle jerk".

Re:APIs by AKAImBatman · 2004-10-11 05:01 · Score: 1

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

--
Javascript + Nintendo DSi = DSiCade

hear here by dAzED1 · 2004-10-11 05:02 · Score: 1

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

Meanwhile, C++ goes nowhere by Animats · 2004-10-11 05:02 · Score: 2, Insightful

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 by sriram_2001 · 2004-10-11 05:08 · Score: 1

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 by scotch · 2004-10-11 05:19 · Score: 2, Informative

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.

--
XML causes global warming.
Re:Meanwhile, C++ goes nowhere by StrawberryFrog · 2004-10-11 05:20 · Score: 1

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.

--
My Karma: ran over your Dogma
StrawberryFrog
Re:Meanwhile, C++ goes nowhere by cpghost · 2004-10-11 05:28 · Score: 4, Insightful

C++ is a great language, but it's choosy about its friends. It takes some time to master all (well most) advanced aspects, but as soon as you do, nothing beats a good C++/STL combo.

What I don't like about C++ standard, is the lack of a decent socket library that would be part of the i/o streams. There are non-portable classes for this of course, and everyone could roll their own, but it's not in the C++ standard (yet).

IMHO, one of Java/C# biggest advantages over C++ is this particular aspect. Not that it would convince me though to switch away from C++ to Java, which simply doesn't cut it yet.

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

--
cpghost at Cordula's Web.
Re:Meanwhile, C++ goes nowhere by joib · 2004-10-11 05:35 · Score: 1

Luckily Fortran, with the advent of the new Fortran 2003 standard, is stronger than ever. ;-)
Re:Meanwhile, C++ goes nowhere by yamla · 2004-10-11 05:40 · Score: 2, Interesting

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.

--

Oceania has always been at war with Eastasia.
Re:Meanwhile, C++ goes nowhere by ultrabot · 2004-10-11 05:49 · Score: 2, Insightful

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

--
Save your wrists today - switch to Dvorak
Re:Meanwhile, C++ goes nowhere by spirality · 2004-10-11 05:56 · Score: 1

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 by Gr8Apes · 2004-10-11 06:05 · Score: 1

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

--
The cesspool just got a check and balance.
Re:Meanwhile, C++ goes nowhere by mypalmike · 2004-10-11 06:08 · Score: 1

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

--
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
Re:Meanwhile, C++ goes nowhere by Anonymous Coward · 2004-10-11 06:08 · Score: 1, Funny

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

I love you.
Re:Meanwhile, C++ goes nowhere by deadlinegrunt · 2004-10-11 06:08 · Score: 3, Insightful

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.

--
BSD is designed. Linux is grown. C++ libs
Re:Meanwhile, C++ goes nowhere by ultrabot · 2004-10-11 06:43 · Score: 1

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

--
Save your wrists today - switch to Dvorak
Re:Meanwhile, C++ goes nowhere by Anonymous Coward · 2004-10-11 06:53 · Score: 0

Yes, the replacement for sprintf is std::stringstream. The printf family of functions was completely replaced by the iostream family of classes.
Re:Meanwhile, C++ goes nowhere by Animats · 2004-10-11 07:03 · Score: 0, Flamebait

OK, more details.
The classical problem with C was the failure to distinguish between a pointer and an array. (In the late 1970s, this was considered a feature. Now we know it's a bug.) This led to passing arrays around without size information, and to pointer arithmetic. C++ tries to paper over those issues with the STL, and it almost works. Almost.
"Smart pointers" don't work all that well in C++. The "auto_ptr" mess is instructive. After three published revisions, it still doesn't work well. And that's the simplest case. Reference-counted pointers have worse problems. Making an efficient, airtight smart pointer does not seem to be possible within C++. It needs some language support. Perl's strong and weak references (not Java's) are a good model here. With optimization and language support, the overhead of reference counting can be brought way down. But you can't do that at the template level.
(Incidentally, retrofitting garbage collection to C++ is probably a mistake. It's been tried. The interaction with destructor semantics is too ugly. Calling destructors at random times is not a good thing. And it leads to horrors like "re-animation" in Microsoft Managed C++).
The other huge area of trouble in C++ is threading. The language ignores the whole issue. Locking is considered a library issue. The compiler gives you no help in determining whether a program is free of race conditions.
Because C++ is unsafe, the usual advice is to be "very very careful". This has led to much talk of "patterns", rituals and taboos which supposedly keep bad things from happening. This helps a little, but it's more of a cult than a tool set.
So what we really have is C, with C++ cruft on top of that, then STL cruft on top of that, then "patterns" cruft on top of that. Not good.
And what is the committee doing? Adding more cruft, in the form of "generic programming". There's a way to abuse the template system into pretending to be a recursive term-rewriting engine which can be used to perform arbitrary computatations at compile time. This is being pursued as a foundation for a new generation of incomprehensible template libraries. (If you've ever had to debug someone else's template, you know how hard it is. Imagine something far worse. If you want to go beyond imagining it, go over to Boost, download something, and try to fix it. Suffer.)
I've written a bit on Strict C++. It's not impossible to fix this. It can almost be made backwards compatible. I don't claim to have all the answers. But at least I'm trying to improve safety and reliability. This is far more important than adding cool features.
Re:Meanwhile, C++ goes nowhere by tyrantnine · 2004-10-11 14:06 · Score: 1

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 by mitch0 · 2004-10-11 21:40 · Score: 1

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

--
// "If human beings don't keep exercising their lips,
// their brains start working." -- Ford Prefect
Re:Meanwhile, C++ goes nowhere by Animats · 2004-10-12 06:31 · Score: 1

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.

And multiple inheritance is due when...? by Anonymous Coward · 2004-10-11 05:02 · Score: 2, Interesting

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

Re:And multiple inheritance is due when...? by peterpi · 2004-10-11 06:49 · Score: 1

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...? by Anonymous Coward · 2004-10-11 07:21 · Score: 1, Informative

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...? by tim_bissell · 2004-10-11 07:57 · Score: 1

Never, please...

Neither Smalltalk nor Self have multiple inheritance and Smalltalk practically defined OO.
Re:And multiple inheritance is due when...? by Anonymous Coward · 2004-10-11 11:21 · Score: 0

BUZZ WRONG!

Java does NOT have MI of IMPLEMENTATION
it DOES have MI of public interface.
Re:And multiple inheritance is due when...? by Anonymous Coward · 2004-10-13 01:37 · Score: 0

And also called cut'n'paste inheritance (because you only inherit the name of the function, not the body)
Re:And multiple inheritance is due when...? by Anonymous Coward · 2004-10-13 01:42 · Score: 0

So, you can reuse (inherit) the 10 lines and only need to reimplement the last 990.

Worst? by McLoud · 2004-10-11 05:03 · Score: 1

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

--
sign(c14n(envelop(this)), x509)

Limitations of Generics in Java. by miguel · 2004-10-11 05:04 · Score: 3, Interesting

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. by nuggetboy · 2004-10-11 05:06 · Score: 1

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. by pjt33 · 2004-10-11 05:25 · Score: 1

Java has events and iterators - or does C# mean something different by them to Java?
Re:Limitations of Generics in Java. by Anonymous Coward · 2004-10-11 05:26 · Score: 0

Those who do not understand C++ are destined to reinvent it poorly.
Re:Limitations of Generics in Java. by Tim+C · 2004-10-11 05:58 · Score: 1

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)

--
It's official. Most of you are morons.
Re:Limitations of Generics in Java. by mrright · 2004-10-11 06:21 · Score: 1

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.

--
Private property is the central institution of a free society (David Friedman)
Re:Limitations of Generics in Java. by fforw · 2004-10-11 06:43 · Score: 2, Informative

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?

--
while (!asleep()) sheep++
Re:Limitations of Generics in Java. by mrright · 2004-10-11 07:29 · Score: 2, Informative

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

--
Private property is the central institution of a free society (David Friedman)
Re:Limitations of Generics in Java. by fforw · 2004-10-11 08:21 · Score: 1

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.

--
while (!asleep()) sheep++
Re:Limitations of Generics in Java. by Tim+C · 2004-10-11 09:43 · Score: 1

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.

--
It's official. Most of you are morons.

Java poor design choices by mmusson · 2004-10-11 05:05 · Score: 2, Insightful

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.

--
SYS 49152

Re:Java poor design choices by Vultan · 2004-10-11 05:13 · Score: 2, Interesting

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:Java poor design choices by Anonymous Coward · 2004-10-11 05:29 · Score: 0

What power are you losing with erasure?
Re:Java poor design choices by Anonymous Coward · 2004-10-11 06:45 · Score: 0

Well one could argue that instanceof is broken now. Something like
v instanceof Vector<String>
is just illegal. Of course,
v instanceof Vector
still works but but what if I want to associate a type with it? Blind casting!

Java generics are just syntatic sugar and that hurts.
Re:Java poor design choices by Anonymous Coward · 2004-10-11 09:07 · Score: 0

Arrays in relation to generics are also broken.

Re:APIs by Anonymous Coward · 2004-10-11 05:06 · Score: 0

Hmmm, not sure what you mean by "native". I think it's safe for you to wake up though:

XML parsers - javax.xml.parsers package (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml /parsers/package-summary.html). If sun's parser is not good enough there is DocumentBuilderFactory and SAXParserFactory that allow for integration of any XML parser (Xerces would be one example).
MD5 hash - java.security package (http://java.sun.com/j2se/1.5.0/docs/api/java/secu rity/MessageDigest.html)

Did I just convert you to java?

Re:APIs by AKAImBatman · 2004-10-11 05:06 · Score: 2, Informative

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.

--
Javascript + Nintendo DSi = DSiCade

Netcraft confirms. by Anonymous Coward · 2004-10-11 05:07 · Score: 1, Funny

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... by Chuck+Bucket · 2004-10-11 05:10 · Score: 2, Informative

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*($#@

--
free ipod and free gmail!

Re:Sounds a lot like religion by Anonymous Coward · 2004-10-11 05:11 · Score: 0

anyone else hear dueling bangos?

Enterprise development by drgroove · 2004-10-11 05:11 · Score: 2, Interesting

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 by Fulcrum+of+Evil · 2004-10-11 05:24 · Score: 1

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?

--
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Re:Enterprise development by ievans · 2004-10-11 08:34 · Score: 1

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.

Java is not only a language by hurricane_sh · 2004-10-11 05:17 · Score: 1, Informative

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 by winfx · 2004-10-11 06:08 · Score: 1

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"

There is a huge difference! by Anonymous Coward · 2004-10-11 05:17 · Score: 0, Troll

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

When you code C# you have memory allocation routines available, thereby making possible malloc errors as MS programmers are want to do. The recent MS jpeg buffer overflow is another example of sloppy C routines! Java classes, on the otherhand are based on the premise that the buffers are a not needed, and the browser should will prevent buffer leaks. The essential difference between the MS way of doing things and the real world is understanding the need for memory security. Sun has always understood this, Microsoft has perverted the interenet with .net stupidity! C# is another attempt by Microsoft to pervert the internet to the extent that only locked down so called "trusted software" will sell. The planned obsolesence scheme created by Gates and Co. is obvious. Too bad so many people do not even realise this bullshit is what MS is all about.

Re:There is a huge difference! by TrancePhreak · 2004-10-11 06:11 · Score: 1

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.

--

-]Phreak Out[-

April 1st? by cthrall · 2004-10-11 05:18 · Score: 2, Insightful

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

Java checked exceptions suck, but how to fix them by The+Pim · 2004-10-11 05:18 · Score: 1

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.

--

The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.

Ravioli Code by Ian+Bicking · 2004-10-11 05:22 · Score: 5, Insightful

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 by metamatic · 2004-10-11 11:04 · Score: 4, Insightful

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.

--
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Re:Ravioli Code by angel'o'sphere · 2004-10-11 11:32 · Score: 1

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:Ravioli Code by metamatic · 2004-10-11 13:35 · Score: 1

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.

--
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Re:Ravioli Code by Matje · 2004-10-11 20:41 · Score: 1

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 by angel'o'sphere · 2004-10-11 23:08 · Score: 1

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:Ravioli Code by metamatic · 2004-10-12 01:50 · Score: 1

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

--
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Re:Ravioli Code by timts · 2004-10-13 07:17 · Score: 1

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.

typo galore! by Anonymous Coward · 2004-10-11 05:22 · Score: 0

In Soviet Russia, /. corrects you!

BS C# is an open source standard by Billly+Gates · 2004-10-11 05:24 · Score: 1

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

--
http://saveie6.com/

Re:APIs by mcbevin · 2004-10-11 05:25 · Score: 1

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: by rts008 · 2004-10-11 05:25 · Score: 1

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

--
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti

I don't use closed source Java... by Anonymous Coward · 2004-10-11 05:26 · Score: 0

...and JVM is an example of bad virtual machine.

Re:I don't use closed source Java... by Anonymous Coward · 2004-10-11 05:31 · Score: 0

And I forgot to add that JVM isn't portable. Python, Perl, Ruby, Schemes, Lisps, C, C++, C#/Mono, ML, Haskell etc. are.
Re:I don't use closed source Java... by Anonymous Coward · 2004-10-11 05:46 · Score: 0

You're a crap troll.

still very different by jeif1k · 2004-10-11 05:27 · Score: 4, Informative

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 by rabtech · 2004-10-11 06:13 · Score: 2, Informative

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.

--
Natural != (nontoxic || beneficial)
Re:still very different by Anonymous Coward · 2004-10-11 06:37 · Score: 0

I am not compentent enough at C# to validate your other arguments.
C# has unsafe modules; in unsafe modules, you can call C functions directly (no JNI) and manipulate C data structures and pointers
I can't see this as a feature. I must be an idiot.
C# does not force you to declare exceptions
Neither does java. java.lang.RuntimeException is an unchecked exception. Every exception that subclasses this exception (instead of java.lang.Exception) is quite throwable even without a declaration. Please check your facts.
Why undeclared exceptions is a good thing for anything but quick and dirty script-style hacks is beyond me. Again, I must be an idiot.
Re:still very different by Anonymous Coward · 2004-10-11 06:48 · Score: 0

I can't see [unsafe modules] as a feature

Well, maybe you personally don't need to write unsafe code, but plenty of people do. The need to do this doesn't just go away because Sun declares it to be so. The only choice Java programmers have is JNI, which is really unsafe and really unportable, in addition to be a lot of work and quite inefficient. C#'s unsafe modules allow you to limit unsafe features to an absolute minimum (maybe just a single pointer access), are far easier to debug, are far more efficient, and are far easier to deploy.

Why undeclared exceptions is a good thing for anything but quick and dirty script-style hacks is beyond me.

Actually, it's the other way around: exception declarations (like those in Java) work in small software systems, but they don't work well for large systems.

Please check your facts.

My facts are perfectly accurate; what you wrote does not contradict what I wrote.

Nor does having some exceptions that can be thrown without declaration make up for the problems resulting from the fact that there are many standard declarations that must be declared.
Re:still very different by Anonymous Coward · 2004-10-11 07:12 · Score: 0

The reason I've need value types in Java: I was building a simulation of a p2p networking protocol. I wanted to simulate a large number of nodes, each with unique data, and I was doing bit manipulations to cram it into tiny space.
But since there were no value types, I had an extra 32 bits for the object pointer. There goes my ram. I switched to C.
I don't see any convenient way around this problem in Java. I've run into similar problems on other projects...in one case, luckily my "struct" fit into 64 bits, so I just used a 64-bit int and pulled my data out by hand, but what a pain.
Basically, any time you have a large number of tiny objects, with unique data for each, it seems to me that Java is going to bite you.
Re:still very different by pjt33 · 2004-10-11 07:34 · Score: 1

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 by jeif1k · 2004-10-11 08:00 · Score: 1

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 by Elwood+P+Dowd · 2004-10-11 08:19 · Score: 1

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?

--

There are no trails. There are no trees out here.
Re:still very different by DrXym · 2004-10-11 08:30 · Score: 1

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 by Bob9113 · 2004-10-11 08:38 · Score: 2, Informative

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.

--
Stop-Prism.org: Opt Out of Surveillance
Re:still very different by Anonymous Coward · 2004-10-11 14:37 · Score: 0

C# does not force you to declare exceptions.

And, therefore, you won't.
Making your application ONLY suitable to run on Windows, where Crashing Applications are Expected.

Operator Overloading:
- Symbols vs. English.
- 2 finger typists vs. Qwerty Typists.
- complex unintelligent vs. simple clearly understood English method names

Java doesn't have multi-dimensional arrays?

Unboxing: With Microsoft you'd better what out, everything a Microsoft compiler does for you may very well be broken. Good Luck.

JNI: Means Microsoft can Force you to call the C API after they get tired of writing .Net classes. Just like they did in MFC. Abandoned it and it's C++ librarys.
Re:still very different by jeif1k · 2004-10-11 14:46 · Score: 1
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 by jeif1k · 2004-10-11 15:06 · Score: 1

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:still very different by Anonymous Coward · 2004-10-11 15:33 · Score: 0

Operator Overloading:
- Symbols vs. English.
- 2 finger typists vs. Qwerty Typists.
- complex unintelligent vs. simple clearly understood English method names
Consider the following obviously contrived example:
A a, b, c; D d, e, f; G g, i; H h, j; //"simple clearly understood English method names" c = a.plus(b); f = d.add(e); i = g.plus(h); j = h.add(g); //"complex unintelligent" c = a + b; f = d + e; i = g + h; j = h + g;
Which is simpler? With operator overloading, I have pre-defined mathematically standard symbols to use. I know that if I want to add, I use the binary + operator. With "simple" English method names, did this class name the method plus, add, or what? For a String, where it's fairly well accepted to use += to append something to the end, is the "simple" method name append, concatenate (which I may or may not have even spelled correctly), cat (after the UNIX utility because the full word is long and not so easy to spell), or something else the author thought would be a good idea? A simple set of mathematical symbols are easier to wrap your brain around than the nearly infinite possiblity of English based names.

Re:Sounds a lot like religion by AvitarX · 2004-10-11 05:28 · Score: 3, Informative

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.

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg

Plenty of differences by flakac · 2004-10-11 05:28 · Score: 2, Insightful

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 by Deadbolt · 2004-10-11 06:49 · Score: 4, Informative

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

--
"Honey, it's not working out; I think we should make our relationship open-source."
Re:Plenty of differences by slyckshoes · 2004-10-11 06:54 · Score: 2, Insightful

"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 by fforw · 2004-10-11 06:58 · Score: 1
- 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 .
--
while (!asleep()) sheep++
Re:Plenty of differences by Anonymous Coward · 2004-10-11 07:02 · Score: 0

C# is just another option for developing for .NET.

The only difference between C# and VB.Net et al are minor syntax changes and default implicit imports. Other than that, they are pretty much all the same. I don't see how having multiple variations of the same language benefits anybody.
Re:Plenty of differences by pjt33 · 2004-10-11 07:39 · Score: 1
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 by Anonymous Coward · 2004-10-11 15:58 · Score: 0

I agree that here you have to take care, but requiring care isn't the same as being difficult.
But you can't have real pointers in Java because they're dangerous and require care. Why is it okay to require care sometimes but other times it makes you the scum of the earth?
Re:Plenty of differences by pjt33 · 2004-10-11 20:54 · Score: 1

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:Plenty of differences by Anonymous Coward · 2004-10-13 05:31 · Score: 0

> are many other languages which run in the java
> VM

Not really. Kawa for example is missing important language concepts because these concepts cannot be implemented in java bytecode.

As a side-note: The following simple schem code will crash the JVM's (IBM JDK1.4.1):

(define (f v) (if (= 0 v) 1 (f (- v 1)))
(f 10000)
==> VM crash

Note that the above crash happens even though kawa is implemented in pure java and does *not* use native code (like other implementations). .NET is much better but still not optimal. For example MONO/.NET could be improved to support dynamic languages better.

Re:Java 1.5 vs c# 2.0? Full of shit by Anonymous Coward · 2004-10-11 05:29 · Score: 1, Informative

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:APIs by EmperorKagato · 2004-10-11 05:34 · Score: 2, Funny

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.

--
----- You know you have ego issues when you register a domain in your name.

you're confused by jeif1k · 2004-10-11 05:36 · Score: 1

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.

Re:you're confused by Anonymous Coward · 2004-10-11 06:30 · Score: 0

" 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."
Therein lies the problem. The whole idea of Java was to isolate the os from internet traffic. MS has perverted this concept. The implications are that a locked down Longhorn computer will be the only solution to .net stupidity. Microsoft is very good at planned obsolesence, they make the auto industy look benign!
Re:you're confused by Anonymous Coward · 2004-10-11 07:50 · Score: 0

Therein lies the problem. The whole idea of Java was to isolate the os from internet traffic.

There is no problem, since C# provides exactly the same kind of isolation: applets in C# are prevented from using unsafe code.

What C# gives programmers is a better, safer, more portable way of writing JNI code, and that's a really good thing.

MS has perverted this concept. The implications are that a locked down Longhorn computer will be the only solution to .net stupidity.

You don't know what you are talking about.

IT... by johnhennessy · 2004-10-11 05:37 · Score: 1

Hmmm, In a way I'm happy this was placed under "IT" instead of "Developers".

--
[ Monday is a terrible way to spend one seventh of your life. ]

Can you please clarify.. by Anthony+Liguori · 2004-10-11 05:39 · Score: 1

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! by Oestergaard · 2004-10-11 05:40 · Score: 4, Insightful

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! by Anonymous Coward · 2004-10-11 06:14 · Score: 1, Interesting

>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! by Anonymous Coward · 2004-10-11 06:37 · Score: 1, Informative

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! by t'mbert · 2004-10-11 08:19 · Score: 1

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! by Anonymous Coward · 2004-10-11 08:22 · Score: 0

In regards to build systems, C++ name mangling makes for total hell for using it in any sort of API, making closed-source API's nearly impossible under gcc. Hence if you use C++, your API had better be C. Templates contribute to harder to debug code, and I don't know exactly what problem pass-by-reference is designed to solve. So you CAN write good C, just follow one of the pseudo-OO idioms, and life can be good. Sadly, binary interfaces and efficient use of structures is a lost art in this age of self-absorbed java-programmers who think they can write tameable C++. They really can't.
Re:Welcome stranger! by Anonymous Coward · 2004-10-11 08:42 · Score: 0

Woah chief, re: your use of sarcasm in parent, way to use a sledgehammer when a flyswatter would have done the work. That's how we know you truly are a C++ programmer.
Re:Welcome stranger! by Elote · 2004-10-11 08:50 · Score: 1

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! by Oestergaard · 2004-10-11 09:43 · Score: 1

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! by Oestergaard · 2004-10-11 09:49 · Score: 1

To the bone girl. To the bone :)
Re:Welcome stranger! by sploxx · 2004-10-11 13:13 · Score: 1

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! by Anonymous Coward · 2004-10-11 14:29 · Score: 0

Clueless...

That's why I left C++, the clueless fools who would refuse to use the String class. Plus, refuse to do bounds checking on their Char Arrays. This is what Killed C++.
Plus, the memory leaks.
Re:Welcome stranger! by Anonymous Coward · 2004-10-11 14:58 · Score: 0

pass-by-reference is designed to solve this problem:

void foo(int * const x, int * const y, int * const z);
int someint(void);

int main() {
int x, y, z;

x = someint();
y = someint();
z = someint();

foo(&x, &y, &z);

return 0;
}

Sure, it's not much of a problem, but generalize it to when I need a constant pointer to a pointer to a pointer and I have a pointer to a pointer, and it becomes useful to not have to take the address of a variable to have it changed by a function. You don't have to like it, and you don't have to use it, but it is there for a reason.
Re:Welcome stranger! by archeopterix · 2004-10-12 01:14 · Score: 2, Insightful

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! by Oestergaard · 2004-10-12 01:33 · Score: 1

?

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

More Features != Better Language by Anonymous Coward · 2004-10-11 05:41 · Score: 2, Interesting

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!

Re:More Features != Better Language by Anonymous Coward · 2004-10-11 07:13 · Score: 0

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.
This is a retarded statement. In reality, Java may have 1 right way and C++ may have 3 right ways, but every language has an infinite number of wrong ways to do something. Furthermore, the fact that Java has 1 "right way" to do something is not necessarily a feature if the "right way" is actually less than optimal. I'd rather have 1 right way, and 2 acceptable ways than 1 acceptable way and no right way. Containers in Java 1.4 had no right way.

C# and Java are so similar.... by Manitcor · 2004-10-11 05:42 · Score: 2, Informative

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.

--
"Don't mess with him, he taunts the happy fun ball."

Re:Java checked exceptions suck, but how to fix th by Gr8Apes · 2004-10-11 05:44 · Score: 1

This actually sounds like a good use of annotations.

--
The cesspool just got a check and balance.

Re:APIs by DevolvingSpud · 2004-10-11 05:44 · Score: 1

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

--
Keep your friends close.
Keep your enemies in a little jar on your desk.

Step in the wrong direction by Anonymous Coward · 2004-10-11 05:45 · Score: 0

So what ideal is java 1.5 aiming towards C++??
Why is having generics MORE OO??

Smalltalk didn't have all this junk and was a better language.

The nice thing about Java was that it didn't have stuff like Generics in it.

More features doesn't necessarily make a language better.

Re:APIs by jchoyt · 2004-10-11 05:46 · Score: 2, Interesting

I sincerely apologize for feeding troll. :oD

--
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.

Lingua Ipse by Anonymous Coward · 2004-10-11 05:46 · Score: 0

I admire C# for the language itself, considered apart from any platform that consumes it. It's just a clean, non-obtrusive language that I'd prefer to use regardless of library or machine.

Of course it's true that in real life you have to consider those issues, but there's something to be said for admiring languages themselves. Heck, just look at Haskell.

Available platforms are mere accidentals of history.

Re:Fair and Balanced by Anonymous Coward · 2004-10-11 05:46 · Score: 0

Thank you Mr. Microsoft fanboy. It goes both ways. There are Linux fanboys and there are Windows fanboys. Then there are those of us who actually work for a living and use ALL OSes with each suited to it's task. I work with Windows, Linux, OpenBSD, Solaris, HP-UX, Mac OS X, Tru 64, OpenVMS, Cisco IOS every day. so why don't you fucks shut the hell up and go suck each other's cocks since that's what this is REALLY all about. Meanwhile, the rest of us will get on with the business of doing real work. Fuckers. (Sorry. It had to be said because it's the truth.)

You will see the difference ... by Anonymous Coward · 2004-10-11 05:48 · Score: 0

... between Java and C# when you try to find a job with your C# skills. All good paying jobs are in Java and there is a lot more Java jobs than C#. That's a very important factor.

My great OSS projects are done in Java, very few C#.

Still want to code in C#? Well, good luck, you'll need it.

java sucks by Anonymous Coward · 2004-10-11 05:50 · Score: 0

java sucks

Re:APIs by AKAImBatman · 2004-10-11 05:52 · Score: 1

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

--
Javascript + Nintendo DSi = DSiCade

How exactly is Java "OO from the ground up"? by argent · 2004-10-11 05:53 · Score: 2, Insightful

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

SunOS/Solaris by perdu · 2004-10-11 05:54 · Score: 1

Well, this is the company that gave us the SunOS 5.8 === Solaris 2.8 rigamarole...

--
You only use 2% of your DNA

Re:SunOS/Solaris by Nexx · 2004-10-11 15:23 · Score: 1

No, Solaris 7, Solaris 8. Last of the Solaris 2's was Solaris 2.6 :)

there is a difference by RoninSix · 2004-10-11 05:56 · Score: 1, Informative

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

--
"Two wrongs don't make a right. But three rights make a left!" - Cosmo, "The Fairly Odd Parents"

not cross platofrm by SQLz · 2004-10-11 05:58 · Score: 1

...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 by mcc · 2004-10-11 05:58 · Score: 1

That he trashes C#/Java for requiring virtual machines, then suggests instead people use PHP/Perl... both of which are interpreted languages.

...

What?

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

Re:I'm just amused by PierceLabs · 2004-10-11 06:54 · Score: 1

Stop it - you'll make him cry :)

April 1st Article by Anonymous Coward · 2004-10-11 05:58 · Score: 0

That kind of "article" is somewhat funny on April 1st, but seriously I see no point in posting that here and now.

This looks like a bad joke, and a total lack of regard for the above average intellect of Slashdot readers.

Quick summary of the comments by raider_red · 2004-10-11 06:00 · Score: 2, Funny

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.

--
It's good to use your head, but not as a battering ram.

Re:Quick summary of the comments by fimbulvetr · 2004-10-11 06:44 · Score: 1

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 by blue+trane · 2004-10-11 12:27 · Score: 1

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? by dpw2atox · 2004-10-11 06:05 · Score: 2, Insightful

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.

Re:Sounds a lot like religion by Anonymous Coward · 2004-10-11 06:08 · Score: 0

While offtopic, this is easily the most interesting comment in this story. Thank you.

Parent is wrong by mortenmo · 2004-10-11 06:08 · Score: 1

You can freely download Java 1.5/Java 5 for no charge. It's available now.

Re:Java C# porting - Lucene as example by Anonymous Coward · 2004-10-11 06:08 · Score: 0

There's also Nant, which implements the Ant build system, and Nunit, which is a .net implementation of the Junit java unit testing framework. I'l still sticking with Java though because I get to use Eclipse and Resin. It doesn't hurt that all these open source packages come out for Java first either.

Among other things by mcc · 2004-10-11 06:12 · Score: 1

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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

Reflection? by Anonymous Coward · 2004-10-11 06:12 · Score: 0

Does Java have it or a similiar feature? If not, then it still has a way to go to catch up.

Re:Reflection? by jekewa · 2004-10-11 10:18 · Score: 1

Yes.
import java.lang.reflect.*;

--
End the FUD
Re:Reflection? by jekewa · 2004-10-11 10:21 · Score: 1

I suppose this is better. Or this, for the JDK 5 documentation...

--
End the FUD

The java generics system is a joke by mrright · 2004-10-11 06:13 · Score: 2, Insightful

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.

--
Private property is the central institution of a free society (David Friedman)

Re:The java generics system is a joke by mdemirha · 2004-10-11 07:08 · Score: 1, Informative

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 by mrright · 2004-10-11 07:37 · Score: 1

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

--
Private property is the central institution of a free society (David Friedman)
Re:The java generics system is a joke by jekewa · 2004-10-11 10:44 · Score: 1

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."); } }

--
End the FUD
Re:The java generics system is a joke by mlk · 2004-10-11 11:04 · Score: 1

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.

--
Wow, I should not post when knackered.
Re:The java generics system is a joke by Big_Mamma · 2004-10-11 13:51 · Score: 1

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 by rewt66 · 2004-10-11 06:19 · Score: 4, Interesting

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 by 3770 · 2004-10-11 06:20 · Score: 1

Java is free, MS VS Express products wont be.

--
The Internet is full. Go Away!!!

Java Generics do NOT eliminate ClassCastExceptions by Anonymous Coward · 2004-10-11 06:25 · Score: 0

> Generics improve testability because they
> largely eliminate runtime ClassCastExceptions.

Depends on the implementation. Your statement is correct for C# generics, but not for java generics.

Java generics are just syntactic shugar, they do *NOT* eliminate runtime ClassCastException.
Furthermore java generics are not visible via reflection for example.

Re:The language doesn't matters, it's the platform by j3thr0 · 2004-10-11 06:25 · Score: 0

Every company in existence says "Here's our product, it's better than what you're using because we say so, and you should use it"

Regardless of what Microsoft and/or Sun says, you can always USE WHATEVER LANGUAGE YOU WANT

I can't think of a single "standard" that isn't controlled by some weird committee.

--
I'm schizophrenic; no I'm not.

pine? mutt by flok · 2004-10-11 06:28 · Score: 3, Funny

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

You must have meant, of course mutt.

--

www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi

Re:pine? mutt by julesh · 2004-10-11 19:48 · Score: 1

mutt? MUTT?

elm, I'll have you know.

JNI by Anonymous Coward · 2004-10-11 06:29 · Score: 1, Informative

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 by Anonymous Coward · 2004-10-11 06:36 · Score: 1, Interesting

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 by Anonymous Coward · 2004-10-11 07:20 · Score: 0

Unsafe code is just that - unsafe. Since C# is pretty much locked into a single platform anyway, it might just work, but don't pretend that this is anything portable - it will never be portable anywhere except for MS-Intel, unless you're willing to write platform dependent code. Same goes for Java, except in Java it's way more obvious.
Re:JNI by freshtonic · 2004-10-11 09:32 · Score: 1

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 by mlk · 2004-10-11 11:14 · Score: 1

I wish Sun used CNI.

I'm a pro-Sun/Java kind-of guy, but JNI is bad.

So is static import.

--
Wow, I should not post when knackered.
Re:JNI by Anonymous Coward · 2004-10-13 05:36 · Score: 0

> Portable?! Um... yeah portable accross all
> Windows platforms

Portable accross all .NET platforms, of cause.

Currently these are BSD, Win, Linux and MacX

> depends on what you do inside the unsafe code

The above statement is nonsense. You generally call the P/Invoke within a switch(OS) {... }statement.

You can: kuro5hin.org by freality · 2004-10-11 06:29 · Score: 1

Just when i start reading /. for a few days again, i'm reminded why it's so easy to drift........ away......

Generics DO NOT improve testability by Anonymous Coward · 2004-10-11 06:31 · Score: 0

Testability is the ability to test. It has nothing to do with the preponderance or lack of ClassCastExceptions.

How many ClassCastExceptions have you had to deal with in Java anyway?

It is very very very rare in the code I've had to deal with.

Hacking all the bloody libraries and complicating all the code is not a way to make your code reliable.

It was a marketing decision. Pure and simple. Because there are a lot of simple minded developers (or those without a formal University education) that think that more language features automatically means better.

There wrong.. see C++ for evidence.

Rules on languages... by feloneous+cat · 2004-10-11 06:34 · Score: 2, Interesting

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.

--
IANAL, but I've seen actors play them on TV

Re:Rules on languages... by shish · 2004-10-11 11:55 · Score: 1

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

--
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment

Re:APIs by SnapShot · 2004-10-11 06:35 · Score: 1

dom4j vs. jdom, the vi vs. emacs of the Pepsi generation ;-)

--
Waltz, nymph, for quick jigs vex Bud.

For me C# doesn't matter yet by buttkick · 2004-10-11 06:36 · Score: 1

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 by buttkick · 2004-10-11 06:40 · Score: 1

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.

It's the installation stupid by nzgeek · 2004-10-11 06:37 · Score: 3, Informative

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.

--
gadgetophile.com

The biggest problem with C# is by donbrock · 2004-10-11 06:37 · Score: 0

it's Microsoft.

--
The Truth About Slashdot

They got him! by Anonymous Coward · 2004-10-11 06:38 · Score: 0

Osama bin Laden has been captured!

Unsigned types, yet? by Anonymous Coward · 2004-10-11 06:39 · Score: 0

That's all well and good.. but I would've been much happier if they had unsigned types. I mean, who invents a new language, touts it as the be-all-and-end-all, yet doesn't offer unsigned types?

Sigh, I'm going out for some Glühwein.

Re:Sounds a lot like religion by Anonymous Coward · 2004-10-11 06:40 · Score: 0

A: de-da-dee-da-dee-da-dee-da-dee.

B: de-da-dee-da-dee-da-dee-da-dee.

A: de-dum-di-di-dum-dee-dee-da-dee.

B: de-dum-di-di-dum-dee-dee-da-dee.

A: dim-dum-diddle-y-dum-di-da-dum.

B: Monkey Island III van Halen track.

Re:Parent is right but referring to the wrong thin by Knetzar · 2004-10-11 06:43 · Score: 1

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 by blowdart · 2004-10-11 06:43 · Score: 1

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 by The+Pim · 2004-10-11 06:45 · Score: 1

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.

--

The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.

You're going to name it what?! by richever · 2004-10-11 06:47 · Score: 5, Informative

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?! by p2sam · 2004-10-11 10:35 · Score: 3, Insightful

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 by Cereal+Box · 2004-10-11 06:51 · Score: 1

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 by 21mhz · 2004-10-11 06:53 · Score: 1

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.

--
My exception safety is -fno-exceptions.

Re:Bad coding habits by Anonymous Coward · 2004-10-11 09:28 · Score: 0

-- Lisp fans have an amazing success story behind them: Emacs. 25+ years and still perfectly unusable.

Only unusable if you are a complete jackass idiot..
Re:Bad coding habits by blue+trane · 2004-10-11 12:35 · Score: 1

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 by 21mhz · 2004-10-12 00:03 · Score: 1

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.

--
My exception safety is -fno-exceptions.

matryoshka programming by 4of12 · 2004-10-11 06:57 · Score: 1

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

--
"Provided by the management for your protection."

Partly agree by Hortensia+Patel · 2004-10-11 07:00 · Score: 1

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 by Animats · 2004-10-11 16:20 · Score: 1

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

Next up on Slashdot... by Liquid+Len · 2004-10-11 07:07 · Score: 1

Religion: Which is the One True Faith?

(Stolen from snpp.com)

Re:Next up on Slashdot... by mlk · 2004-10-11 11:01 · Score: 1

Religion: Which is the One True Faith?

Emacs. :D

--
Wow, I should not post when knackered.

With Java, stuck in Windows/Linux/Solaris by RdsArts · 2004-10-11 07:08 · Score: 2, Informative

"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 by shaper · 2004-10-11 07:55 · Score: 4, Interesting

If it's a choice of language based solely on the portablity of code, C# wins out IMHO. With Java, you're dependant on Sun to support your system, which is a royal pain. (as anyone with a *BSD box will tell you)

I run a J2EE application on WebSphere on a mainframe under OS/390. Where's .Net for OS/390? I can (and have) also deploy that same application with zero changes to Linux, Windows, Solaris, AS/400 or Mac OS X. I can choose from a number of J2EE implementations like WebSphere, WebLogic, JBoss or Resin, each of which have different features and strengths. I don't even recompile, I just drop in the WAR and go.

And it is incorrect to say that you are dependent on Sun to support your system. Independent vendors like IBM, BEA and Apple also license and support J2SE and J2EE for their own platforms. My personal systems are Macs and I get my Java from Apple, not Sun. My corporate systems are IBM and I get my corporate Java from IBM, not Sun. If I have a problem with either, I don't call Sun, I call Apple or IBM. IBM provides my production support contract. IBM are the ones who responded with a custom patched version of WebSphere for OS/390 in less than 24 hours when I had a production problem. Not Sun.
Re:With Java, stuck in Windows/Linux/Solaris by Anonymous Coward · 2004-10-11 11:29 · Score: 0

Last I checked Mono does not plan to be full compatable with the CURRENT version of .NET for around 5 years! That is not acceptable for Enterprise.

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)

*BSD is not supported by Sun, but then nor is Apple, IBM, and a host of other systems.
While FreeBSD is supported by MS, but the lience states that you can not use it for Enterprise.
Re:With Java, stuck in Windows/Linux/Solaris by Anonymous Coward · 2004-10-11 13:46 · Score: 0

Even worse, check out what Sun is doing with J2ME/CLDC/MIDP on mobile devices. They're optimizing to one platform: ARM with their "Hotspot for CLDC"

WORA = Will Only Run on ARM
Re:With Java, stuck in Windows/Linux/Solaris by kaffiene · 2004-10-11 15:37 · Score: 1

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 by Anonymous Coward · 2004-10-11 16:06 · Score: 0

With Mono/XSP you have support on OS/390 too :)
http://www.go-mono.com/
Re:With Java, stuck in Windows/Linux/Solaris by Joseph_Daniel_Zukige · 2004-10-11 20:45 · Score: 1

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 by RdsArts · 2004-10-12 11:21 · Score: 1

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? by Matt+Ownby · 2004-10-11 07:12 · Score: 1

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? by Anonymous Coward · 2004-10-11 07:22 · Score: 1, Interesting

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? by spacecowboy420 · 2004-10-11 07:23 · Score: 2, Insightful

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.

--
ymmv
Re:and how is this insightful? by dtfinch · 2004-10-11 08:11 · Score: 1

Dotgnu is starting to look pretty good. Installed it last week.
Re:and how is this insightful? by angel'o'sphere · 2004-10-11 11:42 · Score: 2, Interesting

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:and how is this insightful? by angel'o'sphere · 2004-10-11 11:45 · Score: 1, Troll

hm ... I allready posted, so it makes no sense to use my mod points here, can someone please correct teh TROLL rating on parent?

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:and how is this insightful? by ckaminski · 2004-10-11 13:03 · Score: 2, Insightful

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? by ckaminski · 2004-10-11 13:06 · Score: 1

tell me more about this gdb-mode swami?
Re:and how is this insightful? by chefren · 2004-10-11 19:05 · Score: 1

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? by generalpf · 2004-10-12 07:53 · Score: 2, Informative

You press CTRL-Break. It's undocumented but it works, even when you're surrogate-debugging a COM object.

Beta by Anonymous Coward · 2004-10-11 07:16 · Score: 0

You can see C# 2.0 for free in its beta form right now. Go to msdn.microsoft.com, search for .NET 2.0.

Re:Parent is right but referring to the wrong thin by 3770 · 2004-10-11 07:17 · Score: 1

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.

--
The Internet is full. Go Away!!!

Language differences? by Jugalator · 2004-10-11 07:21 · Score: 1

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.

--
Beware: In C++, your friends can see your privates!

C#? by NeoGeo64 · 2004-10-11 07:26 · Score: 1

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:C#? by Anonymous Coward · 2004-10-11 10:57 · Score: 0

C# is an OOP language.
C++ is a procedual language with Objects superglued on top ;)

Re: Generics by rreyelts · 2004-10-11 07:33 · Score: 1

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 by Anonymous Coward · 2004-10-11 07:36 · Score: 1, Interesting

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>

Why the Paul Graham stuff? by Anonymous Coward · 2004-10-11 07:36 · Score: 0

I know that Paul Graham has said some seemingly negative stuff directed towards Java but get over it. Why include him in the initial post here? There are a lot of well known people that do not or refuse to use Java but do you single them out? Being petty certainly will not help your cause.

And oh yeah, Lisp RULEZ!!!!!!

SQLServer cheap?!? by Anonymous Coward · 2004-10-11 07:41 · Score: 0

SQLServer is about the same price as Oracle these days--- either per named user or CPU. Depending on your application, neither of them is anything like 'cheap'. So, yeah, not supporting other DBs is a big drawback.

Where can I get C#? by SamSeaborn · 2004-10-11 07:42 · Score: 1

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#? by ChatHuant · 2004-10-11 08:07 · Score: 3, Informative

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? by Anonymous Coward · 2004-10-11 07:48 · Score: 1, Interesting

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!!!! by CaptainPinko · 2004-10-11 07:49 · Score: 1

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.

--
Your CPU is not doing anything else, at least do something.

OT: by SirTalon42 · 2004-10-11 07:51 · Score: 0, Offtopic

Before I found out it was 'C Sharp' I thought it was 'C Number'.

Are you nuts?!? by Anonymous Coward · 2004-10-11 07:53 · Score: 0

Is this a joke?!? There is ***NO SINGLE BENEFIT*** in using C#! Since the nature of it is proprietary, there is virtually ***NO REASON*** to use it.
So, stop blabbering about comparison, there could hardly be any, we are talking about Windows toy-platform here. I was once a Microsoft developer (gizz what a horror), and pray not to be forced to do it again.

Not sure wht you were getting at but... by SuperKendall · 2004-10-11 07:59 · Score: 1

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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Except you got exceptions wrong by SuperKendall · 2004-10-11 08:04 · Score: 1

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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Re:Except you got exceptions wrong by jeif1k · 2004-10-11 14:55 · Score: 1

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... by ^BR · 2004-10-11 08:09 · Score: 1

...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 by deuterium · 2004-10-11 08:13 · Score: 2, Interesting

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.

Re:Apples and Oranges by Anonymous Coward · 2004-10-11 08:36 · Score: 0

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.
I would have to agree, except that what ends up happening from first hand experience is this.
1. management hires bad programmers.
2. bad programmers rely on VS.NET to do most of the work for them.
3. end result is the code written by the programmers is throw away and is constantly rewritten with each version.
4. at some point, the cost of maintenance of the application is 85%. the company is no longer competative, because the programmers still suck. they were bad to begin with and the tool encourages lazy coding.
5. company goes belly up, once customers realize the product is horrible and completely inflexible.

I just spent over a year trying to fix exactly this kind of situation. The end result is the project is doomed and the company is just buying time. Once someone builds a solid competing product, doing it the VS.NET wizard way becomes a horrible mistake. What's worse, only way to save the company is to fire entire teams and invest in experience hardcore developers to re-architect the product and build it better.

varargs is *not* an enhancement by hopethishelps · 2004-10-11 08:23 · Score: 3, Interesting

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 by rreyelts · 2004-10-11 10:50 · Score: 1

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 by anarxia · 2004-10-11 11:06 · Score: 1

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 by Anonymous Coward · 2004-10-11 13:10 · Score: 0

Heaven forbid you be able to define a function that operates on multiple arguments. This may well be bad style in C++ where the compiler is too stupid to type check the arguments, but once you fix that, variable arguments are very nice. Of course, Lisp programmers have been able to do this for 40 years...
Re:varargs is *not* an enhancement by barrkel · 2004-10-12 23:32 · Score: 1

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.

Double Duh!! by Nom+du+Keyboard · 2004-10-11 08:34 · Score: 1

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.

--
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."

Re:Java checked exceptions suck, but how to fix th by Anonymous Coward · 2004-10-11 08:34 · Score: 0

Catching an exception that can't happen IS reckless, agreed. Sometimes you want these out-of-the-blue exceptions to go higher up in the app and be logged 8-levels up. If so, you should not have to keep passing them off like a bucket-brigade. This is why checked exceptions are a failed attempt. Syntax should not be neccessary to ditch them though, we need java in the next version to DROP them altogether! Features designed to stiffle programmers that do not in themselves produce benefit often restrain actual development without addign safety. Many people write empty catch blocks and should instead write adapters to convert exceptions to subclasses of RuntimeException...

Go Read This by cthrall · 2004-10-11 08:39 · Score: 1

http://blogs.msdn.com/cyrusn/archive/2004/10/11/24 0673.aspx

Then tell me how much you want to push C# to production.

Paul Graham sez... by Anonymous Coward · 2004-10-11 08:42 · Score: 0

he doesn't know any good hackers who prefer Java. That probably goes for C# too.

Neither of the languages holds a candle to Common Lisp or Prolog.

What really sucks... by argent · 2004-10-11 08:56 · Score: 1

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 by chiph · 2004-10-11 09:04 · Score: 2, Interesting

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.

Real Control by Anonymous Coward · 2004-10-11 09:23 · Score: 0

I'll stick with my assembler and linker.

Foo-foo bloat language drunkards...

Java:JVM != .NET:C# by DoubleReed · 2004-10-11 09:25 · Score: 2, Informative

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? by the-build-chicken · 2004-10-11 09:25 · Score: 1

Anyone?

which in turn makes me remind of another joke :) by Anonymous Coward · 2004-10-11 09:46 · Score: 0

as seen on /. :

-"Yes, some things are just way more scary than Java the Hut." (typo or something)
-"Like what? C# the Hut?"
-"That character from Episode 1.0 is scary, you know, .jar .jar /bin"

Re:Sounds a lot like religion by puddpunk · 2004-10-11 10:20 · Score: 1

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? :)

MOD PARENT UP by Anonymous Coward · 2004-10-11 10:26 · Score: 0

Seeing as it could well be the best informed post in the entire article's comment mishmash.

Also, I had no idea that Java had enums. Care to elaborate? All I've seen so far has been a bunch of "public static final int"s in a class, and those are a pain in the ass to deal with.

Re:APIs by Anonymous Coward · 2004-10-11 10:27 · Score: 0

Any other features you'd like me to find for you?

Yes, where do I find the "don't suck" feature?

I'm kidding...

C#2.0 and IDEs by shodson · 2004-10-11 10:34 · Score: 2, Interesting

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 by AngryScot · 2004-10-11 10:35 · Score: 1

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

--

All spelling mistakes are due to solar flares...honest

Re:APIs by Rudeboy777 · 2004-10-11 10:52 · Score: 1

where do I find the "don't suck" feature?

Found it!

--

From hell's heart I fstab at /dev/hdc

Operator overloading by evilpenguin · 2004-10-11 11:25 · Score: 3, Informative

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 by Anonymous Coward · 2004-10-11 14:06 · Score: 0

Uh, Java doesn't Lack a Currency class, It's had BigDecimal for years.
Re:Operator overloading by evilpenguin · 2004-10-12 02:14 · Score: 1

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 by kfg · 2004-10-11 11:28 · Score: 1

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 by kfg · 2004-10-11 11:31 · Score: 1

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 by Cereal+Box · 2004-10-11 11:45 · Score: 1

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.

1.5 still J2SE by Anonymous Coward · 2004-10-11 11:49 · Score: 0

So when do we get a J2EE upgrade to the new API? I figured that would be a more important question.

Re:Fair and Balanced by Anonymous Coward · 2004-10-11 12:02 · Score: 0

Like CNN and the other news outlets are "fair and balanced"? Fox news makes a concerted effort to be fair by giving both sides equal "fair" air time. This is something most other agencies fail to even attempt unless the equal airtime is positive for the left and negative for the right. You pick on Fox because unlike the rest of the media it doesn't spew out only the news that fits your beliefs. Just because it isn't what you believe doesn't make it incorrect. Nor does it make it slanted.

Open your eyes and pay attention to wording. Most telivised media will word things or omit words in such a way as to mislead and slant towards one side. If you take off your blinders you will notice that most outlets have slant and of those more then not are to the left.

.Not is as buggy and full of holes like IE by Anonymous Coward · 2004-10-11 12:21 · Score: 0

.Not is nothing more than COM /Activex full of bugs, buffer over flow and security nitemare. .Not scalability is like VB.

In praise of C++ by Baudelaire76 · 2004-10-11 12:29 · Score: 1

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 by mosel-saar-ruwer · 2004-10-11 12:36 · Score: 1

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? by nitehawk214 · 2004-10-11 13:00 · Score: 1

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.

--
I'm a good cook. I'm a fantastic eater. - Steven Brust

Bias article? by AstroDrabb · 2004-10-11 13:12 · Score: 2, Insightful

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.

--
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison

101 reasons why Java is better than dotNet by Anonymous Coward · 2004-10-11 13:16 · Score: 1, Informative

this guy wrote an interesting list.

read the 101 reasons
here

Let's see... by Anonymous Coward · 2004-10-11 13:24 · Score: 0

There are 3 parts to a language:

1. The syntax
2. The type system
3. The evaluation model

All 3 parts of C# are based on Java, not Delphi. Let me break it down:

1. Syntax: there are two main styles of syntax, Pascal and C. Delphi is Pascal based, while Java is C based. From C, the object oriented constructs have been added in different styles: there's C++ style, and there's Java style (and there are others). C# is Java based.
2. Type system: the Java language made some unique design decisions for their type system: interfaces (which C# copied), a distinction between primitive and reference types (perhaps a mistake, but nevertheless which C# copied and provided a workaround in the form of autoboxing), covariant array types (a mistake! which C# also copied!), and types indexed by name and class loader (which C# copied).
3. Evaluation model: the core ideas were again copied from Java to C#. In particular, Java's evaluation model restricted the language to single inheritance, and C# decided to follow Java's lead and do the same thing. Java's class loaders, perhaps Java's best feature, which allow dynamic loading of new code in a type safe way, was also copied into C#. And this is what gives it away. More than syntax, or virtual machines, or libraries, this is the one feature that sets Java apart from any other language. Well, apart from C#, of course, which copied class loaders from Java.

Now, maybe someone else can help me out here, but I also have a sneaking suspicion that C# also uses a constant pool per class file, and has pretty much the same class loading algorithm and method dispatch algorithm.

Last time I checked, it looked like the C# and Java syntax were identical for the hello world program, except for the different way to declare the package/namespace of the class, and the fact that C# uses an uppercase "M" for its main method instead of java's lowercase "m". Other than that, the same program would compile in both languages. The basic class declaration syntax and method declaration syntax is the same, down to the public static void main(...) {}. The modifiers are the same. Certainly it wouldn't take much to make a largish Java program compile under the C# compiler.

Computer science = abstract + conquer! by j.leidner · 2004-10-11 13:40 · Score: 1

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.

What is happening? by Anonymous Coward · 2004-10-11 14:01 · Score: 0

First, two sugar languages, Boo and Groovy. Then three other: Scala for JVM, Nemerle for MSIL and Felix (sourcefore) against C++. Is it a new program paradigm apearing?

Awesome stuff by randymorin · 2004-10-11 14:21 · Score: 1

I'm still praying that Java survives.

Exceptions... by r6144 · 2004-10-11 14:40 · Score: 2, Interesting

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... by Oestergaard · 2004-10-11 22:35 · Score: 1

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:Sounds a lot like religion by Anonymous Coward · 2004-10-11 15:01 · Score: 0

Your response to my post, sir, is the sanest that I've read.

Re:Fair and Balanced by slickwillie · 2004-10-11 15:12 · Score: 1

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 by kaffiene · 2004-10-11 15:17 · Score: 2, Informative

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. by Trejkaz · 2004-10-11 15:28 · Score: 1

So exactly like add*Listener and remove*Listener methods, just with different syntax.

--
Karma: It's all a bunch of tree-huggin' hippy crap!

Irrellevant by kaffiene · 2004-10-11 15:33 · Score: 1

Those certifications do not prevent it being patent encumbered.

Vi for Eclipse by Trejkaz · 2004-10-11 15:35 · Score: 1

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?

--
Karma: It's all a bunch of tree-huggin' hippy crap!

C# vs Java vs Python vs whatever by NullProg · 2004-10-11 16:23 · Score: 1

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

--
It's just the normal noises in here.

Innovations? by descubes · 2004-10-11 17:07 · Score: 1

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.

--
-- Did you try Tao3D? http://tao3d.sourceforge.net

Old stuff by Anonymous Coward · 2004-10-11 18:18 · Score: 0

Both java and C# haven't invented anything new, all the features has been in other languages already (C++, smalltalk, ...).

I wouldn't personally use C# for anything serious. C# compilers and virtual machines are way too new to they to be really stable and mature.

Java has been here ~ 10 years and only now I think it really works and computers are starting to be fast enough for it to be useful as real (versus toy) language.

I'm still using C/C++ for doing most of the serious stuff because of performance. I don't want to say C++ is better than Java. This is relative because it depends how on coders skills and how well software needs to be optimized. IMHO with ASM/C/C++ you can always get the best performance if you are willing to spend much time on optimizing your code. With Java you can get quite good performance by using very little time on optimizations.

I have much experience in C/C++/ASM and I don't know Java so well that I could get nearly same performance from it. I code CPU intensive programs (scientific computing) which needs to be well optimized.

Re:Java checked exceptions suck, but how to fix th by Deef · 2004-10-11 19:37 · Score: 1

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.

One Word by The+Grassy+Knoll · 2004-10-11 20:14 · Score: 1

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.

--
They will never know the simple pleasure of a monkey knife fight

Re:One Word by LnxAddct · 2004-10-12 02:02 · Score: 1

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. by DavidTurner · 2004-10-11 20:30 · Score: 1

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 by mcbevin · 2004-10-11 20:52 · Score: 1

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 by Pieroxy · 2004-10-11 21:30 · Score: 1

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.

--
Write boring code, not shiny code!

IntelliJ IDEA!!! by node159 · 2004-10-11 21:31 · Score: 1

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

--
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?

Its called compromise :) by node159 · 2004-10-11 22:13 · Score: 1

This is why marketing and eng's shouldn't mix :)

--
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?

Any place for both of them ? by dweeves · 2004-10-11 22:29 · Score: 3, Insightful

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 by tijsvd · 2004-10-11 23:28 · Score: 1

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?

C# Future Slowed by ECMA Standard by Anonymous Coward · 2004-10-12 00:52 · Score: 0

> Java might have a very hard time keeping up with C#

C# is an ECMA standard whereas Java is a Sun product. Wont't this make it harder for C# to keep up with Java in the future?

Re:Sounds a lot like religion by Anonymous Coward · 2004-10-12 01:59 · Score: 0

Get real. Sun has donated more to open source projects than almost anyone else (except maybe IBM).

Sun may not want their products destroyed by giving their enemies in the open source movement (the religious zealots who want to destroy all "evil companies" or maybe just destroy Java in favour of Perl or C) but I can hardly blame them for that.

Most people here are obviously not professionals. They don't realise the truth and wisdom of your last paragraph because they never have to deal with different environments in different companies (or projects within one company), being safely hidden from reality in the ivory towers of their temples to Linus and ESR.

As Babbage might have said... by gidds · 2004-10-12 02:25 · Score: 1

I am not able to rightly apprehend the kind of confusion of ideas that could provoke such an article!

--

Ceterum censeo subscriptionem esse delendam.

Tuples? I Haven't Heard That in Years... by LifesABeach · 2004-10-12 03:31 · Score: 1

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... by cakoose · 2004-10-12 14:17 · Score: 1

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.

GODDAM MODERATORS!!!! by Anonymous Coward · 2004-10-12 04:03 · Score: 0

Who the hell went around marking everything under this topic as "troll"? Moderators should be required to justify such with a detailed message. I have no fucking hint why they are complaining. Wanting functions is not a "troll" for fucksakes! GOTO HELL MODERATORS! Fry fry fry!!!!

Re:GODDAM MODERATORS!!!! by Anonymous Coward · 2004-10-12 04:07 · Score: 0

Who the hell went around marking everything under this topic as "troll"? Moderators should be required to justify such with a detailed message. I have no fucking hint why they are complaining. Wanting functions is not a "troll" for fucksakes! GOTO HELL MODERATORS! Fry fry fry!!!!

You implied it by SuperKendall · 2004-10-12 04:38 · Score: 1

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

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Re:You implied it by jeif1k · 2004-10-12 07:17 · Score: 1

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... by SuperKendall · 2004-10-12 07:48 · Score: 1

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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

.Net sucks by Anonymous Coward · 2004-10-13 00:41 · Score: 0

.Net == VB just slicker. COM still under the hood ...buggy and security nigthmare

sprintf options by Anonymous Coward · 2004-10-13 04:29 · Score: 0

There is great coverage of that here:

http://www.gotw.ca/publications/mill19.htm

a haiku for this thread by Anonymous Coward · 2004-10-13 05:31 · Score: 0

I read all the threads,
I'm not sure why I did that.
My mind is mushy goo.

Java vs C#? by Anonymous Coward · 2004-10-15 06:36 · Score: 0

Comparing Java to C# as the only available options is like comparing republicans to democrats. The correct answer is "none of the above". Real Programmers write in Perl.

Given what the java API does by mcc · 2004-10-18 10:20 · Score: 1

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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

Swing interfaces by ChunderDownunder · 2004-10-19 23:06 · Score: 1

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.

790 comments