Re: [scala] Option vs null

Tony Morris wrote:

I think we are speaking in different languages. Here's an explanation of
what I mean when I use words like "Strings", "Files", and "is" (plural:
"are") (I trust you know what "not" means :) :-

"A String" is an instance (i.e. a value) of the java.lang.String class,
where the java.lang.String class is intended to represent immutable
arrays of characters - i.e. character strings, aka text information.

"A File" is an instance of the java.io.File class, where the
java.io.File class is intended to represent a file or directory path
name.

When I use the word "is", I am asserting some level of semantic
equivalency between the subject on the left of the "is" and the object
on the right, for some context, which itself may be explicit or implied
by prior sentences or emails. As in any human language, there is a
little fuzziness in here. I hope you are able to follow ;)

E.g.: when I say "this String is the path to a file", I am asserting
that the *meaning* (in the programmer's mind) of 'this' String value is
that it can be interpreted by the OS as the location of a file in some
filesystem.

So when I say "Strings aren't Files", I am asserting that there isn't a
semantic equivalency between Strings and Files. The basis of my claim is
that their types have different semantic intent, as documented in the
Java platform documentation[1]. Certainly, some Strings may be paths to
files, and many Files are paths to files (and not directories, or
non-existent files or directories), but I trust a trivial survey of
real-life programs will demonstrate that the vast majority of Strings
are not employed as paths to files.

[1] See:
http://java.sun.com/javase/6/docs/api/java/lang/String.html
http://java.sun.com/javase/6/docs/api/java/io/File.html

I am of course interested in pragmatic concerns over theoretical
correspondences; many different things can be mapped to a single set,
and each operation shown to be mappable to a corresponding equivalent
operation on the single set, and thus be shown to be isomorphic, but
this isn't interesting for solving real-world problems. In order for our
solutions to help with the real world, the elements of our problem
domain need to map onto real objects in the real world, where
theoretical correspondences between our abstractions no longer apply.

To make that more concrete, let me give an example:

- I might use a location for String values called 'name', and intend for
that to map to a person in the real world (assuming other constraining
factors that remove ambiguity).

- I might similarly use a location for File values called
'homeDirectory', and intend for it to map to some range of iron oxide
particles contained in a metal box underneath my desk.

Now, String and File might have, with appropriate contortions, an
isomorphic set of values and operations, but there is in no way a
similar isomorphism between a person in the real world and a pile of
rust inside a small metal box - at any level humans (who pay software
developers their wages) care about.

These distinctions (the kinds between Strings and Files) are important
in software engineering, because humans are fallible. If everybody used
Strings both when they needed names of people and paths for files on
disk, there is a danger (because they are fallible, don't forget that)
that they might confuse the two somewhere, and mistakenly look for a
person inside a metal box, or insult someone by describing them as a bit
rusty.

This is why I say things like "Strings aren't Files". Because if we go
down that path, we have lost a valuable guard against human fallibility.
By enabling implicit conversions between Strings and Files, we muddy the
gap between the two.

And most importantly, because Strings and Files are rarely put to
semantically equivalent uses, implicit conversions between the two are
ambiguous and conflicting. I tried to make this clear to you by giving
you an example; if you create a String -> File implicit conversion, and
justify it by appealing to isomorphism, then you can't object to a File
-> String conversion that was the inverse. Unfortunately, an alternative
obvious File -> String conversion also exists; that of reading the
contents of a file on disk into memory as a String; and we have the
aforementioned ambiguity and conflict.

> because I reason about software using a
> different method and without labels.

Labels are useful. Function and parameter names are labels. I wonder how
successfully you program in the large without named functions or
parameters? Even the lambda calculus needs a parameter name! :)

> The structure of a File
> (java.io.File) as an algebra is isomorphic to a String

I have explained why an isomorphism between any two pairs of (set and
operations on elements of the set) is not particularly interesting for
solutions that people pay wages for - i.e. representing real-world
problems - and also why it is important that the distinction between
what may theoretically be isomorphic algebras is made clear.

In summary, your justification for your suggestion strikes me as naive,
narrow-minded and dangerous. It seems to ignore the real world, and the
very real complexities of software engineering as practiced
professionally.

> > (I also wish someone would fix the missing Reply-To header in this
> > mailing list...)
>
> It's been discussed numerous times and I think the conclusion was to
> leave it as is. I don't know the details because I seem to care less
> than others do, but you might be interested in looking at these
> previous threads to get more details.

It's unfortunate for me primarily because it breaks threading in my mail
reader; and the default action for a reply drops the mailing list from
the conversation.

The conversation moves from the mailing list folder to my inbox because
the sender of the reply is no longer the mailing list, and the mailing
list doesn't deliver duplicates when it is CC'd on a reply.

As it stands, I don't think I'll be contributing many replies to the
Scala mailing list, as I don't want to clog the aforementioned inbox.

-- Barry

--
http://barrkel.blogspot.com/