Java and C# "Comparison"
harding.edu
harding.edu
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;
import pounding.headache;
XML comments are more of a convention. Compiler won't prevent you from makin incorrect xml there.
Yes, that's what decimal is for.
Capitalisation is pretty simpl(e/istic) http://msdn.microsoft.com/en-us/library/ms229043.aspx
Enums -> yes, they's that magical: http://download.oracle.com/javase/1.5.0/docs/guide/language/...
"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.
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?
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.
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'.
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.
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.
An insignificant part. The main goal was a wee bit more of type-checking at compile time.
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.
Java:
import harding.compsci.graphics.Rectangle; // Import single class
// Import all class. Can't import single class.
using Rectangle = Harding.CompSci.Graphics.Rectangle; // import single classeg 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.
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.
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).
You appear to be confusing a well made point with something that was never said.
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.
SomeMethod((x) => SomeOtherMethod(x));
class WrapperIDontReallyNeed() {
public void AnotherWrapper(uselessType x) {
SomeOtherMethod(x);
}
}
...
SomeMethod(new WrapperIDontReallyNeed());
And again - I don't see any mention from his side about being powerful. I don't think he's confusing anything either - expressiveness of a language is a pretty common term and is true in this case. C++ is easy to beat from that point of view, unless you add a tonne of Boost.
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.
I think that there is a shared common intuition that some languages are better than others. Think of it like the P != NP problem. We may not be able to objectively prove that P != NP, but we all share a strong belief that it must be the case.
This argument also takes the form of 'my language can do the same thing in fewer keystrokes'. Personally I think typing speed is near irrelevant, since I've never met anyone who churns out working code as quickly as they can type.
And I'm a big fan of the 'my language is more readable than your language' argument, I find it compelling, but I recognise that others do not.
All Turing complete languages are essentially equally "powerful", but not all languages are equally expressive. It takes less work to write code in Java than in assembly, and for some tasks it takes less work to write code in C# than in Java. Generally that's considered a good thing, with fewer lines of code and more readable code programmers can get more work done while having a higher confidence their code doesn't have glaring defects.
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.]