Benefits of compiler errors

T

Tony Morris

The claim that Java is statically-typed is incorrect. One need only look at
the notion of 'null' to disprove this claim.
Perhaps "Java attempts to be statically-typed, but falls short in a few
areas" is a little more precise.
The document then goes on to talk about definite assignment semantics,
however, it ignores, or simplifies, the advantages of all of these concepts.
The proponents of dynamically-typed languages would eat the given reasoning
up in a second - I say this as a firm believer in the notion of
"compiler-aided programming" (I don't like that terminology, but I'll use it
anyway).

That a statically-typed (or failed attempt, such as Java) does not exist
whereby it permits a valid and concise alignment with a formal requirement
specification is one of the reasons that we are observing a trend toward
dynamically-typed languages. Given this reasoning, it can be extrapolated
that a statically-typed language that does indeed permit an alignment with a
requirement specification may be superior to all existing dynamically-typed
languages (and certainly more superior to our existing type-safe languages).
This is all a different story though.
 
D

Dave Glasser

The claim that Java is statically-typed is incorrect. One need only look at
the notion of 'null' to disprove this claim.

How does Java's notion of "null" disprove that claim? I'm not
disagreeing with you, I'm just asking.


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net
 
T

Tony Morris

Dave Glasser said:
How does Java's notion of "null" disprove that claim? I'm not
disagreeing with you, I'm just asking.


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net

There are other, more convoluted (to the intuition) reasons why Java is not
statically-typed, but the existence of null is the easiest one to pick one.
null has no type - it exists for this very reason. For example, many parts
of the API specification will provide a method that is specified similar to:
"This method returns an instance of some type T, however, if such an
instance cannot be returned, and since I don't want the call stack to unwind
by throwing an exception, this method will return 'null' and you will be
permitted to assign it to your type T, since null is dynamically-typed - you
can assign it to any reference type".

This is simple enough, but sometimes it is not yet obvious, until one
digresses into the reasons why the very existence of null (regardless of
typing) and that the implementation of exceptions (mildly related) in Java
is in many ways, defective. I hope to avoid that situation, merely for
brevity, especially on internet forums. I hope you understand.
 
S

Stefan Ram

Tony Morris said:
There are other, more convoluted (to the intuition) reasons why
Java is not statically-typed, but the existence of null is the
easiest one to pick one. null has no type - it exists for this
very reason.

The Java programming language is a strongly typed
language, which means that every variable and every
expression has a type that is known at compile time. There
is also a special null type, the type of the expression
null. A null literal is always of the null type.
The null reference can always be cast to any reference
type. (JLS3)

The null literal has a type, while the null reference is
typeless as is any other reference in Java. Only variables and
expressions have types, and objects have classes (as run-time
types). References themselves are typeless.

Your criticism agains methods returning "null" to signal a
special condition does not seem to be related to the type of
null. -- It also would apply if it would return a specially
typed null reference or null object of the declared return
type of the method.
 
T

Tony Morris

Stefan Ram said:
The Java programming language is a strongly typed
language, which means that every variable and every
expression has a type that is known at compile time. There
is also a special null type, the type of the expression
null. A null literal is always of the null type.
The null reference can always be cast to any reference
type. (JLS3)

The null literal has a type, while the null reference is
typeless as is any other reference in Java. Only variables and
expressions have types, and objects have classes (as run-time
types). References themselves are typeless.

Your criticism agains methods returning "null" to signal a
special condition does not seem to be related to the type of
null. -- It also would apply if it would return a specially
typed null reference or null object of the declared return
type of the method.

Your quoting of the JLS was indeed expected, but you must understand that I
do not accept it as an authoritative source. In fact, many of my colleagues,
who work alongside with me implementing this specification, do not
acknowledge it as an authority. This is the fundamental reason why you may
not see why a "method that returns null" is not related to the defective
existence of null itself. That few people are able to consider an
alternative, and perhaps less contrived solution (an exception is not it,
because they are defective too as the never-ending exception debate clearly
indicates), is the result of the subscription to the authority of the JLS.
One must also acknowledge the nature of specifications written using English
and the potential and intrinsic ambiguity as a result. If the JLS said that
'null is a language defect, and we wish we didn't introduce it, however, our
most prominent language experts are unable to determine a suitable solution,
so we simply concede to the point and introduce it as a dynamic type, while
providing the illusion that it is not through the JLS', is this correct as
an authority? I certainly think it is a more plausible description of
reality, and many agree, but are unable to disclose evidence due to the
filth within which they work and therefore, depend on to survive.

Ignoring the JLS, marketing material, etc. and working purely with
programming languages, I define that null is dynamically-typed according to
my, and the generally accepted, definition in language research. Sure, we
can redefine our axiom as the JLS and discuss within that frame of
reference, in which case, I concede entirely, but my initial assumption was
not that due to the aforemention failure to acknowledge the illusion of a
proclaimed authority as being real.
 
D

Dave Glasser

There are other, more convoluted (to the intuition) reasons why Java is not
statically-typed, but the existence of null is the easiest one to pick one.
null has no type - it exists for this very reason. For example, many parts
of the API specification will provide a method that is specified similar to:
"This method returns an instance of some type T, however, if such an
instance cannot be returned, and since I don't want the call stack to unwind
by throwing an exception, this method will return 'null' and you will be
permitted to assign it to your type T, since null is dynamically-typed - you
can assign it to any reference type".

This is simple enough, but sometimes it is not yet obvious, until one
digresses into the reasons why the very existence of null (regardless of
typing) and that the implementation of exceptions (mildly related) in Java
is in many ways, defective. I hope to avoid that situation, merely for
brevity, especially on internet forums. I hope you understand.

I understand, but I'm not buying it. Null itself is not data; it's not
an object, it's more of a "state" that a reference can be in. That's
why it has no type. It means that a reference is currently *not*
referring to any object in memory.

And methods don't really return *objects*, but rather references to
objects. A subtle distinction, to be sure, and not one I'd normally
bring up, but I think it's an important one here.

When you have code like this:

String s = null;

You're effectively assigning a null reference to the variable s. Or,
if you prefer to think of s itself as the reference, you can say
you're putting the reference s into a state where it refers to
nothing. Either way, since the reference refers to nothing, the
operation will always be typesafe, and this is known at compile time.
That's the bottom line, all of the JLS arcana and semantic
hairsplitting notwithstanding.

BTW, I don't expect you to buy my argument either, but this is the
sort of thing that can be argued ad nauseum, and I don't plan on
spending any more time on it. So the last word is yours, if you want
it.

--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net
 
J

John C. Bollinger

Your quoting of the JLS was indeed expected, but you must understand that I
do not accept it as an authoritative source. In fact, many of my colleagues,
who work alongside with me implementing this specification, do not
acknowledge it as an authority.

An authority on what? Surely the JLS is the *definitive* authority on
the Java language. I guess you must mean that you don't accept the JLS
as an authority on type theory, or something along those lines. That's
reasonable, but begging your pardon, I don't know enough about you to
accept /you/ as an authority on the topic, either. I have only your own
assertion of authority. I do stipulate, however, that *I* am *not* an
authority on such matters.

[...]
Ignoring the JLS, marketing material, etc. and working purely with
programming languages, I define that null is dynamically-typed according to
my, and the generally accepted, definition in language research.

Well do you care to share that definition with those of us who have yet
to be initiated into the 33rd degree?

Any way around, even if there are holes in Java's static type system (a
point which I do not yet concede), I think it would be much more
appropriate to say that its static typing is imperfect or incomplete
than to flatly deny that the language is statically typed at all. In my
own imprecise understanding of the term, Java certainly *is* statically
typed, and I daresay that most other regulars here would say the same.
Where is the distinction that I, as a programmer, would actually care about?
 
J

John C. Bollinger

Chris said:
I'm having some trouble brainstorming here. I know there's more to this
topic than I'm thinking of right now. So please, if you have a second
and more insight than me, expand on this JINX page:

http://riters.com/JINX/index.cgi/Compiler_20Aided_20Programming

I added a little bit. I think there is room to say something about
annotations there, but I haven't used them enough to know just what
ought to be said. Perhaps there's also room for some comments about
typesafe enums, though I haven't quite formulated them.
 
M

megagurka

Tony said:
The claim that Java is statically-typed is incorrect.

I would say that it's mostly statically typed. In fact for most
programs 99% of the code is statically type checked by the compiler.
That a statically-typed (or failed attempt, such as Java) does not exist
whereby it permits a valid and concise alignment with a formal requirement
specification is one of the reasons that we are observing a trend toward
dynamically-typed languages.

What are you saying here? That no statically typed programming
languages exist? If so, it would be interesting to hear your argument
why you think languages like ML and Haskell are not statically typed.

Your argument regarding null values has some merit, but there are
solutions for this. For example, Nice introduces the concept of
"nullable" types which means that possible null values can only be
assigned to "value slots" of a nullable types, otherwise the compiler
gives an error.

/Jesper Nordenberg
 
C

Chris Smith

John C. Bollinger said:
I added a little bit. I think there is room to say something about
annotations there, but I haven't used them enough to know just what
ought to be said. Perhaps there's also room for some comments about
typesafe enums, though I haven't quite formulated them.

Thanks. I will definitely add some stuff about the basic annotations
implemented by javac, and the possibility of adding simple stuff with
the apt tool.

As for enums, that brings up an interesting distinction. Since the name
"compiler aided programming" isn't in common use anywhere that I know of
(I made it up, and I've used it in a few newsgroup posts), it ends up
meaning whatever that page says it does. It seems to me that stuff like
initialization checking is more in line with what I was thinking of when
I created the page than enums (or access specifiers, for that matter)...
but I'm trying to put my finger on the difference. They DO both fit,
but there's a difference hanging in the back of my mind.

Anyway, add whatever you will, of course. That's what wikis are for.
If you want to add even more stuff, see

http://riters.com/JINX/index.cgi/MissingPages

which I just added this evening.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
J

John C. Bollinger

Chris said:
As for enums, that brings up an interesting distinction. Since the name
"compiler aided programming" isn't in common use anywhere that I know of
(I made it up, and I've used it in a few newsgroup posts), it ends up
meaning whatever that page says it does. It seems to me that stuff like
initialization checking is more in line with what I was thinking of when
I created the page than enums (or access specifiers, for that matter)...
but I'm trying to put my finger on the difference. They DO both fit,
but there's a difference hanging in the back of my mind.

The enum-related bits I was thinking of were things such as the compiler
issuing a diagnostic when it determines that the cases of a switch
statement don't cover all the possible values of the enum type of the
switch expression. (Eclipse's compiler can do this, for instance.)
Nevertheless, I'm not entirely sure whether that particular page is the
right place to cover it.

My take on "compiler-aided programming" is that the more fully you
describe the intended structure and behavior of the program to the
compiler, the better able it is to detect violations. That seems pretty
much in line with your initial text, and it's certainly the slant I was
going for with my additions.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top