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