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. 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). 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. 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. 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. (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. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Wp9yCvXlbrUJ. 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.
