

Java and C# "Comparison" - Garbage
http://www.harding.edu/fmccown/java_csharp_comparison.html

======
Stormbringer
There were some problems I noted:

first example, the package statement is redundant. That would make the java
example much shorter, and apparently shorter code is inversely proportional to
e-peen length or something like that.

XML comments sounds like an interesting feature, but isn't the real feature
that C# treats XML as a native type (or something like that??)

decimal as a type sounds interesting, does that let you do high precision
financial math and/or math for large amounts of dollars?

object: C# capitalisation looks really random to me. I worked on a Java
project once with a guy who learned on something that was almost, but not
quite proper Java (Jada?) and reading his code was an exercise in going wtf?
Because he didn't follow (or know, or understand) the first letter
capitalisation rules.

For pi, you should of course use Math.PI not 3.14

I think the enum syntax is wrong in Java, don't you need to spray angle
brackets all over it in a mad orgy of generically making it much harder to
read?

Also, I don't think his println will do what he says it will do as he hasn't
defined a toString method??? Or is the enum magical enough to figure that out
on its own?

I knew his capitalisations were buggered up, Math.Pow does nothing in Java,
should be Math.pow

Converting an int to a string should be: String s = "" + x;

Converting the string back into an int should be longer, you need to catch the
possible conversion exception NumberformatException

If you're converting doubles to whole numbers, you should probably put them
into either a long or a BigDecimal, rather than an int.

For string concatenation I think he's missed += I know a lot of people don't
like it because they think it is slow or bad form, but the smart guys at Sun
optimised the buggery out of it, so it goes like a greased rattlesnake. Check
the bytecode that is produced if you don't believe me.

From the article:

    
    
        throw up;
    

I just about did. Sorry, I had to stop, I couldn't continue.

import pounding.headache;

~~~
michaelcampbell
> Converting an int to a string should be: String s = "" + x;

"should" is rather subjective; there are a variety of ways to do this, and the
usage of the overloaded "+" operator with an empty argument has always felt
hackish to me. String.valueOf(int_var); is equivalent, but (also subjectively)
more cleanly shows ones intent.

~~~
Stormbringer
I was reading through some Python the other day (could have been "learn Python
the hard way") and it struck me that one of the things that people like about
it is the way it handles Strings, or the 'power' it gives you over strings or
something like that.

Objecting to using + or += overloading on strings in Java seems to me to be
cutting off your nose to spite your face.

In Objective-C for instance I _dearly_ wish that there were better ways of
slapping strings and integers together. But no, everything seems to be a call
to some oddball class method with optional formatter classes and other magic
constants tossed around with gay abandon. Or alternately, _sometimes_ you can
use C-style format strings, and sometimes you can't. Enjoy.

In Python would you object to nesting "s and 's because it feels hackish? In
Lisp would you avoid Macros because they are hackish? In Perl would you avoid
regexs because they are hackish?

~~~
michaelcampbell
> Objecting to using + or += overloading on strings in Java seems to me to be
> cutting off your nose to spite your face.

Nowhere did I say you shouldn't use them; I said your assertion of "should"
was subjective at best and "clever" in a bad way, since you're only using it
for the side effect of auto-boxing the int INTO a string; not its intended
purpose of concatenating strings.

> In Python would you object to nesting "s and 's because it feels hackish? In
> Lisp would you avoid Macros because they are hackish? In Perl would you
> avoid regexs because they are hackish?

No, because none of them are.

------
seanlinmt
Here's a more exhaustive comparison of Java and C#.
<http://www.25hoursaday.com/CsharpVsJava.html>

~~~
sukuriant
This is more like what I was hoping for and even mentioned things I'd
forgotten in my list

------
nigelsampson
It seems to be a very old comparison, missing generics from both and lots of
other features, been a long time since I've done any Java but it seems like
its C# 1.0 compared to Java 6?

~~~
Stormbringer
The generics are on the Java side at least once. See the ArrayList<Object>
example.

Personally, if I was going to use a generic list based on <Object>, I'd just
use ArrayList or Vector without the generic notation. And then if the compiler
issued a warning I would bitch slap it and tell it to go make me some money.

I laugh because part of the argument for generics was that they would make
code shorter and easier to read. Yet they make the code harder to read, and I
seemed to write much less code when all I had to do was cast the object when I
took it out of the collection.

Anyway, there are some instances where generics are useful, things like
HashMaps.

The problem is, the people who write crappy HashMap code invariably are
abusing it to try to avoid writing a proper object. E.g. they're using it as a
list of named properties or attributes, some of which may or may not be there
this time round. If they'd just shove it into an object, it would make things
a lot easier to read. The only downside is they would have to put checks for
null all over the place. Since this would actually make their code more
robust, make them a better programmer and also make them a better person in
general, I have no problem with that 'drawback'.

~~~
whateverer
You didn't just tell us all that being forced to check for null references
strengthens the spirit, now did you? That is akin to saying that being forced
to check for buffer overflows is edifying, or that no programmer from a good
family uses garbage collectors.

~~~
Stormbringer
No it's not. Checking for nulls (and it's brother-by-a-different-mother
catching exceptions) is entirely in keeping with the philosophy of being
lenient in what you accept as input.

Checking for nulls is good practice because it makes you think about what is
happening in the code. It makes you think about making design decisions about
how you will handle nulls. It makes you aware that some libraries out there
may return null from a method call. It makes you aware that no matter how
often you make your co-workers sign a death pact in their own blood that they
will never return a null or pass you a null, that they may do so anyway either
through omission or commission (incompetence or miscomprehension or some weird
boundary condition).

Checking for nulls is compatible with a philosophy of thoroughly testing your
code.

Even if you are the perfect programmer, others are not. Refusing to check for
nulls is to be at risk of disagreeing with reality how it should work. Reality
always wins.

Realising that if everyone else is not perfect, that perhaps they are also not
perfect, is what causes the personal growth benefit I ascribed to being a more
careful programmer.

~~~
whateverer
Thanks for the response.

Well, the thing is, that you shouldn't have to fear for null to creep up
somewhere in the code at any time. Sure, if your language (like most, sadly)
has null as an alternate value for almost any type you'll have to do that,
just like in C you have to check for the bounds of the buffers into which you
read strings, but that doesn't have to be the case!

There are languages that made away with null in general, such as Haskell (yes,
I know, I know), where if you have operations that require some null-
equivalent, you declare it so by using the Maybe monad, and the compiler will
ensure that the null gnomes won't throw a wrench at the rest of your code :)

On not trusting the output of other layers/code: it's a great policy, but I do
think that we should strive to be able to take more and more things for
granted in our code, or at least reasonably for granted, like we usually trust
that random bits won't change in our integers because of cosmic rays. And for
that the language designers can give us tools in some form or another, if they
do their homework. It will only make it easier to live with our limitations.

------
jasonkester
It seems a bit silly to compare syntax of these two languages, when the thing
that makes them what they are is their class libraries.

So as you can see, they're nearly identical in syntax. But that doesn't mean
they're even similar in terms of being suitable for a given task.

I'd like to see a comparison of Java's standard class libraries as compared to
.NET. How do you open a file in each? Execute a stored procedure and spin thru
the returned recordset. That's where the interesting stuff lies, and where the
ecosystems diverge.

------
fleitz
There are some problems with it.

Java:

    
    
      import harding.compsci.graphics.Rectangle;  // Import single class
    

C#:

    
    
      // Import all class. Can't import single class.
    

Correct answer:

    
    
      using Rectangle = Harding.CompSci.Graphics.Rectangle; // import single class

~~~
Groxx
I've been using this trick to get around the uber-global-scope that exists
where I'm working. Two versions of utility tools exist with identical scopes
and names (don't ask why), so re-naming the class with "using" is the _only_
way to force the selection. I wish I'd seen this comment a couple months ago
when I was trying to figure out wtf was going on.

~~~
S_A_P
maybe Im misunderstanding you here, but when you have a collision of
namespaces like that cant you just fully qualify the object you want?

eg var foo = new Name.Space.Object();

For me the using statement in C# is handy shorthand for something that
implements IDisposable(say, SqlClient for example) making sure that Dispose
gets called.

~~~
Groxx
No, though say you have three nested namespaces for your utility class, and
many other classes in those namespaces at varying levels and another version
by the same name exists in global scope. There's even _another_ version of the
same class that's deprecated, but used in one or two places, and sites mid-way
through the namespacing. And ASP is so #^@%in brilliant, everything resides in
a single app_code folder and non-namespaced classes cannot be not-imported (as
far as I've been able to tell).

You can name.space.the.object, absolutely. Though it's closer to
TheMasterNameSpace.Utilities.DatabaseConnectivity.TheClassNameThatIsUnnecessarilyLong,
and that would have to be typed _every_ time you wish it to be used. That
amounts to literally _hundreds_ of times that must be typed in some of the
larger chunks of code, and tens of thousands if not significantly more over
the course of a decent sized project. Changing this to "using TC = ..." makes
it _immensely_ less of a PITA, and changing it to use a different version
(with the same API) requires changing a _single_ location.

And I am fully, painfully, _daily_ aware of how bad this architecture is,
there's no need to point this out. I'm part of the process of correcting this
injustice.

------
InclinedPlane
A more accurate description: a translation of C# 1.0ish syntax for Java code
examples.

Java and C# are no longer directly comparable in my opinion, the introduction
of first class functions, extension methods, and LINQ in general make modern
C# a far more expressive language than Java is currently capable of
(notwithstanding several extremely expressive JVM based languages such as
scala and clojure).

~~~
Stormbringer
You appear to be confusing having more features with being more powerful. An
easy mistake to make, but not necessarily true.

~~~
jamesrom
Not once in his comment did he say anything even close to 'being more
powerful'. Why did you interpret it that way?

You appear to be confusing a well made point with something that was never
said.

~~~
SeanLuke
Let us try again.

He is confusing having more features with being "more expressive" (whatever
that means). And even if we work out what that means, he's confusing "being
more expressive" with "being more powerful" (whatever THAT means).

By this logic, C++ is the language to beat.

~~~
arethuza
I think in terms of raw feature count Common Lisp probably "wins" - I can
recommend a read through Steele's _Common Lisp the Language_ if you have some
time to spare:

<http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html>

~~~
Stormbringer
Surely not! Lisp must have close to the fewest features of any language (other
than the weird ones like Brainf*ck that only have 8 instructions).

Other than Macros and parenthesis there isn't anything to it. If I remember
correctly, pretty much all you need to do to write your own lisp is to
implement eval.

~~~
arethuza
That's the basic syntax of Lisp that you are thinking of - they actual Common
Lisp language has a metric shipload of built in features from basic functions,
data types through to things like the Loop macro right up to decidedly non-
trivial things like CLOS.

------
sukuriant
My first thought was that this will be a very incomplete list. I was right.
Where is the delegate vs anonymous class comparison. What about the horrible
tricks you can do to emulate refs (pass an array with the reference in it,
instead), and the less horrible thing you can do with out parameters (create a
return class)? What about the differences in the implementation of proper
event-driven design between the two languages? And the biggest difference I've
experienced between the two, what about the general design and thought behind
their different standard APIs?

All in all, I was very underwhelmed. This should have fleshed the real
differences (to me the thought behind their APIs) out.

[edit: finally reading the small text underneath the title, I see this is a
syntax comparison. A couple of my statements still make sense, but this really
needs to have its title changed. I suppose people wouldn't read it if that
were the case, though.]

~~~
henrikschroder
Worse, it's a syntax comparison from Java to C#, i.e. a "how do I" for Java
people writing C#, not the other way around. For example I saw it list the ?:
operator, but where is the ?? operator that C# has and Java sorely lacks?
Where's the using block? Delegates? LAMBDA EXPRESSIONS?!?

------
fletchowns
I thought this page was supposed to be a joke just to illustrate how similar
they can be.

------
wladimir
I almost didn't click because I feared this was a language war post, but this
is actually a pretty useful comparison sheet showing the language syntaxes.

