> I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling
I'm not so sure about that. Java (both the language and the VM) is relatively unique in its mix of static (mostly in the sense of being typed) and dynamic (all linking is dynamic; code is often be loaded, unloaded and generated at runtime; reflection and general introspection of the runtime is pervasive). It's a blend of, say, ML, Smalltalk and Erlang. The module system is therefore more impressive than it may look at first glance. While not all the tooling is there yet, through the use of what it calls "layers", it makes it possible to dynamically load plugins or even upgrades to components in the system, each depending on different versions of the same library, while enforcing customizable levels of isolation between them. Whether or not there are any conflicts requiring a separation of "layers", can also be determined at runtime by introspection.
Other than (its botched version of) parametric polymorphism (due to how easily it can be circumvented, defeating the entire point to it), what ML-influenced features does Java actually have? There is no global type reconstruction, there are no abstract types, and “computation as expression evaluation” is a royal pain in the rear hole in Java.
Oh, I simply meant any safe, typed language, and that was the first that came to mind.
Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures). I think interfaces (and the ability to override methods like `equals` are pretty close to abstract types. I also strongly disagree with your description of Java's parametric polymorphism being "botched", and certainly not that its "entire point" is defeated. That it can be circumvented is what makes code and data sharing between different languages with different variance models possible (compare to how badly that's done in .NET). So it's simply a matter of what requirements are more important to you.
I can understand those that think that Java not being fully static or fully dynamic may defeat the whole purpose of what they like in their preferred approach. But I think that Java combines static and dynamic aspects in a rather unique and novel way, and the new module system is not different, combining in an interesting way both static and dynamic aspects.
> Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures).
The whole point to structures and signatures is abstract types. Mere value hiding can be achieved with let, which isn't exactly the pinnacle of typing: Scheme has it.
> I think interfaces (and the ability to override methods like `equals` are pretty close to abstract types.
Please do tell how you would make two or more instances of an abstract type in Java, in such a way that:
(0) The client is aware that that the two instances have a common type.
(1) The client is not aware of the representation.
If it's not possible, then Java doesn't have abstract types, period.
> That it can be circumvented is what makes code and data sharing between different languages with different variance models possible
And unsafe. (No, memory safety alone isn't safety.) If it's going to be unsafe, then I better at least get my money's worth in terms of performance, which is why low-level languages like C and Rust are the only ones worth FFI'ing to.
> I can understand those that think that Java not being fully static or fully dynamic may defeat the whole purpose of what they like in their preferred approach.
Java is fully dynamic. “Type checking” in Java is basically a mandatory linter.
> Please do tell how you would make two or more instances of an abstract type in Java, in such a way that...
By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`.
> And unsafe.
It seems like you're defining "safe" to be precisely what the languages you like provide, no more and no less. I can say that ML and Haskell are unsafe because they don't statically forbid erroneous behavior at runtime, like a sorting function that doesn't sort (or doesn't terminate). Java has no undefined behavior. In fact, it is completely unknown how much safer -- if at all -- is ML than Java in practice.
> If it's going to be unsafe, then I better at least get my money's worth in terms of performance, which is why low-level languages like C and Rust are the only ones worth FFI'ing to.
Of course it's a matter of specific requirements, but I think you get more than your money's worth in terms of performance in Java, and having decades of experience writing huge multi-MLOC programs in both Java and C++, I'm convinced that it takes significantly less effort to get a well-performing large Java app -- especially if it's concurrent -- than a C++ app, even though you could surpass Java's performance given considerable additional effort. In any event, I think that the success of the JVM shows that many people find supporting it to be worth it.
> Java is fully dynamic. “Type checking” in Java is basically a mandatory linter.
This is simply untrue. Java is mostly type safe. If you have a variable of type `Foo` in your program, it cannot reference an object of a type that is not `Foo` at runtime. You are right that this does not extend to generic types, but only if -- 1. you've intentionally tried to circumvent the type, or 2. you've fallen victim to an obscure bug that was found recently, and is very hard to reproduce accidentally.
> By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`.
That's not an abstract type, it's an object type. An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program. OTOH, objects with the same type may have different internal representations, determined by whoever constructs the object, just as in your example.
> It seems like you're defining "safe" to be precisely what the languages you like provide, no more and no less.
Safety is defined in terms of the language's semantics, not my personal preferences: are meaningless operations ruled out or not? (We can get technical and say that Java does, in fact, assing a meaning to invalid casts: to throw ClassCastException. But very few people would consider that a useful meaning: if you run into it, your program plainly has a bug.)
> An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program.
So, like:
<T> foo(A<T> a, B<T> b) { ... }
You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type.
> Then it isn't.
That it's not completely typesafe (Scala isn't, either, BTW) doesn't mean that it's not completely safe. The vague notion of safety is not defined by the arbitrary notion of type safety, which heavily depends on the type system. TCL is typesafe, but few would say it's safer than Java.
> But very few people would consider that a useful meaning: if you run into it, your program plainly has a bug.
There are many more plainly incorrect behaviors that aren't prevented even when the language is 100% type safe (depending on the type system, and the effort required to encode the correctness conditions) -- as Java prior to generics was, BTW. So if you want to define "safe" as "typesafe", that's fine, but given than ML's and Java's type systems are of similar (not identical, but similar) richness (i.e., they are both simple type systems with parametric polymorphism), and given that you don't actually run into `ClassCastExceptions` in Java unless you choose to do stuff that can get you into that sort of trouble (which would mean ignoring compiler warnings), I think the two languages offer a similar level of safety.
> So, like (...) You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type.
Abstract types are existentially quantified, whereas generic type parameters are universally so.
> Scala isn't, either, BTW
Scala isn't type safe either, period.
> So if you want to define "safe" as "typesafe", that's fine, but given than ML's and Java's type systems are of similar (not identical, but similar) richness (i.e., they are both simple type systems with parametric polymorphism)
Actually, Java's type system is more complicated, since it has subtyping, as well as a limited form of first-class existentials (wildcards) that Standard ML doesn't have, yet somehow Java buys me less safety than Standard ML. This is what happens when engineers design programming languages.
> and given that you don't actually run into `ClassCastExceptions` in Java unless you choose to do stuff that can get you into that sort of trouble (which would mean ignoring compiler warnings), I think the two languages offer a similar level of safety.
There are no runtime type errors at all in Standard ML.
interface A<T> {
T x();
void y(T t);
}
void foo(List<A<?>> as) { // every element may have a different instance of T
for (A<?> a : as)
bar(a);
}
<T> void bar(A<T> a) {
T t = a.x();
a.y(t);
}
> There are no runtime type errors at all in Standard ML.
There are no runtime type errors at all in TCL, either. That doesn't mean that the language is safer. "Safety" and "type safety" are not the same. Type safety has its virtues, but I would argue that Java's type safety is good enough; I would take it along with its dynamic capabilities over SML for many projects -- it's just a tradeoff that buys you a lot of other stuff. There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List), and that's a price worth paying in many cases, considering that it's not high at all.
> This is what happens when engineers design programming languages.
I guess engineers prioritize things based on what they're actually worth to developers (or, at least, according to how much they believe they're worth to their developers) as opposed to using an arbitrary metric for some intrinsic quality, whose relationship with actual benefit isn't at all clear. Java sacrifices a tiny bit of type safety for interop and various dynamic capabilities. I wasn't aware that there's been some major discovery showing that this is the wrong tradeoff to make.
Kind of, but, with wildcards, you still don't get the ability to unpack the existential for arbitrary further use. You can only unpack the existential within a single method, which is unnecessarily restrictive. If you unpack the same existential package twice (say, because you need to do it in two different methods, neither of which calls the other), then, as far as the type checker cares, that produces two different abstract types. Programming with abstract types in Java is a pain, which is why (understandably) Java programmers don't do it.
> There are no runtime type errors at all in TCL, either.
Yeah, but you don't get basic things such as integers, which is even worse.
> There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List)
Anyhow, the only thing I wouldn't want to do in Standard ML is manipulate arrays, mainly because runtime bounds-checking is unnecessary when you get your array algorithms right, but Standard ML requires it anyway. Interoperability between two memory-safe languages is completely useless to me.
> and that's a price worth paying in many cases, considering that it's not high at all.
Any price is high when you get nothing in exchange for it.
> Programming with abstract types in Java is a pain, which is why (understandably) Java programmers don't do it.
OK, but I never said Java is ML. The example I provided is not uncommon.
> Interoperability between two memory-safe languages is completely useless to me.
Fair enough, but it's clearly not useless to many people.
> Any price is high when you get nothing in exchange for it.
I think that polyglotism and dynamic capabilities are a good deal, and I think that many others find it at least as useful as complete type safety, but, of course, that depends on your needs and personal preferences.
>> Please do tell how you would make two or more instances of an abstract type in Java, in such a way that...
>By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`.
This is not i believe what he is talking about, here is a silly example in SML, it has 3 types which all share a type t...
a list of t pairs, a vector of t's, and a function from pair of t's to t.
functor Foo (type t;
val pairs : (t * t) list
val f : t * t -> t)
= struct
val things : t vector = Vector.fromList (List.map f pairs);
end
One thing to note is that t is never exported/returned.
and thus, the thing returned exports t vector but not t.
we could export t in a few different ways:
type t = t; Export it, let its binding be known
type t; Its a type, but what it is bound to is not known.
I'm not so sure about that. Java (both the language and the VM) is relatively unique in its mix of static (mostly in the sense of being typed) and dynamic (all linking is dynamic; code is often be loaded, unloaded and generated at runtime; reflection and general introspection of the runtime is pervasive). It's a blend of, say, ML, Smalltalk and Erlang. The module system is therefore more impressive than it may look at first glance. While not all the tooling is there yet, through the use of what it calls "layers", it makes it possible to dynamically load plugins or even upgrades to components in the system, each depending on different versions of the same library, while enforcing customizable levels of isolation between them. Whether or not there are any conflicts requiring a separation of "layers", can also be determined at runtime by introspection.