The greeting code in Java

[blmblm]

[ snip ]

Actually, I am going to prepare a seminar under the title: C++ vs.
Java
I try to compare C++ and Java from point of programming view.

All the more reason to try for examples that make idiomatic use
of language features, then. Your C++ program doesn't read its input
a character at a time; why should the Java program?

 

[Jeff Higgins]

Java: Accounts of My Explorations.
1. Hello

.... The maddening rattle-clank of the trucks on rails subsided as our
train approached Java Station. Outside the dusty, smokey panes of the
stifling car, amid the lush forest of Java, suddenly loomed a great line
of platforms. On and on they seemed to stretch, each different and I
hadn't been informed where to disembark. I reached for my preprocessor;
but the brown-eyed girl, sensing my anxiety, smiled and touched my hand.
"They are all the same" she whispered, "write once, run anywhere, we say
here". Pulling the signalling cord, she said "Come along, we'll get off
here and I'll show you." "We shall say hello and they will all
understand us, and smile and welcome us."
....

 

[Tobias Blass]

Even in C one would not be likely to input a string by reading one
charaacter at a time -- in a beginner program at least.

Hmm at least in K&R (the inofficial standard C learning book) you often find
while((c=getchar())!=EOF)

It's less performant than reading whole blocks but in many cases much simpler
(And that's what matters in a learning book)

 

[Stefan Ram]

Hmm at least in K&R (the inofficial standard C learning book) you often find
while((c=getchar())!=EOF)
It's less performant than reading whole blocks but in many cases much simpler
(And that's what matters in a learning book)

Usually, »getchar« already is buffered internally.

(Also, thinking about optimising even before any
requirement specification is given really seems
to be premature.)

More computing sins are committed in the name of
efficiency (without necessarily achieving it) than for
any other single reason -- including blind stupidity.

William A. Wulf

We should forget about small efficiencies, say about 97%
of the time: premature optimization is the root of all
evil.

Donald E. Knuth

We follow two rules in the matter of optimization:

Rule 1. Don't do it.

Rule 2 (for experts only). Don't do it yet -- that is,
not until you have a perfectly clear and unoptimized
solution.

M. A. Jackson

 

[Tobias Blass]

Hmm at least in K&R (the inofficial standard C learning book) you often find
while((c=getchar())!=EOF)
It's less performant than reading whole blocks but in many cases much simpler
(And that's what matters in a learning book)

Usually, »getchar« already is buffered internally.

(Also, thinking about optimising even before any
requirement specification is given really seems
to be premature.)

[snip some quotes]

M. A. Jackson

I know these quotes (every programmer should).
I didn't want to warn of using getchar. I must admit the performance thing was a
guess (and I think I read it somewhere), but even if it is the second part of
the sentence applies. Premature Optimization is mainly evil _because_ you
sacrifice simplicity (there are other reasons but this is the most important
one).

 

[Gene Wirchenko]

On Tue, 21 Jun 2011 09:34:34 +0000 (UTC), Tobias Blass

[snip]

I know these quotes (every programmer should).
I didn't want to warn of using getchar. I must admit the performance thing was a
guess (and I think I read it somewhere), but even if it is the second part of
the sentence applies. Premature Optimization is mainly evil _because_ you
sacrifice simplicity (there are other reasons but this is the most important
one).

This point was covered neatly in "Code Complete". At least, it
was in the first edition. I have not read the latest.

McConnell was writing encryption software to run on an original
IBM pc. He optimised and optimised to speed up his C code. Finally,
he hucked it and rewrote in Assembler. His observation was that as
more and more optimisations were added, the code became much less
readable.

I like to optimise for code readability. If code is useful, it
generally will have a long lifetime. That gives more opportunity for
changes being required. Changes are a real bother when the code is
not easily readable.

Sincerely,

Gene Wirchenko

 

[blmblm]

s/charaacter/character/, of course (why do these details only become
apparently *after* posting?)

Hmm at least in K&R (the inofficial standard C learning book) you often find
while((c=getchar())!=EOF)

It's less performant than reading whole blocks but in many cases much simpler
(And that's what matters in a learning book)

Well, if you say so (my copy of K&R is not easily accessed right
now). Certainly that style makes sense in examples in which
the goal is to process a character at a time (to classify/count
characters, for example, or to copy one file to another).

But is this style used in examples in which the objective is to
collect one whitespace-delimited "string" and print it? Huh.
Maybe I need to reread K&R ....

 

[Tobias Blass]

s/charaacter/character/, of course (why do these details only become
apparently *after* posting?)


Well, if you say so (my copy of K&R is not easily accessed right
now). Certainly that style makes sense in examples in which
the goal is to process a character at a time (to classify/count
characters, for example, or to copy one file to another).

But is this style used in examples in which the objective is to
collect one whitespace-delimited "string" and print it? Huh.
Maybe I need to reread K&R ....

Obviously it is not the right choice for any problem you might encounter (the
K&R examples are copy input to output, count characters, count lines etc.) but
there are situations where getchar() is useful and one should be aware that
it exists. I don't want to say that one should use it everywhere.

 

[blmblm]

[ snip ]

Obviously it is not the right choice for any problem you might encounter (the
K&R examples are copy input to output, count characters, count lines etc.) but
there are situations where getchar() is useful and one should be aware that
it exists. I don't want to say that one should use it everywhere.

Well, we agree that there are situations in which reading input
a character at a time makes perfect sense, and others in which it
doesn't. I claim that the OP's greeting program is in the second
category. You might disagree!