6 ms·

I also think Java is fine. Compared to C#, I find Java code easier to read as there is less magic. I also use Groovy for some corner cases like for example JDBC

by olavgg 10y ago

I also think Java is fine. Compared to C#, I find Java code easier to read as there is less magic. I also use Groovy for some corner cases like for example JDBC stuff or metaprogramming. I'm also a big fan of Maven and the development tools for Java, and most importantly the eco-system with rich libraries and frameworks. Is there an alternative for JRebel or Spring-loaded for C# yet?

mattmanser 10y ago
What magic are you talking about? Various .Net frameworks have silly amounts of magic, but C# itself?
- jrudolph 10y ago
  Silly amounts of magic? Ever looked at a Java Spring project?!
  - hacktothefuture 10y ago
    THIS!
- blauditore 10y ago
  When I started going into C# from Java a bit, there were two things slightly annoying me: - Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention. - The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code. Those are not necessarily "magic", but potential obscurities that can't happen in Java, simply because Java lacks these features.
  - samfisher83 10y ago
    If you have visual studio it tells you what the var is.
    - kuschku 10y ago
      So, where do I get a version fo Visual Studio that’s open source, and works on Linux? And not just the little text editor VS Code, a real IDE? For most devs, Visual Studio isn’t a realistic option.
      - eropple 10y ago
        Most developers use Windows, where VS Professional (under the badge of VS Community) is free. The set of developers who use Linux and OS X (and I mean, I am one) is not representative of developers of a whole.
        mmgutz 10y ago
        You mean most .NET developers use Windows?
        eropple 10y ago
        I mean most developers, period, use Windows, on a worldwide basis. Most web developers use Windows. Most C/C++ developers use Windows. Most Android developers use Windows. Almost all .NET developers use Windows--but most developers, period, use Windows. Windows is the de facto standard in most places that aren't chasing the leading edge.
        kuschku 10y ago
        > I mean most developers, period, use Windows, on a worldwide basis. I’m not sure anyone would agree with that. Unless you also count designers, and kids who just learnt how to click together a website in Frontpage 2000 as developers. Especially if you count compsci graduates, it becomes very obvious just how much *nix dominates.
  - krzat 10y ago
    Interesting. I wonder what would be your opinion on languages with even more magic, like Swift.
    - blauditore 10y ago
      I'm not saying it's a bad thing, I actually like both. It just takes more time to get up to speed and there is more surface of attack for devs to screw things up. That's also what I don't like e.g. about JS: It's so unrestrictive you can do a lot of wild things with it - which is sometimes good but often bad. Idk about Swift, never used it yet.
  - gregmac 10y ago
    > The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code. I find type inference to be the opposite, generally, because it encourages good naming, and it reduces noise/boilerplate. It also makes writing and refactoring faster (don't have to think about the return types, just the code flow). The only situation I can even think of where it is a problem is when you are passing something to an overloaded method. For example: void DoSomething(MySpecialType value); void DoSomething(string value); //// var result = GetData(); DoSomething(result); You can't tell which one is going to be called by just looking at that code. However: * GetData() is probably badly named in this situation * If DoSomething() does something very different depending on the type passed, it should have different names, not be overloaded On top of that, this code can also have the same problem without type inference: DoSomething(GetData())
    - blauditore 10y ago
      > It also makes writing and refactoring faster (don't have to think about the return types, just the code flow). I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change. Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.
      - msbarnett 10y ago
        > If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change. If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way. Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.
  - mattmanser 10y ago
    The var syntax definitely doesn't lead to hard to read code. It's one of those assumptions people who haven't actually used it make. 99% of the time it's completely obvious what the variable is because you can just look at the right side of the equal sign. Also, you can just hover over it. As for the extension methods, they pretty much fixed that in VS 2015, it will now tell you which using statement you need to include. Extension methods are a good solution to a specific problem.
  - rzzzt 10y ago
    Lombok includes the "val" keyword, which infers the type from the initializer expression: https://projectlombok.org/features/val.html https://projectlombok.org/features/val.html
  - m_fayer 10y ago
    Do you really think something like this: Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<string, Tuple<int, List<string>>>(); Is prefferable to: var foo = new Dictionary<string, Tuple<int, List<string>>>(); What do you get from the former that makes the eye-pain worth it? Also, the var keyword is necessary for anonymous types if you want to hold a reference to one. And this is a language feature I sorely miss in Java-land.
    - dbdr 10y ago
      Since Java 7 you can use the "diamond operator" in such cases: Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<>();
  - serge2k 10y ago
    both of these are great tools, but as with many you have tradeoffs. Extension methods give you a way to produce very clean reusable code to extend behaviour of classes. Downside is you do need to bring in the extension method class (not a big deal). Java is a shitty language exactly because they don't put in things like these out of fear that people don't know how to use them.
    - ygra 10y ago
      Java has default methods on interfaces instead. It's their take on the same issue, in a way. They considered the fact that with C#'s extension methods types not owned by the developer can be extended (as well as platform types) a problem and opted instead for a solution where someone who owns a type also controls its extensions. Default methods in Java are purely a way of adding stuff to interfaces in your API without breaking existing implementations (but also allowing future implementations to override those methods). C# on the other hand is merely a bit of syntactic sugar which can be confusing at times. (I have to admit not to be a fan of various libraries that add extension methods to integers and similar. It's not a good way of exposing an API in my eyes.) TL;DR: Java has something similar, it just came from a different view of how the problem should be solved. Both approaches have advantages and drawbacks.
  - int_19h 10y ago
    > Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you. Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.
  - pjmlp 10y ago
    I guess you are out of touch with Java. Extensions methods can be approached via default methods. Java 9, latest by 10, will get var. It is already on the approved roadmap.

by olavgg 10y ago

mattmanser 10y ago

What magic are you talking about? Various .Net frameworks have silly amounts of magic, but C# itself?

jrudolph 10y ago
Silly amounts of magic? Ever looked at a Java Spring project?!
- hacktothefuture 10y ago
  THIS!
blauditore 10y ago
When I started going into C# from Java a bit, there were two things slightly annoying me: - Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention. - The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code. Those are not necessarily "magic", but potential obscurities that can't happen in Java, simply because Java lacks these features.
- samfisher83 10y ago
  If you have visual studio it tells you what the var is.
  - kuschku 10y ago
    So, where do I get a version fo Visual Studio that’s open source, and works on Linux? And not just the little text editor VS Code, a real IDE? For most devs, Visual Studio isn’t a realistic option.
    - eropple 10y ago
      Most developers use Windows, where VS Professional (under the badge of VS Community) is free. The set of developers who use Linux and OS X (and I mean, I am one) is not representative of developers of a whole.
      - mmgutz 10y ago
        You mean most .NET developers use Windows?
        eropple 10y ago
        I mean most developers, period, use Windows, on a worldwide basis. Most web developers use Windows. Most C/C++ developers use Windows. Most Android developers use Windows. Almost all .NET developers use Windows--but most developers, period, use Windows. Windows is the de facto standard in most places that aren't chasing the leading edge.
        kuschku 10y ago
        > I mean most developers, period, use Windows, on a worldwide basis. I’m not sure anyone would agree with that. Unless you also count designers, and kids who just learnt how to click together a website in Frontpage 2000 as developers. Especially if you count compsci graduates, it becomes very obvious just how much *nix dominates.
- krzat 10y ago
  Interesting. I wonder what would be your opinion on languages with even more magic, like Swift.
  - blauditore 10y ago
    I'm not saying it's a bad thing, I actually like both. It just takes more time to get up to speed and there is more surface of attack for devs to screw things up. That's also what I don't like e.g. about JS: It's so unrestrictive you can do a lot of wild things with it - which is sometimes good but often bad. Idk about Swift, never used it yet.
- gregmac 10y ago
  > The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code. I find type inference to be the opposite, generally, because it encourages good naming, and it reduces noise/boilerplate. It also makes writing and refactoring faster (don't have to think about the return types, just the code flow). The only situation I can even think of where it is a problem is when you are passing something to an overloaded method. For example: void DoSomething(MySpecialType value); void DoSomething(string value); //// var result = GetData(); DoSomething(result); You can't tell which one is going to be called by just looking at that code. However: * GetData() is probably badly named in this situation * If DoSomething() does something very different depending on the type passed, it should have different names, not be overloaded On top of that, this code can also have the same problem without type inference: DoSomething(GetData())
  - blauditore 10y ago
    > It also makes writing and refactoring faster (don't have to think about the return types, just the code flow). I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change. Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.
    - msbarnett 10y ago
      > If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change. If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way. Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.
- mattmanser 10y ago
  The var syntax definitely doesn't lead to hard to read code. It's one of those assumptions people who haven't actually used it make. 99% of the time it's completely obvious what the variable is because you can just look at the right side of the equal sign. Also, you can just hover over it. As for the extension methods, they pretty much fixed that in VS 2015, it will now tell you which using statement you need to include. Extension methods are a good solution to a specific problem.
- rzzzt 10y ago
  Lombok includes the "val" keyword, which infers the type from the initializer expression: https://projectlombok.org/features/val.html https://projectlombok.org/features/val.html
- m_fayer 10y ago
  Do you really think something like this: Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<string, Tuple<int, List<string>>>(); Is prefferable to: var foo = new Dictionary<string, Tuple<int, List<string>>>(); What do you get from the former that makes the eye-pain worth it? Also, the var keyword is necessary for anonymous types if you want to hold a reference to one. And this is a language feature I sorely miss in Java-land.
  - dbdr 10y ago
    Since Java 7 you can use the "diamond operator" in such cases: Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<>();
- serge2k 10y ago
  both of these are great tools, but as with many you have tradeoffs. Extension methods give you a way to produce very clean reusable code to extend behaviour of classes. Downside is you do need to bring in the extension method class (not a big deal). Java is a shitty language exactly because they don't put in things like these out of fear that people don't know how to use them.
  - ygra 10y ago
    Java has default methods on interfaces instead. It's their take on the same issue, in a way. They considered the fact that with C#'s extension methods types not owned by the developer can be extended (as well as platform types) a problem and opted instead for a solution where someone who owns a type also controls its extensions. Default methods in Java are purely a way of adding stuff to interfaces in your API without breaking existing implementations (but also allowing future implementations to override those methods). C# on the other hand is merely a bit of syntactic sugar which can be confusing at times. (I have to admit not to be a fan of various libraries that add extension methods to integers and similar. It's not a good way of exposing an API in my eyes.) TL;DR: Java has something similar, it just came from a different view of how the problem should be solved. Both approaches have advantages and drawbacks.
- int_19h 10y ago
  > Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you. Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.
- pjmlp 10y ago
  I guess you are out of touch with Java. Extensions methods can be approached via default methods. Java 9, latest by 10, will get var. It is already on the approved roadmap.