Lambda the Ultimate

inactiveTopic Java and Pointers
started 1/14/2003; 1:05:39 AM - last post 1/16/2003; 12:24:11 AM
Ehud Lamm - Java and Pointers  blueArrow
1/14/2003; 1:05:39 AM (reads: 2295, responses: 13)
Java and Pointers
Keith posts some nice links about the Java-doesn't-have-pointers language myth.

Why did I put this message in the OOP department? Well, using reference semantics is something OOP languages do, some may even say it's something compiled OOPLs have to do -- but I still find it ugly.

We work so hard to establish abstraction boundaries, only to have programmers return references to internal arrays and such by mistake.

Well, anyway, that's life.

Posted to OOP by Ehud Lamm on 1/14/03; 1:06:31 AM

Ehud Lamm - Re: Java and Pointers  blueArrow
1/14/2003; 5:04:37 AM (reads: 1171, responses: 0)
It should be noted that this issue is quite relevant to teaching programming. Some people assume that by using language like Java you eliminate the need to teach students about pointers. This is a rash conclusion.

Michael Vanier - Re: Java and Pointers  blueArrow
1/14/2003; 9:14:28 AM (reads: 1125, responses: 2)
Hmm. Having reference semantics doesn't automatically mean that you have to deal with null pointers or their ilk. Ocaml has a much nicer system wherein the equivalent of "null" can only occur if you use a type that specifically allows it (the "option" polymorphic type). Real references in ocaml must be initialized with a non-null value, so the null pointer exception can't happen. This can be odd at times -- you create an empty list reference and then later just substitute in a completely different list -- but it's safe. Haskell's monads give even more power; you can chain operations which return option types so that the unpacking of the option is totally transparent. Which allows you to -- *gasp* -- get the null pointer semantics *back* in a pure functional language! Hey, that's progress ;-)

Michael Vanier - Re: Java and Pointers  blueArrow
1/14/2003; 9:17:23 AM (reads: 1127, responses: 0)
Another point. Having spent way too much time wrestling with C's pointers, I have to say that java's NPE doesn't scare me at all. If that's the worst that java can do, then my life as a programmer is going to be pretty sweet compared with all the stuff that can happen in C (memory corruption, leaks etc.). BTW if you're a C programmer you absolutely, positively, MUST check out valgrind, which is sort of like Purify on steroids (a very powerful memory bug checker).

Patrick Logan - Re: Java and Pointers  blueArrow
1/14/2003; 6:25:18 PM (reads: 1077, responses: 1)
Yes, an NPE in Java at least does not corrupt the application in unspecified ways. At a minimum some kind of orderly shutdown can take place.

Beginning programmers should use functional languages or functional subsets of languages in order to avoid altogether the idea of call by reference and side effects. Eventually they should learn about these concepts, and regretably they should learn about C and pointer arithmetic too. More interesting, and a separate topic, is the idea of appropriate use of "exceptional values" in even functional languages.

Any interesting application in any language is going to exhibit a need for "exceptional data" sooner or later. For these situations, the languages equivalent of "null" should not be used.

The simplest example of this could be the Maybe type n Haskell:

data Maybe a = Just a | Nothing

but this is really another kind of "null".

Better, but more complex examples, are described in Ward Cunningham's Checks pattern language which is really language independent.

Ehud Lamm - Re: Java and Pointers  blueArrow
1/15/2003; 12:13:41 AM (reads: 1092, responses: 0)
NPE is not the only problem with using references. Let's not forget aliasing, which is at least as problematic.

Daniel Bonniot - Re: Java and Pointers  blueArrow
1/15/2003; 2:50:03 AM (reads: 1074, responses: 1)
The Nice language has option types: ?String is the type of values that are either a String or null. Packaging is transparent, because of the subtyping String < ?String (in caml you need the Some constructor, and IIRC Haskell needs Just, or return if you use monads). Unpackaging can be done by testing to null:

?String x = ...;

if (x != null) /* here x has type String */

The good thing about it is that it is quite straighforward compared to monads. It looks like mere case analysis.

You can also define higher level operators: x || "default" evaluates to the value of x unless it is null, in which case it is "default". This expression has of course type String.

Ehud Lamm - Re: Java and Pointers  blueArrow
1/15/2003; 6:17:08 AM (reads: 1086, responses: 0)
We started with pointers but we moved on to something much more interesting. It seems that many language designers (esp. of modern languages) noticed that missing values are common, and more importantly a common cause of errors.

This seems so obvious one has to ask why so few mainstream languages provide dedicated constructs for dealing with this issue.

Frank Atanassow - Re: Java and Pointers  blueArrow
1/15/2003; 7:50:04 AM (reads: 1008, responses: 1)
The simplest example of this could be the Maybe type n Haskell:

data Maybe a = Just a | Nothing

but this is really another kind of "null".

Not quite.

First, Maybe a is distinct from a, so the programmer is forced to check it.

Second, Maybe (Maybe a) is distinct from Maybe a, so there can be multiple exceptional values.

Third, Maybe forms a monad, so error-checking code can be modularized and separated from applications which require it.

Patrick Logan - Re: Java and Pointers  blueArrow
1/15/2003; 8:28:36 AM (reads: 1009, responses: 1)
References and aliasing - yes, good point.

"Maybe a" is distinct from "a" - yes, another good point.

"We started with pointers but we moved on to something much more interesting." - and a very good point. I am also surprised how little attention this gets in the mainstream.

Ehud Lamm - Re: Java and Pointers  blueArrow
1/15/2003; 8:37:12 AM (reads: 1047, responses: 0)
The paper on Haskell exceptions is very well written. I recommend reading it.

Ehud Lamm - Re: Java and Pointers  blueArrow
1/15/2003; 8:45:08 AM (reads: 1043, responses: 0)
On a side point, one of first DSLs I worked with was an in house query language that had special rules for processing missing and invalid data. They were grouped when sorting, propagated through calculations (i.e., 3+invalid = invalid) etc.

This was a minute detail in the language design, but it was crucial. The language (well, the first version anyway) didn't have if statements and such, so without the automatic special handling of missing and invalid data, the language would have been seriously crippled.

Even with if statements, this feature made programming much easier.

Michael Vanier - Re: Java and Pointers  blueArrow
1/15/2003; 5:28:49 PM (reads: 979, responses: 1)
Gee, I'd much rather that 3 + invalid raised an exception than yielded invalid. That's why I hate NaN in floating-point arithmetic. When an NaN happens, I want to know about it! I've seen numerical simulations where an NaN happens early on and you never find out about it until the end of the simulation, when you realize that half of your results are NaNs.

Ehud, what's the Haskell paper on exceptions?

Ehud Lamm - Re: Java and Pointers  blueArrow
1/16/2003; 12:24:11 AM (reads: 1003, responses: 0)
Well, it all depends on your needs, doesn't it? That's why I emphasized that the language was a query DSL. It was used for generating reports etc.

In that context you don't need (nor does the language support) exceptions. Let me give an example. Suppose the age of some of the twon residents in your database is unknown (it doesn't matter why this is the situation. Assume this is out of your hands). You want a report listing all residents that will turn 18 this year.

All you need is that language, while doing calculations with birth dates etc. will propagate the fact that the information is missing.

The reason you can dispense with exceptions is that the handling of missing and invalid data is uniform, and embodied in the behaviour of the various operators.

Naturally, a general purpose language cannot choose this approach.

Haskell Exceptions.