Re: [scala] Option vs null

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Kelly wrote:
| Tony Morris wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Barry Kelly wrote:
|>> Tony Morris <tmorris@...> wrote:
|>>
|>>> Personally, I'd delete the String function and write a String ->
|>>> File implicit
|>> I sincerely hope you aren't serious. Strings aren't files, and
|>> implicitly converting one to the other is a gross sanity violation
|>> - consider a lexical analyzer that can scan string text or source
|>> from a file (and thus might be overloaded on both): in this case,
|>> the string isn't a logical pointer to the file, but rather the
|>> other way around, the file is a pointer to the source text.
|>>
|>> Would you then suggest a File -> String implicit? So that there is
|>> an asymmetrical bidirectional conversion between strings and files?
|>>
|> I'm serious (and so is Jesper it seems). The sentence "Strings aren't
|> Files" doesn't parse for me
|
| 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

However, when you analyse the details, you discover an isomorphism of
the structure of each algebra. It is bit like saying "construction of
logic theorems and computer programming are not the same thing", since
they "seem" and "feel" like different things. Indeed, they have
different "fuzzy" connotations attached to each. However, fundamentally
we *know* they are empirically the same thing (C-H Isomorphism) and that
any suggestion that they are different is merely the projection of our
own narrow (and prior to the discovery by Curry-Howard, ignorant) views.

|
| 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.
When you say "intend it to map to ..." I say "define functions across
the structure". This is just more accurate reasoning to remove the
fuzziness. Once the fuzziness is gone, I'm sure you'll shift your
position. That you, personally, to appease yourself and your biases,
independently of the software, which exists externally to you, wish to
project a different fuzzy meaning on two equivalent structures, is only
going to contribute to - at worst - an impoverished view for you of what
is really going on.

|
| 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.
WTF?

|
| 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.

These fallacious distinctions are *incredibly detrimental* to software
development because humans are fallible - even with just my own personal
anecdotes over the years. I have met your assertion with my own, which I
am committed to as much as you are yours. The question now is, are you
prepared to explore this path and possibly shift position? I am, but
you'll have to bring some new arguments to the table.

|
| 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.
We have improved our reasoning process by identifying the true structure
of our program, instead of artificially and arbitrarily elevating the
status of labels that we wish to attach to it.

Would you object to me calling this "Option"? How about "Maybe"?

sealed trait Null[+A]
final case object Nup extends Null[Nothing]
final case class Yep[+A](a: A) extends Null[A]

What about this? What do you call it?

sealed trait Disjunction[+A, +B]
final case class OneTheorem(a: A) extends Disjunction[A, Nothing]
final case class TheOtherTheorem(b: B) extends Disjunction[Nothing, B]

The Scala community agreed that we'd call it "Either", but does it matter?

Here are some facts; we can define a covariant functor and a monad
across the Null structure. For some other structures, this is not true.
Indeed, not for Disjunction! (it is not even well-kinded; we fail
immediately). These are just observations about the so-called *real
world*. If I were to vanish tomorrow, these observations stand.

|
| 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.
This fuzzy notion of "semantically equivalent uses" is ill-defined and
is unlikely to ever eventuate into a consistent definition. I'm sure
you'll try and I'll probably have to respond with a Socratic
midwife-like response, until eventually the mailing list gets annoyed
with me :)

Nevertheless, if I find myself "being fuzzy" or "unable to define
consistently under critical examination", either through self-reflection
or assistance from peers, then I have a mental defense system that sets
off warning bells, which is why I never use such informal reasoning. It
misleads us only into states of mental inconsistency.

|
|> 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! :)
Labels are useful, but they denote a structure or concept. The same
label for the same structure does not make the structures different,
which is at the very essence of the computer program (again, C-H
Isomorphism).

What label do you attach to this structure?

\a b -> b
\a b -> a b
\a b -> a (a b)
\a b -> a (a (a b))

Most people call it "the set of natural numbers". We can run with that.
In fact, you can call it "poop" if you like. As long as we have
agreement on the structure itself, it is not going to matter to the
intangible software.

|
|> 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.
The "real world" where "real complexities" are "practiced professionally"?

Oh I know, you mean the one where there are mathematical structures that
exist independently of our own biases, yet we feel compelled to project
labels on them and pretend that other labels denoting the exact same
structure are in some way distinct because we take comfort in our own
ignorance? Or, are you talking about a different real world to the one I
find myself in? I find the above paragraph quite telling and my sarcasm
is not intended to belittle, but display my shock.

You're stepping into the land of being blatant with logical fallacy here.

To address your statement more bluntly (let's assume good will and not
fallaciousness as always), in this real world, software is *seldom
practiced professionally*. How many programmers do you know who have
none or very little idea about the very basic and essential fundamental
tenets of the theory of computation? Since we're on this topic, turn to
the person next to you and say "Curry-Howard Isomorphism" (or insert
equivalent should you so choose). What response did you attract? I get
googley eyes and a "WTF are you talking about?' look. This would be OK,
if the respondent had independently discovered this themselves and just
not had a label (C-H-I) to attach to it, but I am assuming this is not
the case.

Now go to your local mechanic and say "spark plug"; same response?
Didn't think so.

Furthermore, the so-called "real complexities of software engineering"
have very little to do with how we label structures. I am fully aware of
the deception in industry that dilutes the true contentions in computer
programming (like you know, the halting problem for example). In any
case, the evidence is all around you. I mean "Java bean"? "Actor"?
"LINQ"? Do these words have any meaning at all? For example, a smart
programmer looks at LINQ and just says "oh that's a glorified monad".
Does this act of "renaming" cause him problems? Actually, quite the
opposite - since he can show that they are precisely the same thing (in
fact, a specialisation in this case), he can draw on his understanding
of *the concept of monads* and fully understand LINQ in the flash of a
brief thought.

Software is in the abstract, always was and is today - they just don't
tell you that at school anymore (I do in my tutorials, but always
afterward in spare time where students are keen to learn). Ever wonder
why Microsoft hit it so big? Can you really make money with an
intangible artifact? The naysayers didn't think so, but at least all
parties (Microsoft and the naysayers) were equipped with the knowledge
that software is intangible. That we find ourselves in a somewhat
altered (distorted?) situation today does not alter this fact.

A brief and related thought fondly reminds of the gross ineptitude that
surrounded me in my recent, but foregone days working for IBM Software
Group :) I won't share it with you, for brevity's sake :)

|
|>> (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
|
I'm out of breath anyway, how about you? :)

- --
Tony Morris
http://tmorris.net/

Real-world problems are simply degenerate cases of pure mathematical
problems.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIdUvYmnpgrYe6r60RArorAJ0TMXORb5HlaDX2sxpROrL4aRjFFwCfW62u
wPU8MlEXSf6UiMgV9v/4lS0=
=jYRU
-----END PGP SIGNATURE-----