Two words:
ivory tower
Retrofitting concepts into languages where there's little *real* benefit
serves only to waste resources that could be better spent elsewhere --
and to risk breaking things, e.g. backward compatibility, that do have
real, tangible benefit.
We're in the real world, developing real software. Nothing is perfect
and no one has the luxury to repeatedly up-end everything to rework
everything that wasn't 100% perfect. Sure, when there are serious
issues you go back and rework things, but there are time/resource vs.
compability/migration-cost vs. perfection vs. .... tradeoffs that one
must carefully weigh. That's one reason it's called software engineering.
On 10/15/2012 6:37 AM, Kevin Wright wrote:
On 15 October 2012 12:01, Reinier Zwitserloot <[email protected]
<mailto:[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.
--
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.
