Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Benefits of compiler errors

Reply
Thread Tools

Benefits of compiler errors

 
 
Chris Smith
Guest
Posts: n/a
 
      01-04-2006
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/Com..._20Programming

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
 
 
 
VisionSet
Guest
Posts: n/a
 
      01-04-2006

"Chris Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed).. .
> 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/Com..._20Programming


Ad Hoc:
As a memory prompt,
the change your making ripples front to back,
the compiler reminds you of all the locations that need attention.

--
Mike W


 
Reply With Quote
 
 
 
 
Tony Morris
Guest
Posts: n/a
 
      01-04-2006
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.

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

"Chris Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed).. .
> 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/Com..._20Programming
>
> --
> www.designacourse.com
> The Easiest Way To Train Anyone... Anywhere.
>
> Chris Smith - Lead Software Developer/Technical Trainer
> MindIQ Corporation



 
Reply With Quote
 
Dave Glasser
Guest
Posts: n/a
 
      01-05-2006
"Tony Morris" <(E-Mail Removed)> wrote on Thu, 5 Jan 2006 09:15:25
+1000 in comp.lang.java.programmer:

>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
 
Reply With Quote
 
Tony Morris
Guest
Posts: n/a
 
      01-05-2006
"Dave Glasser" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Tony Morris" <(E-Mail Removed)> wrote on Thu, 5 Jan 2006 09:15:25
> +1000 in comp.lang.java.programmer:
>
> >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


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.

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



 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      01-05-2006
"Tony Morris" <(E-Mail Removed)> writes:
>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.


 
Reply With Quote
 
Tony Morris
Guest
Posts: n/a
 
      01-05-2006

"Stefan Ram" <(E-Mail Removed)-berlin.de> wrote in message
news:(E-Mail Removed)-berlin.de...
> "Tony Morris" <(E-Mail Removed)> writes:
> >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.
>
>


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.

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



 
Reply With Quote
 
Dave Glasser
Guest
Posts: n/a
 
      01-05-2006
"Tony Morris" <(E-Mail Removed)> wrote on Thu, 5 Jan 2006 10:47:28
+1000 in comp.lang.java.programmer:

>"Dave Glasser" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>> "Tony Morris" <(E-Mail Removed)> wrote on Thu, 5 Jan 2006 09:15:25
>> +1000 in comp.lang.java.programmer:
>>
>> >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.
>>


>
>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
 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      01-05-2006
Tony Morris wrote:
> "Stefan Ram" <(E-Mail Removed)-berlin.de> wrote in message
> news:(E-Mail Removed)-berlin.de...
>
>>"Tony Morris" <(E-Mail Removed)> writes:
>>
>>>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 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?

--
John Bollinger
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      01-05-2006
Chris Smith wrote:
> 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/Com..._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.

--
John Bollinger
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[O.T] SystemC benefits? Jezwold VHDL 2 02-08-2005 02:51 PM
MCSE Benefits... what benefits. Johnny Yi MCSE 51 01-24-2005 02:05 PM
DBA Certification Benefits?...And Advice Ryan Gagliano Microsoft Certification 2 01-15-2005 07:00 AM
Errors, errors, errors Mark Goldin ASP .Net 2 01-17-2004 08:05 PM



Advertisments