My new toy

[Arved Sandstrom]

And they should leave. They do actual harm with their code.


Oh, boo-hoo-hoo. Poow widdo cwybabies are boowud wif deir poow, poow
lives making better than average salaries for indoor work and all they
have to do is write code. I cannot begin to tell you how sorry I am
that they're all disillusioned and have given up after "some" years.

Actually, Lew, the process I am describing here results in just what you
said: "all they have to do is write code". That's exactly what happens.
9-5, M-F, mediocre code. No employer or professional recognition or
incentive for doing anything better.

I've been programming professionally for over thirty years, and some of
my mentors in the profession have been in their eighties. There's no
reason to give up the pursuit of excellence and most definitely no
reason to excuse giving it up.

[ SNIP ]

I think you realize that I personally like programming. I work for a
small consulting company, and all of my colleagues enjoy it as well.
However, when we work at client sites and interact with organic IT then
the story can be very different. The keen programmers come and go
quickly - there's a high rate of churn (it's not rare to see the really
promising programmers not even last out their probationary periods). The
ones that stick it out either never were keen or they only stayed that
way for a year or two - then reality intruded.

I've been pretty lucky in the kind of programming work I've done, but
there've been a few stints where I didn't much want to go to work
either. You're way down the food chain so nobody listens to your ideas
about improving code, process, or anything else. The projects are death
spirals. There's no testing. Your coding colleagues (for various
reasons) display little interest in what they do. Some of them are flat
out incompetent...they could never be good programmers even if they
wanted to be. The projects themselves are completely uninteresting (so
it's usually a good thing that they are destined for an early death).

I'll tell you what happens in situations like that. A majority of
programmers probably would like to enjoy their work, but if that's not
going to happen many just punch the clock, go home, and don't think
about it again until the next morning. They resign themselves. Others go
home and work on their own projects and check the job listings...if
you're in this latter group eventually you may find a pretty decent job
and belong to that minority of programmers who show enthusiasm for what
they do.

This discussion is not about utopia. It's about what the coding industry
currently is.

AHS

 

[Roedy Green]

I'd love it if we had a Java Language Hyperspec.

I am always invented work for others and myself far faster than anyone
could finish it. But it would be interesting to take a one of the
more intimidating bits of the spec, then have someone brave take a
stab and deciphering what it means and putting it is slightly more
comprehensible form. The others could read that tool to bootstrap an
even more accessible translation.

Then perhaps it would be possible to publish an ANNOTATED JLS, which
merges text from the JLS with explanatory text. However most of the
JLS text would live in little iframe windows -- only referenced by the
dedicated language lawyers.

It would say that the JLS text is definitive and ask for reports of
any discrepancies or omissions.

Text is tagged with level of obviousness and importance, so that
people can more easily ignore stuff they already likely know or stuff
that is too picayune for the current purpose. (dynamic filtering in
the server or client Applet)

The ideal tool for doing this I don't think yet exists, except in my
imagination. I described it many years ago at
http://mindprod.com/jgloss/author.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Martin Gregorie]

that's odd. It is not working for me. I am using Windows version. What
about you?

Linux version, the Fedora 10 spin, but I stand corrected: it doesn't
work.

I made the mistake of not looking at it in Firefox first to see what it
'should' look like.

 

[Joshua Cranmer]

1. I contend it was DELIBERATELY written to be obscure and
inaccessible to average programmers. Spec writing is an academic
one-upmanship game, much like lawyerly contract writing. It is not
just the JLS. Nearly every spec is written this way.

Having had to implement specifications before, I can tell you that
excessive precision is infinitely preferable to readable vagueness. For
example, compare the current definition of display: run-in under CSS 2.1:

A run-in box behaves as follows:

1. If the run-in box contains a block box, the run-in box becomes a
block box.
2. If a sibling block box (that does not float and is not absolutely
positioned) follows the run-in box, the run-in box becomes the first
inline box of the block box. A run-in cannot run in to a block that
already starts with a run-in or that itself is a run-in.
3. Otherwise, the run-in box becomes a block box.

That seems easy to implement, right? Boris Zbarsky, in preparing to
implement, identified over a dozen issues that the easy-to-read text
misses, including interactions with tables, non-folded whitespace,
multiple run-ins, ::first-letter and ::first-line, etc. The thread in
the W3C mailing list group has reached over 49 messages and is still in
progress, all because of under-precision. As a result, the three major
implementations of it all differ in how they handle these not-so-edgey
cases.

It is a lot easier to come by edge cases in programming languages than
it is in stuff like CSS or HTML, as typos easily cause lookup in edge
cases. If I have:

class a {
public a a() { return null; }
public int a;
public void b() {
a a = a();
a.a();
}
}

is this legal? If not, where is the error? Can you find the answer using
only the JLS?

Compiler writers are absolutely dependent on being able to do that: they
need precise definition of identifier lookup, they need precision in the
workings of the type system. Specifications are not designed for the end
user, who cares mostly about the common cases; they are designed for the
implementors, who needs to know about the fiddly little twists and turns
that can happen in the most unrealistic programs. After all, the essence
of the compiler is that it rejects or accepts a given string of text, so
it must be sufficiently specified to the point that anyone can do it for
any string passed in as input. If the specification fails to do that, it
is a failure as a specification.

I doubt it's out of a need for grandiosity, but more a practical desire
to avoid having two incompatible implementations that both follow the
specification, the fate of such specifications as HTML or CSS.

 

[Roedy Green]

Then perhaps it would be possible to publish an ANNOTATED JLS, which
merges text from the JLS with explanatory text. However most of the
JLS text would live in little iframe windows -- only referenced by the
dedicated language lawyers.

I would like to see a BNF-like description of Java but using colour to
make it very clear the difference between terminals, non-terminals and
meta-operators.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Roedy Green]

easy-to-read text

Easy to read is not the problem. It is incompleteness. Nothing
clarifies even the most opaque text like an example. However, spec
writers seem to think that using examples is baby talk.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Arved Sandstrom]

Having had to implement specifications before, I can tell you that
excessive precision is infinitely preferable to readable vagueness. For
example, compare the current definition of display: run-in under CSS 2.1:

A run-in box behaves as follows:

1. If the run-in box contains a block box, the run-in box becomes a
block box.
2. If a sibling block box (that does not float and is not absolutely
positioned) follows the run-in box, the run-in box becomes the first
inline box of the block box. A run-in cannot run in to a block that
already starts with a run-in or that itself is a run-in.
3. Otherwise, the run-in box becomes a block box.

That seems easy to implement, right? Boris Zbarsky, in preparing to
implement, identified over a dozen issues that the easy-to-read text
misses, including interactions with tables, non-folded whitespace,
multiple run-ins, ::first-letter and ::first-line, etc. The thread in
the W3C mailing list group has reached over 49 messages and is still in
progress, all because of under-precision. As a result, the three major
implementations of it all differ in how they handle these not-so-edgey
cases.

[ SNIP ]

I ran into exactly the same problems when working on Apache FOP many
years ago. We had to interpret the XSL-FO specification as it was back
then, and there were also many vague spots, missing spots, and flat-out
contradictions. I'm not busting on the spec writers per se - creating a
specification for layout markup/languages is among the more complicated
things to do.

What frequently happens is that implementors are not involved in writing
specifications. This, IMO, is a mistake.

AHS

 

[Joshua Cranmer]

Easy to read is not the problem. It is incompleteness. Nothing
clarifies even the most opaque text like an example. However, spec
writers seem to think that using examples is baby talk.

To the contrary, most specifications that I have read (excluding,
interestingly enough, RFCs), are full of examples. In terms of the JLS,
there's only one or two places where I think an example would be
extremely useful in terms of understanding. Many of the other
example-less places are actually surprisingly simple if you sit down and
play with them.

 

[Lew]

We have beginner books that do Hello World to death, and we have the
JLS, but we don't have anything in between, a sort of JLS for dummies
that gives the practical information from the JLS that programmers
need in a clear declarative style primarily using examples to explain
fine distinctions. Consider for example enums. Most books just touch
on them. The JSL overwhelms with abstract descriptions. Surely there
is a way to give the necessary information in a more palatable way.

Actually there are quite a number of intermediate sources between those
extremes. The articles at
<http://www.ibm.com/developerworks/java>
books such as /Effective Java/ (2nd ed.) by Bloch, /Java Concurrency in
Practice/ by Goetz, et. al, and training at places like javapassion.com are
all between the extremes you describe.

Enums, for example, are very well covered in /Effective Java/. Generics, one
of the trickier concepts in Java, are also very well covered in that book, and
in white papers available at java.sun.com.

Programming is not a profession for stupid people.

 

[Lew]

Agreed. I would give it a B in comparison with other specs.

This whole business about saying Java programmers shouldn't have to be able to
read the Java Language Specification is like saying that lawyers shouldn't
have to be able to read a contract. It's our profession to be able to do
that. Accountants have to understand double-entry bookkeeping. Lawyers have
to understand contracts. Java programmers have to understand the JLS. Anyone
who can't deal with the JLS should leave the profession. It's our job to be
smart, and if you aren't smart, get the heck out.

Buh-bye. See ya, wouldn't wanna be ya.

 

[Dave Searles]

And you think that's acceptable?

Well, if it isn't, then you're saying that "extra effort and polish"
above and beyond the stated requirements is *mandatory*.

Making unwritten extras mandatory is a great way to turn bright-line
rules and boundaries into a murky minefield where a person can be
sanctioned despite innocence, good faith, and having toed all of the
official, visible-to-them lines.

"You're fired!"
"What for?"
"Not crossing your u's."
"Waitaminnut, the rules say i's and j's must be dotted and t's crossed.
It doesn't say anything about u's."
"Well, here we cross our u's too. Didn't you know that?"
"No, because it isn't mentioned anywhere."
"Well it's true anyway. Pack your things and get the hell outta here."

Job security has gotten bad enough without mandating performing above
and beyond the official call of duty, by some unspecified and
unguessable amount, such that no one can be certain whether they are
actually meeting the actual, hidden-from-them requirements or not.

Performing above and beyond the call can be a sensible factor in who
gets promoted over whom, but not, IMO, in who merely gets to keep their job.

 

[Dave Searles]

I think you realize that I personally like programming. I work for a
small consulting company, and all of my colleagues enjoy it as well.
However, when we work at client sites and interact with organic IT then
the story can be very different. The keen programmers come and go
quickly - there's a high rate of churn (it's not rare to see the really
promising programmers not even last out their probationary periods). The
ones that stick it out either never were keen or they only stayed that
way for a year or two - then reality intruded.

That could have to do with any number of environmental factors.
* Praise: or lack thereof. If they don't get raises, or at least
praises, over the mediocre programmers, they may feel
underappreciated and seek greener pastures. With their superior
skills, they've got a better shot at landing a replacement job
quickly, too.
* Institutional dumbing-down: if everyone is treated as if they
are mediocre, regardless of whether they are or not, the non-mediocre
will chafe, especially if this involves actual restrictions.
* Feedback: whether it's accepted or not. Related to the above item.
"Here, implement this interface exactly to spec" isn't very
interesting to someone with the skills and mindset to be able to
develop interfaces and whole architectures.
* Tools: If everyone's forced to use NetBeans then that whiz who'd
rather use his heavily-customized emacs and other tools isn't gonna
like it. If the language being used is bondage-and-discipline the
Lisp wizard isn't gonna like it.
* Process: If the process sucks, and dooms the project in a way that
the expert can see coming a mile away but the mediocre coders with
their noses to the grindstone haven't noticed, guess who jumps ship
first?

This discussion is not about utopia. It's about what the coding industry
currently is.

And what it currently is, is an unmentionable four letter word that
rhymes with "git".

 

[Wojtek]

Arved Sandstrom wrote :

I doubt that one in ten have ever consulted the JLS.

I do. Well at least by proxy. I ask questions here and sure enough some
wonderful soul responds.

 

[Roedy Green]

I do. Well at least by proxy. I ask questions here and sure enough some
wonderful soul responds.

We all owe a great debt of gratitude to Len and Patricia... They act
like the community's lawyers to interpret the JLS contract.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"I mean, source code in files; how quaint, how seventies!"
~ Kent Beck (born: 1961 age: 48), evangelist for extreme programming.

 

[NevilleDNZ]

My equivalent was the Algol 68 report. If ever there was a
deliberately obscure spec, that has to be it.

Deliberately? LOL!! check out this quote from "Decrypted
Secrets: Methods and Maxims of Cryptology" By Friedrich
Ludwig Bauer:
http://books.google.com/books?id=s9y9p2jP6pQC&q=ALGOL+68

Semagrams: Linguistic stenography recognizes two
methods: ... or it is expressed in the form of visible
(though often minute) graphical details in a script or
drawing, in a semagram. ... Despite its clumsiness
it lasted well: the most recent uses known to me
are A. van Wijngaardens's alleged usage of roman and
italic full stops in the ALGOL 68 report.

AND this was assuming just one message was hidden in the
report. (The report was sponsored by the UN in the middle
of the cold war ;-)

However I - for one - have not even been able to find the
suspect message (encrypted with "italic full stops") in the
"Revised Report on the Algorithmic Language ALGOL 68":
* http://books.google.com.au/books?id=vyYuAAAAIAAJ&q=eeyore

I suspect the ALGOL 68 report was only ever intended to
be read by "Language Lawyers". But was in the "additional
reading" list of some Professors simply to torment the
faster students.
c.f. http://en.wikipedia.org/wiki/Van_Wijngaarden_grammar

The classic structured (and humane) Algol68 manual to put
under ones pillow would be "Informal introduction to ALGOL 68"
By C. H. Lindsey & S. G. van der Meulen:
* http://books.google.com.au/books?id=3h8sAAAAIAAJ&q=par--

enjoy
Neville Dempsey