Benefits of compiler errors

Discussion in 'Java' started by Chris Smith, Jan 4, 2006.

  1. Chris Smith

    Chris Smith Guest

    Chris Smith, Jan 4, 2006
    #1
    1. Advertising

  2. Chris Smith

    VisionSet Guest

    "Chris Smith" <> wrote in message
    news:...
    > 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


    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
     
    VisionSet, Jan 4, 2006
    #2
    1. Advertising

  3. Chris Smith

    Tony Morris Guest

    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" <> wrote in message
    news:...
    > 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
    >
    > --
    > www.designacourse.com
    > The Easiest Way To Train Anyone... Anywhere.
    >
    > Chris Smith - Lead Software Developer/Technical Trainer
    > MindIQ Corporation
     
    Tony Morris, Jan 4, 2006
    #3
  4. Chris Smith

    Dave Glasser Guest

    "Tony Morris" <> 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
     
    Dave Glasser, Jan 5, 2006
    #4
  5. Chris Smith

    Tony Morris Guest

    "Dave Glasser" <> wrote in message
    news:...
    > "Tony Morris" <> 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/
     
    Tony Morris, Jan 5, 2006
    #5
  6. Chris Smith

    Stefan Ram Guest

    "Tony Morris" <> 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.
     
    Stefan Ram, Jan 5, 2006
    #6
  7. Chris Smith

    Tony Morris Guest

    "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > "Tony Morris" <> 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/
     
    Tony Morris, Jan 5, 2006
    #7
  8. Chris Smith

    Dave Glasser Guest

    "Tony Morris" <> wrote on Thu, 5 Jan 2006 10:47:28
    +1000 in comp.lang.java.programmer:

    >"Dave Glasser" <> wrote in message
    >news:...
    >> "Tony Morris" <> 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
     
    Dave Glasser, Jan 5, 2006
    #8
  9. Static typing [was: Benefits of compiler errors]

    Tony Morris wrote:
    > "Stefan Ram" <-berlin.de> wrote in message
    > news:-berlin.de...
    >
    >>"Tony Morris" <> 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
     
    John C. Bollinger, Jan 5, 2006
    #9
  10. 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/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.

    --
    John Bollinger
     
    John C. Bollinger, Jan 5, 2006
    #10
  11. Chris Smith

    megagurka Guest

    Tony Morris wrote:
    > 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
     
    megagurka, Jan 5, 2006
    #11
  12. Chris Smith

    Chris Smith Guest

    John C. Bollinger <> wrote:
    > > 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.


    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
     
    Chris Smith, Jan 6, 2006
    #12
  13. Chris Smith wrote:

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

    --
    John Bollinger
     
    John C. Bollinger, Jan 7, 2006
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jezwold

    [O.T] SystemC benefits?

    Jezwold, Feb 7, 2005, in forum: VHDL
    Replies:
    2
    Views:
    639
    Jezwold
    Feb 8, 2005
  2. Chak

    .NET 2.0 benefits

    Chak, Feb 23, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    1,942
    Matt Adamson
    Apr 20, 2006
  3. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,033
    Mark Goldin
    Jan 17, 2004
  4. Stijn Verrept

    Benefits ASP.NET over CGI

    Stijn Verrept, Jan 19, 2004, in forum: ASP .Net
    Replies:
    12
    Views:
    6,893
  5. Aaron

    ASP.NET benefits for ASP

    Aaron, Jan 24, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    384
    Hermit Dave
    Jan 24, 2004
Loading...

Share This Page