My new toy

[Mike Schilling]

And before that, what you called "hazing a newbie" often wasn't.

The only example I can think of that might be called "hazing a
newbie"
recently was a certain attempt to scare newbies away from reading
the
JLS or the Javadocs my comparing it to a "superhuman ability" to
"read Chinese".

That's an odd metaphor, considering the sheer number of perfectly
ordinary people who read Chinese every day.

 

[Lew]

That's an odd metaphor, considering the sheer number of perfectly
ordinary people who read Chinese every day.

I thought so when I read it originally, too, but I was more disturbed by the
attempt to characterize reading the Javadocs and the Java Language
Specification as something scary and difficult as opposed to something
necessary and attainable than by the jingoism.

 

[David Segall]

How big is your screen in pixels? Mine is 1900 × 1200.

I find it hard to come out with a single layout that looks good at a
wide range of screen sizes. Artistic skill is one of my biggest
weaknesses.

Since I have icons in sizes from 16x16 up to 256x256, perhaps with
variable style sheets and JSP, I will be able to customise the layouts
better.

It might also be possible to let the user grow and shrink the text,
independently of the graphic elements.

Does any browser support a scheme where you can specify style sheets
that are automatically applied to just one website, or that augment
the website's style sheets?

If knew the user's screen width, I could reduce the number of columns
on button menus when they would not all fit. These are things that
would require JSP.

I started a reply to this but it turned into a web page
<http://www.profectus.com.au/ee_multicolumn.html>. Judging from your,
much appreciated, Java Glossary I'm sure you understand how that
happened

 

[RedGrittyBrick]

I started a reply to this but it turned into a web page
<http://www.profectus.com.au/ee_multicolumn.html>. Judging from your,
much appreciated, Java Glossary I'm sure you understand how that
happened

Very useful and interesting. A bit Off Topic.

Great in Firefox. Obviously, IE8 lacks support for this, but renders it
as a single column so not a complete disaster.

 

[Roedy Green]

That's an odd metaphor, considering the sheer number of perfectly
ordinary people who read Chinese every day.

Of course, but they spend 12+ years of study learning how to do it. It
is not something that you should just be expected to know as a matter
of course.

Lew and I disagree on the JLS.

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.

2. Understanding such documents is perhaps something like violin
playing. Most people CAN'T do it, no matter how hard they try.

3. People who can do it make it look effortless.

A story. I was once hired to document a 3D differential solving
program for a university professor that could be used to track flows
and diffusions of chemicals in waterways or soil. The math was
terrifying with the deeply nested integrals.

I discovered a metaphor that make it intuitively clear just how the
algorithm worked. The author insisted I remove it from the
documentation, because it made the discovery look too obvious.

Spec writers want their work to look grand, so they use a formal
language where they avoid examples and avoid disabusing possible
misinterpretations. It is a way of demonstrating competence -- *I*
can understand this gibberish. How intelligent I must be! You are
unworthy before me.


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

Of course, but they spend 12+ years of study learning how to do it. It
is not something that you should just be expected to know as a matter
of course.

Lew and I disagree on the JLS.

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.

2. Understanding such documents is perhaps something like violin
playing. Most people CAN'T do it, no matter how hard they try.

3. People who can do it make it look effortless.

[ SNIP ]

You mentioned "average" programmers. I contend that not many "average"
programmers need a formal language specification. In fact, and at risk
of venturing a circular argument, I'd say that if a programmer _can_
make effective use of a formal programming language specification,
they're above average.

Why would an "average" programmer even need the JLS? The APIs and a
handful of decent books will serve them much better.

Spec writers want their work to look grand, so they use a formal
language where they avoid examples and avoid disabusing possible
misinterpretations. It is a way of demonstrating competence -- *I*
can understand this gibberish. How intelligent I must be! You are
unworthy before me.

A lot of specs are like that, sure. Especially internal ones. But the
JLS is pretty good as these documents go.

AHS

 

[Lew]

Why would an "average" programmer even need the JLS? The APIs and a
handful of decent books will serve them much better.

Another thought occurs to me. Before I state it, let me point out that I am
in favor of API docs and decent books (Bloch's /Effective Java/, Goetz et
al.'s /Java Concurrency in Practice/), and of online resources like
javapassion.com, mindprod.com, java.sun.com,
<http://www.ibm.com/developerworks/java> and the rest. For learning Java and
gaining true insight and mastery, they are /nonpareil/. I recommend using the
JLS as an arbiter and research tool, not a tutorial. That provides a direct
answer to Arved's excellent question. (Calling it "silly" is a rhetorical
device only, not a real judgment.) I started getting in the habit of using
the JLS to answer tricky detailed questions about Java behavior, particularly
generics and the multi-threading memory model. As an adjunct to the
aforementioned excellent sources, the JLS was invaluable.

The other thought is that the JLS is important for more than individual
programmers, or the obvious purpose of ensuring specific promises in Java
implementations. (Not totally successfully - Sun themselves violated the spec
prior to Java 5 by letting references to the 'class' literal initialize the
class.) As a social document, it's important as a bar for programmers. A
"fool bar", if you will, pun intended. In one's quest for perfection as a
developer, one should not shirk knowing the real rules, not just the second-
and third-hand re-interpretations. To become competent at if not comfortable
with reading the Java Language Specification is to achieve real competence
with the language, and an inability to read the defining document will always
be a serious handicap to any serious programmer.

As a body, the guild of Java programmers benefits by requiring competence in
the JLS in order to assert competence in the Java language. How can you trust
someone to work in the language who isn't even able to comprehend its
definition, or even to approach reading the definition from time to time?

 

[Arved Sandstrom]

Silly question. All Java programmers need the JLS in order to be
certain of behaviors and to answer the kinds of questions that we see
all the time in this newsgroup.

[ SNIP ]

I agree. But then you'd be seriously raising the bar as to what is
considered to be an "average" Java programmer. As it is, I doubt that
one in ten have ever consulted the JLS.

My point is, well over half of the Java programmers I've ever worked
with would need some extensive programming education before the JLS
would ever be really useful to them. Hell, they'd need remedial basic
education; I'll wager that a majority of Java programmers today wouldn't
be able to thoroughly grasp the discussion about floating point types in
the JLS. Just to cherrypick one example.

In theory, sure, every Java programmer should use the JLS as required.

AHS

 

[Mike Schilling]

Of course, but they spend 12+ years of study learning how to do it.
It
is not something that you should just be expected to know as a
matter
of course.

Lew and I disagree on the JLS.

1. I contend it was DELIBERATELY written to be obscure and
inaccessible to average programmers.

Not to be rude, but that's insane. The JLS is perhaps the most
readable language spec I've ever seen. It's written in clear, even
elegant English, gives lots of examples, and often takes time out to
explain why things work the way they do. Picking a paragraph at
random:

5.1.1 Identity Conversions
A conversion from a type to that same type is permitted for any type.

This may seem trivial, but it has two practical consequences. First,
it is always
permitted for an expression to have the desired type to begin with,
thus
allowing the simply stated rule that every expression is subject to
conversion,
if only a trivial identity conversion. Second, it implies that it is
permitted for a
program to include redundant cast operators for the sake of clarity.

The meaning of that is perfectly clear, and writers who were trying to
be obscure would have left out that second paragraph.

 

[Arved Sandstrom]

Another thought occurs to me. Before I state it, let me point out that
I am in favor of API docs and decent books (Bloch's /Effective Java/,
Goetz et al.'s /Java Concurrency in Practice/), and of online resources
like javapassion.com, mindprod.com, java.sun.com,
<http://www.ibm.com/developerworks/java> and the rest. For learning
Java and gaining true insight and mastery, they are /nonpareil/. I
recommend using the JLS as an arbiter and research tool, not a
tutorial. That provides a direct answer to Arved's excellent question.
(Calling it "silly" is a rhetorical device only, not a real judgment.)
I started getting in the habit of using the JLS to answer tricky
detailed questions about Java behavior, particularly generics and the
multi-threading memory model. As an adjunct to the aforementioned
excellent sources, the JLS was invaluable.

The other thought is that the JLS is important for more than individual
programmers, or the obvious purpose of ensuring specific promises in
Java implementations. (Not totally successfully - Sun themselves
violated the spec prior to Java 5 by letting references to the 'class'
literal initialize the class.) As a social document, it's important as
a bar for programmers. A "fool bar", if you will, pun intended. In
one's quest for perfection as a developer, one should not shirk knowing
the real rules, not just the second- and third-hand re-interpretations.
To become competent at if not comfortable with reading the Java Language
Specification is to achieve real competence with the language, and an
inability to read the defining document will always be a serious
handicap to any serious programmer.

As a body, the guild of Java programmers benefits by requiring
competence in the JLS in order to assert competence in the Java
language. How can you trust someone to work in the language who isn't
even able to comprehend its definition, or even to approach reading the
definition from time to time?

I agree with all of the above. But if as much as ten percent of Java
programmers currently hold themselves to such high standards I'd be
pleasantly surprised.

Fact is, employers don't typically establish a high bar for entry in the
world of professional Java programming. The typical software developer
soon learns that most of their colleagues work 9-5; they leave the job
at the work place. It's not a profession. Technical competence takes
second seat to political skills when angling for most higher level
technical jobs, so that incentive to excel professionally disappears as
well.

I'm trying not to cast aspersions here on most people. There _is_ quite
a large percentage of programmers, that if I had my druthers, would get
fired. They're hacks, and they don't enjoy what they do. But there's
also a large percentage of programmers who are worn out by the realities
of the workplace - after some years (including exposure to the first
category of people) they lose their ambitions. They're not likely to
give a damn about the JLS, or reading "Java Concurrency In Practice" or
"Effective Java" in their spare time.

Continuing to take pride in one's profession - indeed, even treating it
as a profession -, delivering that unasked for extra effort and polish,
and working in one's own time to excel (likely for little or no external
reward), is simply not something that more than a small fraction of
programmers do.

It's nice to talk about the value of the JLS. But usually the people who
are interested enough in the JLS to use it don't have to be told about it.

AHS

 

[Martin Gregorie]

Of course, but they spend 12+ years of study learning how to do it. It
is not something that you should just be expected to know as a matter of
course.

Generally, you're right. However, there are exceptions. The best spec I
ever read was "A very Informal Introduction to Algol 68". It was
readable. You've got to love a spec that starts by saying something like
"This introduction is recursive because the language it describes is
recursive. This means you won't understand this document until you've
read it all." Yes, it was funny - rib-splittingly so in places. And, if
you you had a machine readable version if it, you could compile it.

 

[Martin Gregorie]

On Fri, 04 Sep 2009 15:20:28 +0100, RedGrittyBrick wrote:

Works well in Opera 10.0 too.

 

[Lew]

I'm trying not to cast aspersions here on most people. There _is_ quite
a large percentage of programmers, that if I had my druthers, would get
fired. They're hacks, and they don't enjoy what they do. But there's

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

also a large percentage of programmers who are worn out by the realities
of the workplace - after some years (including exposure to the first
category of people) they lose their ambitions. They're not likely to
give a damn about the JLS, or reading "Java Concurrency In Practice" or
"Effective Java" in their spare time.

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.

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.

Continuing to take pride in one's profession - indeed, even treating it
as a profession -, delivering that unasked for extra effort and polish,
and working in one's own time to excel (likely for little or no external
reward), is simply not something that more than a small fraction of
programmers do.

And you think that's acceptable?

It's nice to talk about the value of the JLS. But usually the people who
are interested enough in the JLS to use it don't have to be told about it.

Well, my concern in this thread has been for newbies who *do* need to be told
about it, and *do* need to be told it isn't the dark mystery and impenetrable
high wall of virtuosity some people seem to want to make it out to be.

Furthermore, any attempt to excuse unwillingness to learn or to pursue quality
in software development should be mercilessly quashed. Fie!

 

[Roedy Green]

You mentioned "average" programmers. I contend that not many "average"
programmers need a formal language specification.

Don't let Lew hear you say that. He figures every programmer should
feel comfortable reading the JLS.

I think a spec could be translated into a list of specific things the
average programmer needs to know. Most of it is only of interest to
compiler writer.

There is another sort of problem I have with specs. You read five
paragraphs of dense prose and finally decide that they have told you
nothing unusual at all. All was done in the usual way. Maybe specs
should be written in various shades for how surprising what is being
said might be. You miss fine points because ordinary things are beaten
to death.

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. I
try to do that to some extent with
http://mindprod.com/jgloss/enum.html
but it has a fair way to go to incorporate all the lore in the JLS.

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

A lot of specs are like that, sure. Especially internal ones. But the
JLS is pretty good as these documents go.

Agreed. I would give it a B in comparison with other specs.
--
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]

Very useful and interesting. A bit Off Topic.

This is slick! It is fast and looks great. Now to figure out how it
works.

Works with Chrome, Firefox, Safari

partially works on Flock, Sea Monkey ( no vertical bars )

Does not work in Opera, IE, Avant

The glossary started as notes to myself about what I had discovered
about Java. When I first posted it, did I ever get flack for trying to
mislead people about how Java worked. Nothing helps you get rid of
your misconceptions faster than posting what you think is true.
--
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]

This is slick! It is fast and looks great. Now to figure out how it
works.

Works with Chrome, Firefox, Safari

partially works on Flock, Sea Monkey ( no vertical bars )

Does not work in Opera, IE, Avant

It is very simple, and the working document describes it clearly. It
needs a min-column-length so that it does not go to multicolumns that
has only one line in them.
--
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]

Algol 60 statement? Explain your answer in terms of the Algol 60 Report.".

My equivalent was the Algol 68 report. If ever there was a
deliberately obscure spec, that has to be it. It was a recursive
document. The formal description required expansion, which then was
the formal description of particular implementation of Algol 68.

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

Works well in Opera 10.0 too.

that's odd. It is not working for me. I am using Windows version. What
about you?
--
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]

I experimented with it in the Java glossary and discovered it makes a
total mess if you have any elements wider than your column width. IT
overlaps.

For future reference, I have documented this at
http://mindprod.com/jgloss/css.html#NEWSPAPER
--
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.