3 ms·

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#

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
- michaelcampbell 16y ago
  > part of the argument for generics was that they would make code shorter and easier to read. An insignificant part. The main goal was a wee bit more of type-checking at compile time.
  - nigelsampson 16y ago
    Agreed, and one part of the Java / C# comparison is that C# also gives type-checking at run time.

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 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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.
michaelcampbell 16y ago
> part of the argument for generics was that they would make code shorter and easier to read. An insignificant part. The main goal was a wee bit more of type-checking at compile time.
- nigelsampson 16y ago
  Agreed, and one part of the Java / C# comparison is that C# also gives type-checking at run time.