[JSR308] Can we agree on our goals?

Gary T. Leavens leavens at cs.iastate.edu
Fri Feb 2 18:39:18 EST 2007


Hi Ted,

Well, I completely disagree with your position then.  Sorry about
that.  My understanding of how Flon's axiom applies to our
discusssions is:

   - No matter what we do, we won't be able to stop people from writing
     unreadable code, even if we don't add anything to Java (a position
     you seem to agree with),

   - No matter what we do, we won't be able to stop X percent of people
     from writing unreadable code (since setting X to 100% reduces
     us to the first case).

My experience in language design efforts says that there is a very
good reason for dismissing such arguments: it's simply not a
productive use of time.

So I don't think your question: "will the code that 80% of the
programmers write look unreadable?" is a fair one to hold a standard
to.  Sorry about that.

I would guess that 80% of the programmers will not produce unreadable
code with any language we give them, because they are responsible
enough to write readable code.  I am skeptical they would be able to
keep their jobs if they write unreadable code.

Of course programmers might choose to write in some other language
that more directly supports their needs, if we make it difficult for
them to write good Java programs.  So I would still like to keep us
focused on whether we can support the use cases we want to support.

That all said, I agree we should try to make the language as clean,
elegant, and simple as possible, while supporting the use cases we
believe are important.  I support your basic instincts to keeping
things simple, clean, and elegant.  That's great.

However, I just don't think it's helpful to worry about horribly
complex code.  Here's another way to understand what I'm saying.  If
you can argue convincingly that the simplest cases are hard to
understand and follow, then I would be persuaded to leave out the
relevant language features, but getting upset over unrealistically
complicated code is not useful.  For example: if the simplest uses of
try-finally blocks and throws blocks were to be hard to follow and
understand, then I would agree to dropping them from the language; but
a very complex example with 20 such blocks being hard to understand
isn't persuasive.

So, carrying this back to JSR 308, if you think that we shouldn't have
even the simplest statement annotations, for example, show me such a
very simple example, and explain why it's not understandable or
readable or how it's very bad for some accepted measure of "goodness"
(like that it destroys information hiding).  That would be persuasive.
Showing me a complex example with 20 different kinds of annotations
isn't persuasive.

I hope that helps explain my position, let me know if it's not clear.
(BTW, I may not be able to respond to emails until Monday.)

On Fri, 2 Feb 2007, Ted Neward wrote:

> Gary, with all due respect, I completely disagree with this position. Not
> worrying about producing readable code strikes me as a position that is
> simply untenable and irresponsible to the legions of programmers out there
> who will have to use what we create here.
>
> Simply citing Flon's axiom and saying, "Programmers will always be able to
> write bad code" is a logical fallacy. The goal of my concern is not whether
> programmers *can* write bad code--I accept Flon's axiom. The question I ask
> is, will the code that 80% of the programmers write look unreadable? That, I
> believe, is always a fair question to ask and a standard to be held to.
>
> I'm also skeptical that we can rely on tools to solve the problem of
> legibility in some vague way--that calls to mind an image of the carpenter
> who chucks his unwanted wood pieces out the window when finished, and when
> criticized for doing so, suggests that since the gardener is responsible for
> picking up the yard anyway, it's the gardener's problem now.
>
> And yes, in current Java, legibility currently *is* a problem, one that's
> been cited in several discussions (witness Eckel's most recent weblog), and
> thus I think makes it *more* of a concern, not less. Many public figures are
> already making it clear that they believe Java has "jumped the shark" and
> become an overly complicated and unusable beast, and I would think us
> irresponsible if we don't take that into account during our discussions.
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
>
>> -----Original Message-----
>> From: Gary T. Leavens [mailto:leavens at cs.iastate.edu]
>> Sent: Friday, February 02, 2007 7:34 AM
>> To: Ted Neward
>> Cc: jsr308 at lists.csail.mit.edu
>> Subject: RE: [JSR308] Can we agree on our goals?
>>
>> Hi Ted and all,
>>
>> About your note below, I feel comprelled to repeat my remarks about
>> Flon's axiom.  Of course you can write unreadable programs with our
>> annotation proposal.  You can write unreadable programs in Java
>> already and sure, we'll provide new ways to do that.  But that's not
>> the point.  The point is whether we'll help programmers use
>> annotations intelligently to accomplish what they want to do.  Most of
>> those good uses of annotations will be fairly spare.
>>
>> The valid concern in your remarks is what happens when there are two
>> or more sets of annotations in use in one program: can programmers
>> produce something that is sensible?  I agree that using two or more
>> sets of annotations might make it difficult for programmers to write
>> code that is easy to read, but presumably tools like Eclipse could be
>> used to suppress one or more sets of annotations.  And note that this
>> concern is independent of where programmers can write annotations,
>> even in current Java this could already be a problem.  So I don't
>> think this is an argument we should worry about for JSR 308, even if
>> it's a more valid concern.
>>
>> On Thu, 1 Feb 2007, Ted Neward wrote:
>>
>>> There's also clearly a readability issue here. Annotations everywhere
>>> means... annotations everywhere. Using two or three different sets of
>>> annotations together in a single program could really quickly make
>>> "annotation hell". We're assuming throughout this discussion in our
>> examples
>>> that only one set of annotations will be in play, but it doesn't take a
>> lot
>>> of imagination to come up with a couple of sets that could easily be
>> used
>>> simultaneously. Reducing the number of places an annotation can be
>> applied
>>> will (I hope) reduce the potential for unreadable code.
>>>
>>> As an exercise, during the JSR 175 discussions I took a moment and wrote
>> up
>>> a class that put an annotation in every possible place an annotation
>> could
>>> go, and judged how it all looked when done. It was a bit cluttered, but
>>> since annotations neatly fit into every place a modifier sat, it sort of
>>> made sense and still seemed readable. I'd strongly suggest we do
>> something
>>> similar (formally or informally), just to make sure we get a clear view
>> of
>>> what we're creating.
>>>
>>> Ted Neward
>>> Java, .NET, XML Services
>>> Consulting, Teaching, Speaking, Writing
>>> http://www.tedneward.com
>>>
>>>
>>>> -----Original Message-----
>>>> From: jsr308-bounces at lists.csail.mit.edu [mailto:jsr308-
>>>> bounces at lists.csail.mit.edu] On Behalf Of Tom Ball
>>>> Sent: Thursday, February 01, 2007 12:26 PM
>>>> To: Eugene Kuleshov
>>>> Cc: jsr308 at lists.csail.mit.edu
>>>> Subject: Re: [JSR308] Can we agree on our goals?
>>>>
>>>> Eugene Kuleshov wrote:
>>>>> Gary T. Leavens wrote:
>>>>>> For my part, I would be very happy with adding the ability to have
>>>>>> annotations on types and statements (or even just loop statements).
>>>>>> I'm not personally trying to use any kind of strategy to lead us down
>>>>>> a slippery slope towards annotations on all possible syntactic
>>>>>> categories.  I think if Java programmers can annotate declarations,
>>>>>> types, and (loop) statements, that will be plenty.
>>>>>  Gary, why limit it on loops and not all { } blocks?
>>>>
>>>> At the risk of polluting this discussion with implementation details,
>>>> javac block nodes have an internal modifiers field, and modifiers hold
>>>> annotations.  The Compiler API only allows access to the static flag in
>>>> those modifiers (BlockTree.isStatic()), but that interface can be
>>>> extended in a backwards-compatible way to provide access to the
>>>> annotations.
>>>>
>>>> The advantage of allowing annotations on blocks rather than on
>>>> statements is that developers can surround any statement with a block
>> if
>>>> they want to annotate it, without  having to make radical modifications
>>>> to the compiler.  It should also make scoping issues simpler, too.  I
>>>> haven't thought out what the impact of having block annotations will be
>>>> on JVM classfiles, but suspect that the current proposed attribute will
>>>> work.
>>>>
>>>> Tom
>>>>
>>>> _______________________________________________
>>>> JSR308 mailing list
>>>> JSR308 at lists.csail.mit.edu
>>>> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date:
>> 2/1/2007
>>>> 2:28 PM
>>>>
>>>
>>> --
>>> No virus found in this outgoing message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date:
>> 2/1/2007
>>> 2:28 PM
>>>
>>>
>>>
>>> _______________________________________________
>>> JSR308 mailing list
>>> JSR308 at lists.csail.mit.edu
>>> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>>>
>>
>>
>>          Gary T. Leavens
>>          Department of Computer Science, Iowa State University
>>          229 Atanasoff Hall, Ames, Iowa 50011-1041 USA
>>          http://www.cs.iastate.edu/~leavens  phone: +1-515-294-1580
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
>> 2:28 PM
>>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
> 2:28 PM
>
>


         Gary T. Leavens
         Department of Computer Science, Iowa State University
         229 Atanasoff Hall, Ames, Iowa 50011-1041 USA
         http://www.cs.iastate.edu/~leavens  phone: +1-515-294-1580




More information about the JSR308 mailing list