Hacker News Reader

Comment by alkonaut | Hacker News Reader

Feels like it needs proper (reified/runtime) generics in order to be useful. Reified generics and value types would be a complete and long overdue break in backwards compatibility.

But

It's a bit sad how java struggles to become a C# from five years ago. Would make a lot more sense to leave java alone, add reified generics and value types at the bytecode/vm level and instead launch a new language that could use all of it.

Throw in pattern matching, algebraic data types and a bit more and I'm sold.

View on HN

> Feels like it needs proper (reified/runtime) generics in order to be useful.

Actually type-erasure is one of Java's best features, because it didn't cripple the runtime for other languages. For example Scala's type system is too expressive to be built on top of .NET's generics.

First of all, reification only helps in terms of type-safety if you have a weak type system. The only value that reification, as implemented in .NET brings is specialization for value types.

Second of all, specialization can be done by the compiler. That's how many languages have always done it. Scala for example has a @specialized annotation for specializing type parameters for primitives [1]. And because this functionality has some gotchas, there's also an up&coming project plugin that's meant to be a replacement in future versions of Scala and that works really well [2]

I myself have used the @specialized annotation on many occasions and in general it does what it's supposed to do. And if that means I can develop in languages like Scala, Clojure and JRuby on top of the JVM, then I really, really love type-erasure. And oh, apparently one barrier for implementing type-classes in F# are the generics in .NET ;-)

> It's a bit sad how java struggles to become a C# from five years ago

What I find sad is grown men that can't see the forest from the trees. Java, the language, is totally irrelevant and uninteresting and I like it that way, because it's the kind of language you can rely on in case you want backwards-compatibility (yes, that's a feature). On the other hand, the JVM is light-years ahead of the CLR, because that's what the Sun, now Oracle engineers have been doing with all of their time.

> pattern matching, algebraic data types

See Scala. It also does type-classes and higher-kinded types, amongst others that F# is not capable of.

[1] http://www.scala-lang.org/api/2.10.3/index.html#scala.specia...

[2] http://scala-miniboxing.org/

...

People keep repeating this stuff and they're totally wrong. F* is dependently typed and is a CLR language.

bad_user, have you ever actually attempted to write a type unsoundness proof for your claim or are you just repeating something you heard somewhere?

https://visualstudio.uservoice.com/forums/121579-visual-stud...

This is so that F# could have higher-order types and interop them with other .NET languages. F#'s type system is simple partly because it strives to use the existing CLR type system, limitations and all.

If you have no such requirements (e.g., Scala, where there's no requirement that Java be able to consume or interpret all of Scala's types), then you can most definitely define a language for the CLR which does this.

F* is not a typo -- that is not F#, it is a separate language.

I am very interested in F*, I heard about it and I'm waiting eagerly for something polished.

Personally I don't like F#, the result, because on one hand you've got the Hindley-Milner type system and on the other hand you've got OOP with .NET generics. It resembles Ocaml in philosophy (I'm sure this wasn't by accident), in that it feels and smells like 2 type-systems in the same language. It's just an opinion of taste of course - but would have anybody used F# if it didn't integrate well with .NET's standard assemblies? So F#'s integration with .NET's generics is very understandable and one reason Scala.NET died was because it was too hard to keep the semantics of Scala, while also integrating well with .NET, which meant the project was interesting only for people wanting to port their Scala code to .NET - for which approaches like IKVM.NET were far better options. I think somebody wrote an interesting paper on Scala and .NET's reified generics, sadly I can't find it right now.

You may have gotten annoyed about hearing this thing about .NET generics not being expressive enough - I also get annoyed hearing about how Java sucks because it doesn't have reification for generics or other such things, when in truth the compiler can handle specialization just fine and both approaches (runtime versus compile-time) have merit and make different compromises.

BTW, I see that you're working on the Roslyn team - you guys are doing great work lately. Keep it up.

Thanks. :)

I happen to agree with you -- I think the technical limitations in both languages/VMs are highly overrated. Java, especially, has been a victim mostly of insufficient leadership and resources, not any fundamental technical issue.

C/F# and the CLR, meanwhile, are probably most limited by backward compatibility.

There is nothing stopping a language implementer from ignoring CLR generics and leveraging erasure to do their own thing. The problem is that such a language is basically cut off from providing a bridge interface to any CLR library that uses generics. I would guess this is why many core Microsoft libraries (say WPF) don't use generics even though they could (but it could just as much be that they were started before generics were pervasive in C#).

The LAMP team actually got pretty far with Scala on the CLR. The reason it didn't go farther was more due to a lack of interesting and funding.

Yup, I mentioned this in a comment below -- interop is always the problem. Then again, anyone who has looked under the hood and seen just how much MS stuff is based on COM knows all about that.

I'm not saying erasure is a bad idea for the jvm, but from a java perspective it's horrible. Not having structs or primitive/struct collections makes all types of low level interop and/or high perf (e.g game) programming cumbersome.

Specialization for value types (including ones not known at compile time) is the main point imho of reified generics, yes.

I like scala and agree that F#'s typed sometimes feels like the bastard child of ML and C# (although I do like ML syntax better).

I agree with you that the backwards compatibility of java is a feature now, since so many other languages incorporate what we'd otherwise want to see in java.

I thought that compile time specializations wouldn't reach all the way, just like C++ templates don't.

Your comment made me wonder if there was an F# implementation for the JVM. This is the only one I could find, and it is still very young:

https://github.com/penberg/fjord

I'vea heard that its on the cards for 9/10, isn't it? (reified generics)

Try Haxe. http://haxe.org/ You get pattern matching, algebraic data types, and much more. And you can also target Java or C#

He meant a language with an actual ecosystem and hundrends of thousands of users, like Java. Haxe does not qualify at the moment...

You can use java jars with the -java-lib flag. The whole library ecosystem is available. There's not as much IDE tooling for Haxe, but Haxe is a lot more succinct. I haven't needed that as much.

Java like most open standards suffers from design by committee, whereas C# so far had Microsoft alone dictating where to go.

Add the Sun troubles into the mix, and slow the features go.

Reply on news.ycombinator.com