3 ms·
> Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations, That's true (and will be addressed
by pron 8y ago
> Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations,
That's true (and will be addressed), but that's a problem that can be fixed by adding a feature, not removing a central one, which is why I said that both Java and .NET have made mistakes, and reified generics was one of .NET's.
> or switch-on-type, for functional languages.
There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. Perhaps you mean switching on A<Foo> and A<Bar>, where Foo and Bar are reference types (and possible with a subtype relationship between them), well even Haskell can't do that, and if there was a language that thought this is a good idea, it would be able to do it quite easily.
- willtim 8y ago> That's true (and will be addressed) Glad to hear it! It's probably the biggest issue trying to do functional programming on the JVM. > There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. The technique to implement ADTs in functional languages on the JVM has often been to add an integer tag to every subtype and switch on that, but it's ugly enough for interop that IIRC Scala doesn't do it (and is thus less efficient).