4 ms·

What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better. Checked exc

What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better. Checked exceptions are really a nuisance, I would call them a negative feature. Java enums in c# are basically classes with readonly properties if you need to pass constructor arguments. Streams in Java are a huge clusterfuck. I can't think to anything that Java has that is better than c#.

35bge57dtjku 9y ago
It'd be great if the secret to language design was cramming in as many features as possible.
int_19h 9y ago
Delegates are not the equivalent of anonymous inner classes. They're commonly used for similar design patterns (observer and other callbacks), yes, but they're not the same thing. To be more specific, an anonymous delegate / lambda can be thought of as an implementation of an interface with a single method. But with Java anonymous inner classes, you can implement multiple methods at once. The reasons why Java enums are better, is because they're actually constrained to the domain you specify. In C#, the range of values for any enum is the same as its underlying integer type - it's just that some of those values have names, while others don't. But it's always legal to cast (and few people know this, but 0 is always a valid enum value that you don't need to cast) - so any method you write that accepts an enum value has to validate it. In Java, since enum is basically a final class with a bunch of private singletons, you are guaranteed that the reference you get points to one of those. That said, given that C# now has pattern matching, and it seems to be getting more powerful with every release, I'd be surprised if it didn't get something like case classes very soon.
- noblethrasher 9y ago
  Delegates and anonymous inner classes are equivalent, modulo API: //Java Bax.addHandler(new Foo() { @Override public void Bar() { doSomething(); } @Override public int Baz(X n) { return computeInt(n); } }); //C# Bax.AddHandler(() => DoSomething(), n => ComputeInt(n)); But, anonymous delegates and lambdas are at once syntactically nicer and more powerful, because of type inference and the fact that they can capture local variables. Regarding Java enums, the actual equivalent feature in C# is class nesting. There is a tiny bit more ceremony involved in defining them, but they're more flexible than Java enums. For instance, you can decide whether or not to implement them as readonly (final) fields, or as static properties, depending on how much you care about cache friendliness. public abstract partial class SomeEnum { private SomeEnum(){} public abstract int Biz(); sealed class AFoo : SomeEnum { public override Biz() => 2 } sealed class ABar : SomeEnum { public override Biz() => 4 } sealed class ABaz : SomeEnum { public override Biz() => 8 } } //Singleton implementation: public abstract partial class SomeEnum { public static readonly SomeEnum Foo = new AFoo(); public static readonly SomeEnum Bar = new ABar(); public static readonly SomeEnum Baz = new ABaz(); } //Cache friendly implementation: public abstract partial class SomeEnum { public SomeEnum Foo => new AFoo(); public SomeEnum Bar => new ABar(); public SomeEnum Baz => new ABaz(); } It's also worth noting that extension methods on C# enums give you most (all?) of the power of Java enums.
  - r2________ 9y ago
    On your delegates example for C#, since the parameters of the lambda and methods match, and you aren't relying on any closure behaviour, you can use 'method group syntax' to make it even more succinct: Bax.AddHandler(DoSomething, ComputeInt);
  - int_19h 9y ago
    That is only equivalent within the boundaries of your API (i.e. when you use them as pure callbacks). But your delegates are two different objects, while in the Java example, it's a single object. This makes a difference if, for example, object identity matters. From practical purpose, Java anonymous classes can be used in any scenario where you need to create a one-off object that derives from a class or implements one interface. A delegate can only be used in a scenario where the receiving variable or function wants a function type. I'm not arguing that delegates are lambdas are bad, mind you. For the common scenario involving callbacks, they're vastly superior. But they're not a complete replacement for Java inner classes.
    - noblethrasher 9y ago
      Yes, but we can recover all of the power of anonymous inner classes by building up a (usually small) set of "ad-hoc" classes that just wrap delegates, as I explain here: https://stackoverflow.com/questions/20703002/does-object-expression-exist-in-c-sharp-like-in-f/20874683#20874683 https://stackoverflow.com/questions/20703002/does-object-exp... By the way, thanks for your work on PTVS, I just discovered it recently.
      - int_19h 9y ago
        But they aren't really anonymous then, since you have to write a wrapper class for every class or interface that you intend to implement inline. By the way, I totally forgot about F# object expressions! But they're a good example of this feature. Better than in Java, in fact, because they let you implement multiple interfaces. Also, IIRC, they're true closures (whereas Java only lets you close over finals, not writable locals). Ideally, you'd have both those and lambdas in a language, like C# and Scala do. If I had to choose, though, I'd definitely pick lambdas - that is the 90% use case.
pjmlp 9y ago
- Better enums - The way one can plug into JIT code generation via invokedynamic, methodhandles and varhandle bytecodes - A JIT compiler written in Java (Graal), now pluggable in the reference JVM - An actual roadmap to rewrite remaining C++ from OpenJDK in Java (Project Metropolis) - The research being done in Graal and Sulong about using Java to write compiler infrastructure - Being portable to devices where the CLR probably will never be ported to - A a better JIT in what concerns dynamic code re-writting - Multiple implementations, some of them with AOT support, from disparate vendors I just enjoy using both eco-systems since they exist.
- apta 9y ago
  > An actual roadmap to rewrite remaining C++ from OpenJDK in Java Very cool. I wasn't aware of that. Do you think this will help introduce more "low level" features in Java since it is paramount to at least keep the same level of performance, and definitely improve it in the future?
  - pjmlp 9y ago
    Yes, this is nothing new, there are a few meta-circular JVMs, just they weren't commercial products. Jalapeño from IBM, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8194 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8... Sun's own Squawk VM, used on Sun SPOT before IoT was a thing. https://www.researchgate.net/publication/221320697_The_squawk_virtual_machine_Java_on_the_bare_metal https://www.researchgate.net/publication/221320697_The_squaw... https://en.wikipedia.org/wiki/Sun_SPOT https://en.wikipedia.org/wiki/Sun_SPOT Regarding Project Metropolis specifically, you can find the information here. "Your next JVM: Panama, Valhalla, Metropolis by John Rose" https://www.youtube.com/watch?v=OMk5KoUIOy4 https://www.youtube.com/watch?v=OMk5KoUIOy4 http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Prop... Note that I wasn't completely fair, the .NET team also has some plans to incrementally move the runtime into C#, but so far it has only been mentioned on an InfoQ interview, no official plans revealed. https://www.infoq.com/articles/virtual-panel-dotnet-future https://www.infoq.com/articles/virtual-panel-dotnet-future "So, in my view, the primary trend is moving our existing C++ codebase to C#. It makes us so much more efficient and enables a broader set of .NET developers to reason about the base platform more easily and also contribute."
naasking 9y ago
> What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better. Not entirely. .NET delegates don't support generic type parameters (aka first-class polymorphism). Methods in C# and Java do. C# interfaces also don't support static methods, which are useful for factory patterns. C#'s factory patterns require a lot more code as a result. C# also has a bunch of artificial limitations, like not being able to specify type constraints on Delegate, Enum, and a few other built-in types. It's just nonsense. The rest of C# is overall better than Java though.
- zzbzq 9y ago
  Not sure what you mean by "delegates can't accept generic type parameters" because you can certainly make a delegate with a <T> in it in C#
  - naasking 9y ago
    There is no delegate equivalent of passing around an instance of IFoo: interface IFoo { void Bar<T>(); } This is known as first-class polymorphism. Classes with methods are strictly more powerful than delegates, but they shouldn't be. It's even worse than that actually, because you can't even create an open instance delegate to a generic interface or abstract class method (you'll get a runtime error, not even a static error).

35bge57dtjku 9y ago

It'd be great if the secret to language design was cramming in as many features as possible.

int_19h 9y ago

Delegates are not the equivalent of anonymous inner classes. They're commonly used for similar design patterns (observer and other callbacks), yes, but they're not the same thing. To be more specific, an anonymous delegate / lambda can be thought of as an implementation of an interface with a single method. But with Java anonymous inner classes, you can implement multiple methods at once. The reasons why Java enums are better, is because they're actually constrained to the domain you specify. In C#, the range of values for any enum is the same as its underlying integer type - it's just that some of those values have names, while others don't. But it's always legal to cast (and few people know this, but 0 is always a valid enum value that you don't need to cast) - so any method you write that accepts an enum value has to validate it. In Java, since enum is basically a final class with a bunch of private singletons, you are guaranteed that the reference you get points to one of those. That said, given that C# now has pattern matching, and it seems to be getting more powerful with every release, I'd be surprised if it didn't get something like case classes very soon.

noblethrasher 9y ago
Delegates and anonymous inner classes are equivalent, modulo API: //Java Bax.addHandler(new Foo() { @Override public void Bar() { doSomething(); } @Override public int Baz(X n) { return computeInt(n); } }); //C# Bax.AddHandler(() => DoSomething(), n => ComputeInt(n)); But, anonymous delegates and lambdas are at once syntactically nicer and more powerful, because of type inference and the fact that they can capture local variables. Regarding Java enums, the actual equivalent feature in C# is class nesting. There is a tiny bit more ceremony involved in defining them, but they're more flexible than Java enums. For instance, you can decide whether or not to implement them as readonly (final) fields, or as static properties, depending on how much you care about cache friendliness. public abstract partial class SomeEnum { private SomeEnum(){} public abstract int Biz(); sealed class AFoo : SomeEnum { public override Biz() => 2 } sealed class ABar : SomeEnum { public override Biz() => 4 } sealed class ABaz : SomeEnum { public override Biz() => 8 } } //Singleton implementation: public abstract partial class SomeEnum { public static readonly SomeEnum Foo = new AFoo(); public static readonly SomeEnum Bar = new ABar(); public static readonly SomeEnum Baz = new ABaz(); } //Cache friendly implementation: public abstract partial class SomeEnum { public SomeEnum Foo => new AFoo(); public SomeEnum Bar => new ABar(); public SomeEnum Baz => new ABaz(); } It's also worth noting that extension methods on C# enums give you most (all?) of the power of Java enums.
- r2________ 9y ago
  On your delegates example for C#, since the parameters of the lambda and methods match, and you aren't relying on any closure behaviour, you can use 'method group syntax' to make it even more succinct: Bax.AddHandler(DoSomething, ComputeInt);
- int_19h 9y ago
  That is only equivalent within the boundaries of your API (i.e. when you use them as pure callbacks). But your delegates are two different objects, while in the Java example, it's a single object. This makes a difference if, for example, object identity matters. From practical purpose, Java anonymous classes can be used in any scenario where you need to create a one-off object that derives from a class or implements one interface. A delegate can only be used in a scenario where the receiving variable or function wants a function type. I'm not arguing that delegates are lambdas are bad, mind you. For the common scenario involving callbacks, they're vastly superior. But they're not a complete replacement for Java inner classes.
  - noblethrasher 9y ago
    Yes, but we can recover all of the power of anonymous inner classes by building up a (usually small) set of "ad-hoc" classes that just wrap delegates, as I explain here: https://stackoverflow.com/questions/20703002/does-object-expression-exist-in-c-sharp-like-in-f/20874683#20874683 https://stackoverflow.com/questions/20703002/does-object-exp... By the way, thanks for your work on PTVS, I just discovered it recently.
    - int_19h 9y ago
      But they aren't really anonymous then, since you have to write a wrapper class for every class or interface that you intend to implement inline. By the way, I totally forgot about F# object expressions! But they're a good example of this feature. Better than in Java, in fact, because they let you implement multiple interfaces. Also, IIRC, they're true closures (whereas Java only lets you close over finals, not writable locals). Ideally, you'd have both those and lambdas in a language, like C# and Scala do. If I had to choose, though, I'd definitely pick lambdas - that is the 90% use case.

pjmlp 9y ago

- Better enums - The way one can plug into JIT code generation via invokedynamic, methodhandles and varhandle bytecodes - A JIT compiler written in Java (Graal), now pluggable in the reference JVM - An actual roadmap to rewrite remaining C++ from OpenJDK in Java (Project Metropolis) - The research being done in Graal and Sulong about using Java to write compiler infrastructure - Being portable to devices where the CLR probably will never be ported to - A a better JIT in what concerns dynamic code re-writting - Multiple implementations, some of them with AOT support, from disparate vendors I just enjoy using both eco-systems since they exist.

apta 9y ago
> An actual roadmap to rewrite remaining C++ from OpenJDK in Java Very cool. I wasn't aware of that. Do you think this will help introduce more "low level" features in Java since it is paramount to at least keep the same level of performance, and definitely improve it in the future?
- pjmlp 9y ago
  Yes, this is nothing new, there are a few meta-circular JVMs, just they weren't commercial products. Jalapeño from IBM, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8194 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8... Sun's own Squawk VM, used on Sun SPOT before IoT was a thing. https://www.researchgate.net/publication/221320697_The_squawk_virtual_machine_Java_on_the_bare_metal https://www.researchgate.net/publication/221320697_The_squaw... https://en.wikipedia.org/wiki/Sun_SPOT https://en.wikipedia.org/wiki/Sun_SPOT Regarding Project Metropolis specifically, you can find the information here. "Your next JVM: Panama, Valhalla, Metropolis by John Rose" https://www.youtube.com/watch?v=OMk5KoUIOy4 https://www.youtube.com/watch?v=OMk5KoUIOy4 http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Prop... Note that I wasn't completely fair, the .NET team also has some plans to incrementally move the runtime into C#, but so far it has only been mentioned on an InfoQ interview, no official plans revealed. https://www.infoq.com/articles/virtual-panel-dotnet-future https://www.infoq.com/articles/virtual-panel-dotnet-future "So, in my view, the primary trend is moving our existing C++ codebase to C#. It makes us so much more efficient and enables a broader set of .NET developers to reason about the base platform more easily and also contribute."

naasking 9y ago

> What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better. Not entirely. .NET delegates don't support generic type parameters (aka first-class polymorphism). Methods in C# and Java do. C# interfaces also don't support static methods, which are useful for factory patterns. C#'s factory patterns require a lot more code as a result. C# also has a bunch of artificial limitations, like not being able to specify type constraints on Delegate, Enum, and a few other built-in types. It's just nonsense. The rest of C# is overall better than Java though.

zzbzq 9y ago
Not sure what you mean by "delegates can't accept generic type parameters" because you can certainly make a delegate with a <T> in it in C#
- naasking 9y ago
  There is no delegate equivalent of passing around an instance of IFoo: interface IFoo { void Bar<T>(); } This is known as first-class polymorphism. Classes with methods are strictly more powerful than delegates, but they shouldn't be. It's even worse than that actually, because you can't even create an open instance delegate to a generic interface or abstract class method (you'll get a runtime error, not even a static error).