Tired of 100s of stupid Getter/Setter methods

[Joseph Dane]

Looking at this doesn't give me any sense of what's going on. I have to
analyze this in detail to see what's happening. It's not only harder
to write, it's much harder to understand.

I think that the biggest contribution in this particular case comes
from the lack of a printf/scanf in the standard java libraries, which
does indeed suck.

also previously mentioned is the anonymous inner class syntax, which
will not win any awards for style, but is still a long way from
"borderline unreadable gibberish".

everyone has a favorite language, or syntax, or whatever, and if you
want smalltalk, you know where to find it. on the whole, I find Java
to be about average in terms of the ugly/pretty (or concise/verbose,
or however you want to define it) continuum.

 

[John C. Bollinger]

Normally, I would let Mark answer for himself, as he probably will, but
from the standpoint of someone who has taught Java I have to agree with
him. Java has wandered far from the conceptual simplicity of the
languages that preceded it (except perhaps, C++) and its many keywords
and inconsistancies can make it look like a lot of gibberish--even to
those familiar with programming. The number and size of books on Java
programming are a fairly decent indicator of its complexity--and
complexity is not necessarily proportional to functionality.

I can't speak about all available Java texts, nor even any sizable
fraction of them, but I suggest that most Java texts are in fact not
about Java the language only, but also about the Java platform API and
OO programming. That goes a long way toward explaining both number and
size of Java texts. To the extent that generics blend the platform API
with base language features it may no longer be completely fair to try
to draw a line there, but nevertheless I do. I'd also venture to
suggest that the number of Java books has at least as much to do with
the popularity of the language as it has to do with the complexity of
the language.


John Bollinger
(e-mail address removed)

 

[Andrew Thompson]

I do not find your test code very
convincing Tom (continues below)

| public class Adder {
|
| public static void main(String[] args) throws Exception {
|
| // Use BufferedReader and StringTokenizer since
| // StreamTokenizer can't handle exponents (e.g.,
5.3E-6)
|
| java.io.BufferedReader br = new
java.io.BufferedReader(
| new
java.io.InputStreamReader(System.in));
| String line = br.readLine();
|
| java.util.StringTokenizer st = new
java.util.StringTokenizer(line);
|
| double v1 = Double.parseDouble(st.nextToken());
| double v2 = Double.parseDouble(st.nextToken());
|
| System.out.println(v1+v2);
| }
| }

try mine..
public class Adder2 {
public static void main(String[] args) {
System.out.println(Double.parseDouble(args[0])+
Double.parseDouble(args[1]));
}
}

It's one line longer than the examples
you put, but uses the same conventions
no blank lines, no comments..

And of course it reads the args the way
you normally would in a little java class,
straight from the command invocation..

Point being, in just about _any_ language
you can find a situation that is 'harder' than
what it would be in another language.
Languages are different and have different
specialties and strengths.

 

[Chris Smith]

Point being, in just about _any_ language
you can find a situation that is 'harder' than
what it would be in another language.
Languages are different and have different
specialties and strengths.

That is a good point. The example here was specifically chosen to
require a console-based user-interface, something that Java quite
clearly and intentionally doesn't really provide as an option. As soon
as you choose a less exotic (in modern terms, not 10 years ago) way to
get the input, Java starts to look a little better.

Nevertheless, clearly there are parts of Java that are not well-liked by
some developers. The point is, though, that if Java as a whole looks
unbearable to you, it doesn't say much that X feature doesn't look
desirable to you either. Features in Java can't reasonably be judged by
how much they look like Common Lisp.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jon A. Cruz]

I think that the biggest contribution in this particular case comes
from the lack of a printf/scanf in the standard java libraries, which
does indeed suck.

Have you looked into the use of MessageFormat and it's friends for these
tasks? For many things they seem much clearer to me, at least from an OO
standpoint.

 

[Tom McGlynn]

That is a good point. The example here was specifically chosen to
require a console-based user-interface, something that Java quite
clearly and intentionally doesn't really provide as an option. As soon
as you choose a less exotic (in modern terms, not 10 years ago) way to
get the input, Java starts to look a little better.

Nevertheless, clearly there are parts of Java that are not well-liked by
some developers. The point is, though, that if Java as a whole looks
unbearable to you, it doesn't say much that X feature doesn't look
desirable to you either. Features in Java can't reasonably be judged by
how much they look like Common Lisp.

Hmmm.... I hope it doesn't make one a dinosaur to actually have programs
that read input from users in files. The example I gave was inspired
from a filter I wrote last week which converted a list of coordinate pairs from
one coordinate system to another, so the whole program was in a loop --
using command line arguments would not suffice there. Even if the
input string came from a GUI component I find that the string is far
more naturally parsed than in Fortran or C. The advantage that Java
has here is that it has standard mechanisms for creating such a GUI
component. But it's not clear to me why we needed to lose the
much greater flexibility and convenience that we had in earlier languages.
Languages aren't a zero sum game.

Nor do I think "love it or leave it" is the only appropriate response to criticisms
of a language. There was enormous criticism of the inflexibility of the
mathematical model used in the original Java specification and this was changed
in later versions of Java. There was great pressure to add templating to Java,
and a mechanism for this is about to be released. Discussion of the issues
where users feel Java is lacking or difficult to use are surely needed if Java
is to evolve in the most productive fashion.

Personally I feel that the multi-layered intricately interconnected
classes and packages for doing I/O in Java are far more complex than
need be and perhaps more important, they require users to know far too much
of fairly abstruse details. Already there have been two major overhauls of I/O
and some areas (e.g., imaging) have developed there own special low level I/O classes.
Streams, Formats, Files, RandomAccessFile, Messages, Readers, Writers,
Buffers (of two different kinds), Channels, encodings, ....

This is not to suggest that I/O will ever be trivial, but Java has raised its
complexity to a whole new level. So generally I like working with Java. But to
me its big win is not its syntax -- it's the fact that programs work --
and fail -- consistently on all platforms.

Regards,
Tom McGlynn

 

[Joseph Dane]

Have you looked into the use of MessageFormat and it's friends for
these tasks? For many things they seem much clearer to me, at least
from an OO standpoint.

clearer? seriously?

I don't see how anything could be clearer than

printf ("the string is %s and the float is %f\n", s, f);

MessageFormat at least requires you to convert primitives into
wrappers.

actually, the MessageFormat stuff is very cool, and very helpful.
but the point of *this particular example* above was to show how
something simple in C is somewhat less simple in Java. that's all,
and IMO most examples supposedly showing how much easier C is to read
than Java are at about the same level of complexity as that one.

 

[Jon A. Cruz]

clearer? seriously?

I don't see how anything could be clearer than

printf ("the string is %s and the float is %f\n", s, f);

MessageFormat at least requires you to convert primitives into
wrappers.

actually, the MessageFormat stuff is very cool, and very helpful.
but the point of *this particular example* above was to show how
something simple in C is somewhat less simple in Java. that's all,
and IMO most examples supposedly showing how much easier C is to read
than Java are at about the same level of complexity as that one.

Actually.... that's exactly my point.

You think that the C is simple, but for many applications that is
woefully inadequate. Especially if your application needs to be
internationalized (more important in this modern Internet age), that C
code doesn't do all that is needed. It needs a fair bit of work to
deliver the intended functionality.


On the other hand, all the Java1 MessageFormat version needs is to get a
different format string loaded.


And for trivial cases, the equivalent Java is
System.out.println( "the string is " + s + " and the float is " + f );

 

[Joseph Dane]

Actually.... that's exactly my point.

yeah. mine too.

You think that the C is simple, but for many applications that is
woefully inadequate. Especially if your application needs to be
internationalized (more important in this modern Internet age), that C
code doesn't do all that is needed. It needs a fair bit of work to
deliver the intended functionality.

I don't think we're disagreeing here. The example cited had no need
for i18n, and never would. It was, by construction, a simple program
that demonstrated how C (or really, printf/scanf) could be simpler to
read.

of course, it did ignore the "scanf takes pointer args" thing that
leads C newbies quickly into pointer insanity.

in fact, printf *would* be nice to have in Java, but I think the
primitive/object duality of Java screws things up. generally
speaking, when I find I need printf in Java, I switch to Perl.

And for trivial cases, the equivalent Java is
System.out.println( "the string is " + s + " and the float is " + f );

but you can't specify precision.

 

[Sudsy]

Jon A. Cruz wrote:

You think that the C is simple, but for many applications that is
woefully inadequate. Especially if your application needs to be
internationalized (more important in this modern Internet age), that C
code doesn't do all that is needed. It needs a fair bit of work to
deliver the intended functionality.


On the other hand, all the Java1 MessageFormat version needs is to get a
different format string loaded.


And for trivial cases, the equivalent Java is
System.out.println( "the string is " + s + " and the float is " + f );

Exactly! While C programmers are accustomed to the special format
characters in printf strings, programmers in other languages can
(rightfully) ask "what with this % stuff and the \n at the end of
the string?".

 

[beagle]

I don't think we're disagreeing here. The example cited had no need
for i18n, and never would. It was, by construction, a simple program
that demonstrated how C (or really, printf/scanf) could be simpler to
read.

You could demonstrate that Java is more readable than C by creating
a different example. String building for example. In C you worry
about arbitrary buffer sizes or start getting advanced and malloc()
and realloc() your memory appropriately.

In a nutshell, toy programs that do things like add A and B are rarely
useful for proving anything. Yes, C is simpler than Java for some
things. And yes, Java is simpler than C for some things. Where it
starts really counting is when you get out of "toy program" land...

 

[beagle]

Personally I feel that the multi-layered intricately interconnected
classes and packages for doing I/O in Java are far more complex than
need be and perhaps more important, they require users to know far too much
of fairly abstruse details.

I've got to agree with you that java.io sucks.

 

[Hylander]

Ok, I went over the top, it aren't 100s of lines but it are enough. It just
superflues code that bloats the code and deflects from the essential.

Timo

If you have 100s (like 500) of lines, I'd assume you have way too many
variables and a class that's too large. We have 10 fingers for a
reason.

Keep element complexity below ten in programming. (unless you want to
hard code the yellow pages...(somewhere, that could be needful...but
not in a program where you are going to have logic going all over as
it is.) ).

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

<snip>

In a nutshell, toy programs that do things like add A and B are rarely
useful for proving anything. Yes, C is simpler than Java for some
things. And yes, Java is simpler than C for some things. Where it
starts really counting is when you get out of "toy program" land...

Hopefully, sophisticated programs are made up smaller less sophisticated
(toy) objects. My goal is to have as many toys in my programs as
possible. All my code should be that simple.

 

[Dimitri Maziuk]

Jon A. Cruz sez:

And for trivial cases, the equivalent Java is
System.out.println( "the string is " + s + " and the float is " + f );

Which is where the whole "immutable strings" mess comes in,
of course. IRL you'll either use StringBuffer where you have
to type 9 characters (.append()) instead of a single '+', or
print each bit in a separate println() call (even more
typing).

Dima

 

[Jon A. Cruz]

Jon A. Cruz sez:



Which is where the whole "immutable strings" mess comes in,
of course. IRL you'll either use StringBuffer where you have
to type 9 characters (.append()) instead of a single '+', or
print each bit in a separate println() call (even more
typing).

No, not at all.

Either it's some simple debugging type thing, or it's not. If it's
simple debugging, then the code as I have it there is fine. If not, then
a proper MessageFormat-based display is the appropriate call.