Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #4009

Re: Java puzzler

From Joshua Cranmer <Pidgeot18@verizon.invalid>
Newsgroups comp.lang.java.programmer
Subject Re: Java puzzler
Date 2011-05-12 10:14 -0400
Organization A noiseless patient Spider
Message-ID <iqgpvs$3bv$1@dont-email.me> (permalink)
References <871987d9-1034-441d-9d33-b2dd6b4de234@glegroupsg2000goo.googlegroups.com> <jhnks6dpk9bjoh7q2gougt0m6ove9etbuq@4ax.com> <iqe1m8$g5e$1@news.albasani.net> <iqe8sr$5p1$1@dont-email.me> <bnpms6lg49p24m2l8taeo51o2pq408uprj@4ax.com>

Show all headers | View raw


On 05/12/2011 01:02 AM, Roedy Green wrote:
> When I read the JLS, it always seems to me extremely ambiguous.  I
> would never trust my interpretation.  Others seem to understand its
> language patterns more deeply and with confidence divine what it
> means.  It may be that they have done more experiments and have at a
> gut level learned the sort of language Mr. Gosling uses.

The JLS is quite rigidly specified, at least in comparison to other 
specifications I have read (e.g., CSS). It is also well-organized 
compared to, say, C++, where I have to spend a lot of time trying to 
figure out which clause covers the question I have (I want to know about 
something involving default initialization of templatized POD-classes... 
only could be in about 5 sections).

> Interpreting the JLS is a special skill quite different from
> programming.

Much of the programming I have done has required me to read, write, 
comprehend, synthesize, and implement specifications, be it as long and 
dense as that for a programming language, as underspecified as an old 
RFC that predates most concerns for i18n, as formal as the formal 
project specification, or as informal as the API documentation. 
Specifications like the JLS are merely API documentation at another 
level: every token is an input to the function "Compile and run me!" 
provided by javac and java, with the JLS merely being a thorough 
exposition on the wonderous ways that tokens interact with each other.

In that vein, every programmer should have the skills to read, 
comprehend, and interpret the JLS, since they should have the same 
skills to read, comprehend, and interpret API documentation.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Java puzzler Gábor Bakos <aborgabor@gmail.com> - 2011-05-10 16:36 -0700
  Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-10 20:16 -0400
  Re: Java puzzler Roedy Green <see_website@mindprod.com.invalid> - 2011-05-11 03:03 -0700
    Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-11 09:07 -0400
      Re: Java puzzler markspace <-@.> - 2011-05-11 08:10 -0700
        Re: Java puzzler Roedy Green <see_website@mindprod.com.invalid> - 2011-05-11 22:02 -0700
          Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-12 08:35 -0400
            Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 08:13 -0700
              Re: Java puzzler Lew <noone@lewscanon.com> - 2011-05-12 12:11 -0400
                Re: Java puzzler Patricia Shanahan <pats@acm.org> - 2011-05-12 18:28 -0700
          Re: Java puzzler Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-12 10:14 -0400
      Re: Java puzzler Roedy Green <see_website@mindprod.com.invalid> - 2011-05-11 21:49 -0700

csiph-web