Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was wrong, reflecting on the .NET design choices

ayende.com

Post reply on HN
Print view View original

131–139 of 139 posts

Re: I was wrong, reflecting on the .NET design choices

#131

Post by paulddraper »

emodendroket wrote: post #126
paulddraper wrote: post #96

Earlier quoted context omitted.

Things that have CLR-like generics work on the CLR. Anything else doesn't. E.g. Scala.

I don't really get the complaint. Even if they had type erasure you couldn't use Scala in the CLR because nobody has written a CLR target. And on the other hand, I don't know why there couldn't be a Scala implementation with true generics. A lot of crap like DummyImplicit and ClassTag is there for no other reason than to work around those limitations anyway.

Scala had a CLR target for a number of years, but getting the type system to work was so problematic it was eventually abandoned.

Re: I was wrong, reflecting on the .NET design choices

#132

Post by wvenable »

mrec wrote: post #124
wvenable wrote: post #87

Earlier quoted context omitted.

I agree it's easy to layer throwing behavior on top of non-throwing behavior -- Java easily chose the worst possible way to do it. But having both a Parse and TryParse means that I can ignore the result of the Parse call entirely and let it fall through to the exception handler. It is by-definition always expected to succeed so when it doesn't then that's a bug. If you only have one of TryParse or Parse you cannot ju…

> If you only have one of TryParse or Parse you cannot judge the intention. Sure you can. To take Java as an example, if you only have one parse method and it returns an `Optional`, you can indicate the intention by whether or not you call `get` directly or call something like `isPresent` or `orElse` first/instead. Yes, you can get that wrong, but you can get the choice between `TryParse` and `Parse` just as wrong.

That's a very good point. I do this all the time with nullable types; I'm not sure why I didn't consider it that way.

Re: I was wrong, reflecting on the .NET design choices

#133

Post by emodendroket »

broiledegg wrote: post #129
emodendroket wrote: post #126

Earlier quoted context omitted.

I don't really get the complaint. Even if they had type erasure you couldn't use Scala in the CLR because nobody has written a CLR target. And on the other hand, I don't know why there couldn't be a Scala implementation with true generics. A lot of crap like DummyImplicit and ClassTag is there for no other reason than to work around those limitations anyway.

I think it's largely an urban myth. All expressive languages whose type systems don't have a 1-to-1 equivalence in the runtime's type system need to employ some degree of erasure. The distinction between "erasure" and "no erasure" doesn't make much sense. It's always just about more (CLR 1, JVM = 2, JVM >= 10) erasure.

I don't see how you figure. In C# List and List are two different types at runtime.

Re: I was wrong, reflecting on the .NET design choices

#134

Post by broiledegg »

paulddraper wrote: post #131
emodendroket wrote: post #126

Earlier quoted context omitted.

I don't really get the complaint. Even if they had type erasure you couldn't use Scala in the CLR because nobody has written a CLR target. And on the other hand, I don't know why there couldn't be a Scala implementation with true generics. A lot of crap like DummyImplicit and ClassTag is there for no other reason than to work around those limitations anyway.

Scala had a CLR target for a number of years, but getting the type system to work was so problematic it was eventually abandoned.

That's what I meant with: "That's largely an urban myth."

Re: I was wrong, reflecting on the .NET design choices

#135

Post by broiledegg »

emodendroket wrote: post #133
broiledegg wrote: post #129

Earlier quoted context omitted.

I think it's largely an urban myth. All expressive languages whose type systems don't have a 1-to-1 equivalence in the runtime's type system need to employ some degree of erasure. The distinction between "erasure" and "no erasure" doesn't make much sense. It's always just about more (CLR 1, JVM = 2, JVM >= 10) erasure.

I don't see how you figure. In C# List and List are two different types at runtime.

And ...?

Re: I was wrong, reflecting on the .NET design choices

#136

Post by emodendroket »

broiledegg wrote: post #135
emodendroket wrote: post #133

Earlier quoted context omitted.

I don't see how you figure. In C# List and List are two different types at runtime.

And ...?

If you're implementing a CLR language and want flawless interop with everything then you just have the constraint that you need to support generics in the same way that other CLR languages do. I'm not seeing why this model is so much worse.

Re: I was wrong, reflecting on the .NET design choices

#137

Post by ska »

le-mark wrote: post #100
ska wrote: post #14

Earlier quoted context omitted.

Whatever the reasons behind it, it is clear that a lot of the effective and high impact industrial languages at various levels of the stack (e.g. c++, ada, Java/C#, python, perl, javascript,etc.) have not managed to incorporate some of the real wisdom learned in earlier systems (e.g. smalltalk an some lisps for OO, etc.) If this was in fact avoidable, it is a sad fact.

This type stupid bloviating is why programming will never be a proper engineering discipline. There are two ways to implement oop: classes aka "object templates" or prototypes. Educate your selves people!

The tone makes it difficult to tell, but I think you are supporting my thesis - mistakes of the past are, in fact, being repeated. Engineering disciplines succeed by a) learning the science and b) applying it properly. We do not do that well in programming. So yes, educate yourself, and then take the lessons to heart.

Re: I was wrong, reflecting on the .NET design choices

#138

Post by emodendroket »

paulddraper wrote: post #131
emodendroket wrote: post #126

Earlier quoted context omitted.

I don't really get the complaint. Even if they had type erasure you couldn't use Scala in the CLR because nobody has written a CLR target. And on the other hand, I don't know why there couldn't be a Scala implementation with true generics. A lot of crap like DummyImplicit and ClassTag is there for no other reason than to work around those limitations anyway.

Scala had a CLR target for a number of years, but getting the type system to work was so problematic it was eventually abandoned.

I'm curious in what sense it was difficult to get it to work.

Re: I was wrong, reflecting on the .NET design choices

#139

Post by paulddraper »

emodendroket wrote: post #138
paulddraper wrote: post #131

Earlier quoted context omitted.

Scala had a CLR target for a number of years, but getting the type system to work was so problematic it was eventually abandoned.

I'm curious in what sense it was difficult to get it to work.

Perhaps not the best explanation but this the gist, as given by Scala's creator in an interview https://youtu.be/p_GdT_tTV4M

> It's harder then it looks, because .NET has a very rich type system which happens to be not the Scala type system. In fact, it's very hard to map some of the parts of the Scala types like higher-kinded types...so it's a difficult task, much more difficult than JS or LLVM. LLVM is likely going to be the third target [after JVM and JS] because there we don't need to fight a type system which is foreign to us, which is what the .NET one is.

Post reply on HN