static hashtable with conent?

[Stefan Ram]

This really comes down to a model of programming as writing
that must communicate its meaning to two very different
audiences. One audience is the compiler, and other programming
tools. The other audience is all programmers who will ever read
the code, my future self included.

Even programmers are not all alike.

What is »readable« to one, depends on his background.

When one comes to Java and the only language one has ever used
before was Haskell, one will deem other coding constructions
as »simple« or »obvious« than someone who only has been
programming in Pascal before. When learning Java, as a first
language, people with a background in mathematics will
consider other notations readable than English majors.

»I've found that some of the best developers of all are
English majors. They'll often graduate with no programming
experience at all, and certainly without a clue about the
difference between DRAM and EPROM.

But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html

 

[Lew]

Even programmers are not all alike.

What is »readable« to one, depends on his background.

When one comes to Java and the only language one has ever used
before was Haskell, one will deem other coding constructions
as »simple« or »obvious« than someone who only has been
programming in Pascal before. When learning Java, as a first
language, people with a background in mathematics will
consider other notations readable than English majors.

»I've found that some of the best developers of all are
English majors. They'll often graduate with no programming
experience at all, and certainly without a clue about the
difference between DRAM and EPROM.

But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html

It might not be unreasonable to expect professional practitioners of
programming with a particular language such as Java to be able to read the
constructs of that language. Even "advanced" constructs with lots of
parentheses or whatever.

If you can't stand the heat, don't be a chef.

 

[Patricia Shanahan]

Lew wrote:
....

It might not be unreasonable to expect professional practitioners of
programming with a particular language such as Java to be able to read
the constructs of that language. Even "advanced" constructs with lots
of parentheses or whatever.

If you can't stand the heat, don't be a chef.

It might not be unreasonable to expect readers of English to be able to
read the constructs of that language. Even "advanced" constructs with
lots of subordinate clauses or whatever.

I can stand the heat but I would rather my readers did not have to.

Patricia

 

[Lew]

Lew wrote:
....

It might not be unreasonable to expect readers of English to be able to
read the constructs of that language. Even "advanced" constructs with
lots of subordinate clauses or whatever.

I was referring to *professionals*. A better analogy would be
(English-language) attorneys, who are expected to do exactly that with
English, or rather the specialized form of English informally called
"legalese". If you cannot parse advanced English constructs such as lots of
subordinate clauses, you should not expect to be paid as a legal professional.

We're supposed to be knowledgeable. It's why we get *paid* to do this.

 

[Lew]

I was referring to *professionals*. A better analogy would be
(English-language) attorneys, who are expected to do exactly that with
English, or rather the specialized form of English informally called
"legalese". If you cannot parse advanced English constructs such as
lots of subordinate clauses, you should not expect to be paid as a legal
professional.

Oh, I'm sorry, that was replete with subordinate clauses. I hope I'm not
being unreasonable in expecting people to be able to read them.

 

[Patricia Shanahan]

I was referring to *professionals*. A better analogy would be
(English-language) attorneys, who are expected to do exactly that with
English, or rather the specialized form of English informally called
"legalese". If you cannot parse advanced English constructs such as
lots of subordinate clauses, you should not expect to be paid as a legal
professional.

We're supposed to be knowledgeable. It's why we get *paid* to do this.

Having had to review and sign patent applications, I absolutely and
totally reject any idea of taking legalese as any sort of model for my
programming style.

Of course we are supposed to be knowledgeable, though as a student I am
not being paid to do anything. I *can* read clever code, if I have to.
My bachelor's degree was in mathematics, which tends to very succinct
notation.

I just don't see why I should make my code any harder to read than it
has to be, and I can see a lot of benefits to making it as simple and
clear as possible. That way, readers can focus on important stuff, such
as whether the map has the right initial contents, rather than details
such as the initialization method.

Patricia

 

[Lew]

I just don't see why I should make my code any harder to read than it
has to be, and I can see a lot of benefits to making it as simple and
clear as possible. That way, readers can focus on important stuff, such
as whether the map has the right initial contents, rather than details
such as the initialization method.

Your points are well reasoned and quite convincing.

 

[Mike Schilling]

Oh, I'm sorry, that was replete with subordinate clauses. I hope I'm
not being unreasonable in expecting people to be able to read them.

I think, though I'm not going to insist upon this (not being in a position
to do so, even were I so inclined to; Usenet, as a free medium, somewhat
paradoxically places fewer demands on the reader than a paid one does.
Having no money invested in the reading of a post leaves the reader free to
quit it at a moment's notice for any reason at all with no sense of having
lost any investment. This places a substantial burden on an author who
desires a wide audience to avoid being either dull or unpleasant. and
certainly to avoid unreasonable demands), that Patricia, whose general good
sense is, I should think, well established in these parts, at least to the
extent that a history of posts can be said to establish a picture of their
author (this being another subject which is open to debate: certainly, the
amount of time that, for instance, sarcasm goes undetected, argues that
Usenet posts are a very imperfect vehicle for communicating the sort of
subtleties by which people, in the common world of face-to-face
communication, use to form opinions of their fellows), has the right of it
here; that while the grammars that underlie both natural languages like
English and artificial languages like Java are capable of forming expression
and statements (and here we are lucky that both terms, while not synonymous
in the two realms, in this case can be used as if they were) of arbitrarily
high complexity, simply by applying the generation rules repeatedly, that in
both cases the idioms which are understood easily and naturally come from a
constrained application of those rules, and that using examples lying
outside the standard idioms places upon our readers, whose ready
understanding is in fact in our own interests as well as in theirs, an
unnecessary burden, and thus should be avoided or at least severely
minimized, absent any significant advantage to be found in their use.

 

[Lew]

I think, though I'm not going to insist upon this (not being in a position
to do so, even were I so inclined to; Usenet, as a free medium, somewhat
paradoxically places fewer demands on the reader than a paid one does.
Having no money invested in the reading of a post leaves the reader free to
quit it at a moment's notice for any reason at all with no sense of having
lost any investment. This places a substantial burden on an author who
desires a wide audience to avoid being either dull or unpleasant. and
certainly to avoid unreasonable demands), that Patricia, whose general good
sense is, I should think, well established in these parts, at least to the
extent that a history of posts can be said to establish a picture of their
author (this being another subject which is open to debate: certainly, the
amount of time that, for instance, sarcasm goes undetected, argues that
Usenet posts are a very imperfect vehicle for communicating the sort of
subtleties by which people, in the common world of face-to-face
communication, use to form opinions of their fellows), has the right of it
here; that while the grammars that underlie both natural languages like
English and artificial languages like Java are capable of forming expression
and statements (and here we are lucky that both terms, while not synonymous
in the two realms, in this case can be used as if they were) of arbitrarily
high complexity, simply by applying the generation rules repeatedly, that in
both cases the idioms which are understood easily and naturally come from a
constrained application of those rules, and that using examples lying
outside the standard idioms places upon our readers, whose ready
understanding is in fact in our own interests as well as in theirs, an
unnecessary burden, and thus should be avoided or at least severely
minimized, absent any significant advantage to be found in their use.

Pure brilliance. Bravo!

As I stated before, I, at least, have acknowledged the validity of Patricia's
argument in favor of clarity over cleverness.

To a point. I doubt very much that I will be afraid to use anonymous classes;
they are occasionally a necessary idiom. In some rare cases, although it has
yet to be necessary for any program I've worked on, I can imagine needing to
define an anonymous class constructor.

I am not arguing for obscurity for obscurity's sake, nor for cleverness for
cleverness's sake. It's just that in Java the anonymous class idiom is the
heart of certain closure-like expressions. If an anonymous class is the
cleanest way to accomplish such a pseudo-closure, I am going to use it, and I
will expect competent Java programmers to understand it. If I were hiring a
Java programmer, I would test them on their ability to understand anonymous
classes as part of the screening process.

OTOH, I have read at least one assertion that nested classes represent a
security hole in Java code. I am skeptical of that claim, but it's out there.

 

[Patricia Shanahan]

Pure brilliance. Bravo!

As I stated before, I, at least, have acknowledged the validity of
Patricia's argument in favor of clarity over cleverness.

To a point. I doubt very much that I will be afraid to use anonymous
classes; they are occasionally a necessary idiom. In some rare cases,
although it has yet to be necessary for any program I've worked on, I
can imagine needing to define an anonymous class constructor.

I am not arguing for obscurity for obscurity's sake, nor for cleverness
for cleverness's sake. It's just that in Java the anonymous class idiom
is the heart of certain closure-like expressions. If an anonymous class
is the cleanest way to accomplish such a pseudo-closure, I am going to
use it, and I will expect competent Java programmers to understand it.
If I were hiring a Java programmer, I would test them on their ability
to understand anonymous classes as part of the screening process.

OTOH, I have read at least one assertion that nested classes represent a
security hole in Java code. I am skeptical of that claim, but it's out
there.

I am all in favor of anonymous inner classes - when an anonymous inner
class is the simplest, clearest, or otherwise best way of expressing
something.

My objection was to an unconventional use of one in a situation in which
there is an alternative that is just as good technically and that seems
simpler and clearer to me.

Code should be as simple as possible, but no simpler.

Patricia