On 15 October 2012 12:01, Reinier Zwitserloot <[email protected]> wrote:
> On Monday, October 8, 2012 1:33:06 AM UTC+2, Simon Ochsenreither wrote: > >> I think it is an interesting example how some "pragmatic" and >> superficially simpler approach tends to break down and cause complexity in >> both the spec and the implementation compared to the "academic" solution. >> > > Yes, java has no type that represents "there is no value that is this > type, not even 'null'". It would be cool if this type existed; a method > that had this as return type cannot actually return, ever. It has to exit > abnormally: Either it runs System.exit(0), which should probably at that > point return this special Nothing type (so that you can type: return > System.exit(0)), or it has to throw an exception. There are no other ways > out. > There are other cases too, it also crops up in recursion where there's absolutely no information whatsoever available for type inference. Just consider: def method[A](x: A): A = method(x) Something like this, without tail recursion, would ultimately crash the JVM with a StackOverflowException. More importantly though... even given a variant that did terminate and didn't stack overflow, what type could reasonably be inferred *except* for Nothing? > Unfortunately, introducing this kind of concept is exactly the kind of > thing java does NOT do, and languages like Scala DO do: it's not a matter > of superiority, it's a matter of tradeoffs: If this Nothing exists, it > cannot actually be a subtype of Object; a List<?> cannot accept an instance > of List<Nothing>, because I can still put nulls in List<?>, and nulls are > not a valid value for Nothing. Hell, generics in general play havoc with > this: Using trickery I can make a List<Nothing> with nulls in it, and then > write return thisHackedList.get(0), which means in practice that Nothing > needs type checking (i.e. that would lead to a ClassCastException or > similar, even if .get(0) returns null). > Fortunately, this is *exactly* you you want to do with an immutable list! The only way to add an element to an immutable list is to create a new list containing the old one as a subset. This means that the type of every element in the existing list must subclass the element type of the new list. To put it another way, this means that the element being added to an immutable list must be a superclass of the element type of all elements already in the list. And, because such lists are immutable, they must be built up by starting with an empty list. This empty list must have an element type such that *anything* you might add to it is a superclass. The element type of such an empty list MUST be the subtype of every other type in existence. That type is Nothing, and Scala's empty list (called Nil) is, indeed, an instance of List[Nothing] List[Nothing] not only makes sense, it's actually a necessary requirement to get immutability right. It also only works if Nothing is very much a subclass of Object, and Null, and anything else you care to mention. > That's the kind of thing where java has decided that the practical upside > of having a 'Nothing' value is not actually that much; it's largely > academic, and it definitely "feels bad" that the language is not complete, > and that this awesome concept is not actually in your language. However, > adding it to the language definitely incurs a cost: The compiler needs to > do all sorts of things to treat Nothing specially, and this is going to > make the spec much more complicated. > What of the cognitive cost to having this concept that developers must necessarily encounter, then forcing them to use hacks and workarounds because it cannot be represented in their programming language? > Scala-like design says you accept the complexity hit, and theorizes that > if you go whole-hog on this you can actually remove a lot of complexity > because the language is much more flexible. So far that seems like it's > been working out reasonably well for scala. The java-like design says that > these mostly academic features just aren't important enough, and in > practice the language will be simpler if you just don't have them. Where > people need them, they'll kludge it. > Isn't that what they tried with Date? and then Calendar? > Sounds ugly. Yet, java's popularity and the robustness of java-based apps > like google ads and many a server out there suggest it's fine. > It's a testament to what a decent developer is able to work around, but the ecosystem developed on the back of Java's strengths and in spite of its flaws - not *because* of its flaws! (Some newer languages got all of this right from the start.) >> > > Right. I'm saying, well, the jury is still out on this. Is it actually > right to burden your language with the Nothing concept? > > I'm pretty sure that retrofitting Nothing onto java is a grave mistake at > this point. > > I fear that the bigger mistake is to add lambdas, and immutable structures, and the whole the-free-lunch-is-over-my-GPU-has-1000-cores-we-desperately-need-to-get-concurrency-right infrastructure, then to cripple it by missing something so fundamental from the type system! -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
