AspectJ: solution to Java's repetitiveness?

[Stefan Ram]

The code bloat/readability argument has some small merit...not so much the

When one tries to keep a language small, reoccuring idioms
will develope, hence redundancy. The advantage still is:
Everyone knowing the small language can derive the meaning of
those idioms upon encountering them from his knowledge of the
small language.

To get rid of this redundancy, one can add special-case rules
or additional keywords for those idioms. This makes source
code smaller, but makes the language specification larger.
The new rules or the meaning of the new keywords can not be
derived upon encountering them, but has to be learned. So this
language will be more difficult to learn and to maintain.

For example, in Lisp, one can write macros for reoccuring
idioms, but anyone who wants to read a program using them has
to learn these macros first (or at least, when he is reading a
usage of one of these macros).

 

[Mark Space]

Can't you just add a (custom) annotation, e.g. "@JavaBean", and use
apt to generate the getters/setters? (Or possibly the newer
javax.annotation* stuff?) You could add options to such an
annotation e.g., read-only.
Then add the one extra line in your ant script to build code.

Note JavaEE defines many such annotations, including for an
MX Bean. Adding a standard annotation "@JavaBean" doesn't seem
like it would be that much effort, for a large convenience payoff.

It's also extra linguistic, which might help to keep the language small
while at the same time preserving readability. It's not one or two
getters/setters that the issue. It's when a class has twenty or thirty
that it starts to impinge on readability.

For more flexibility, something like this (syntax totally invented):

import javax.some.annotaion.framework.*;

public class PlentyAttributes {

private final static int SOME_CONST = 2;

private String internalValue;

@AttribReadOnly
{
private String value1;
private String value2;
private String value3;
private String value4;
}

@AttribMutator // = getter + setter
{
private String valueA;
private String valueB;
private String valueC;
private String valueD;
private String valueE;
private String valueF;
}

@AttribWriteOnly
{
private String valueX;
}

}

I think something like this, with braces to group fields, would improve
readability of classes with large numbers of properties, and also not
require any modifications to the core language. It could be stuffed in
a framework and left for the folks who think it would be useful.

 

[jhc0033]

mv discussion comp.lang.scheme

For example, in Lisp, one can write macros for reoccuring
idioms, but anyone who wants to read a program using them has
to learn these macros first (or at least, when he is reading a
usage of one of these macros).

The answer to this old argument is that this is no different from
procedures.

 

[Stefan Ram]

The answer to this old argument is that this is no different from
procedures.

In most programming languages, parameters of procedures are
strict (they are evaluated at the time of the call). This
gives the reader of an invocation of a procedure some basic
information that is always valid. (In languages with
call-by-value only, one even can deduce that a call will never
alter an argument variable.)

Macros might have lazy parameters (they do not need to
evaluate all of their arguments), which opens more
possibilities for the interpretation of a macro call than for
the interpretation of a procedure name - even in the presence
of a good mnemonic macro name. They also might modify an
argument variable or do other things procedures can't do
and are overall more powerful than procedure calls.

(In languages with more syntax than Lisp, macros or language
extensions also might add additional syntax, which also makes
reading them more difficult.)

 

[Mark Space]

mv discussion comp.lang.scheme



The answer to this old argument is that this is no different from
procedures.

Then why not forego macros, and use procedures?

The answer is that macros do things that procedures don't, are extra
linguistic, and are frequently abused in ways that not available in
procedures.

 

[Abdulaziz Ghuloum]

Then why not forego macros, and use procedures?

The answer is that macros do things that procedures don't, are extra
linguistic, and are frequently abused in ways that not available in
procedures.

In comp.lang.scheme, we frequently abuse procedures as well.
(see Guy Steele's ``Lambda: the ultimate goto''). Should we
ban lambda too by that argument?

Aziz,,,

 

[Mark Space]

Should we
ban lambda too by that argument?

Java did....

 

[Arne Vajhøj]

That's the thing. In Java it often does mean repetitive.

Not in my understanding of those two words.

Arne

 

[Arne Vajhøj]

Some people do. Read the first comment there:

http://hathawaymix.org/Weblog/2004-06-16

"I recall how one day I walked out of work and my hands hurt so much
from typing Java code, because Java is so needlessly verbose."

If the complexity of the task is so that it is possible to type
code all day, then Java is very likely not the optimal
language. Java was not intended for such trivial tasks.

The average productivity for a Java programmer are
probably in the 10-50 lines per day range as average.

Software development is about thinking not about
typing.

Arne

PS: The article is rather funny. Statements like "Zope, it turns out,
had already solved most of the problems I had with my homegrown
application server" gives a good impression of why this person
did not like Java.

 

[Abdulaziz Ghuloum]

Java did....

No argument then.

Aziz,,,

 

[Arne Vajhøj]

Sometimes I tire of typing code like

CleverGreenThing<WingNut, CorkScrew, BathTub> foo
= new CleverGreenThing<WingNut, CorkScrew, BathTub>();

I wonder if my IDE can (be trained to) expand "= new();"?

Eclipse does come with a suggestion if you type:
new CTRL/SPACE

Arne

 

[Stefan Ram]

Nobody writes code or documentation so fast that their typing
prowess (or lack of it) should be a drawback.

»He used this funky ergonomic keyboard

http://www.kinesis-ergo.com/essential.htm

and when he typed it sounded like one of those ratcheting
noisemakers you spin over your head at new years.

I once came to ask him a question that I thought would
take me half an hour to figure out on my own and he
replied, "Well, let's find out" and in less than a minute
he whipped up a piece of code that answered my question.
My jaw was on the floor.«

http://xooglers.blogspot.com/2005/12/they-say-its-darkest-before-dawn.html

 

[Andreas Leitgeb]

@AttribReadOnly
{
private String value1;
private String value2;
private String value3;
private String value4;
}

When I think of how Java and C++ treat differently the
"range" of a public/protected/private keyword, I'd be
very much surprised by one instance of an Annotation
being ever defined to be applied to each of a group of
items.

 

[Andreas Leitgeb]

The boilerplate code is an advantage, not a problem.

You should really add that to your signature,
as it seems to be your mantra

PS: You surely never omit the "value=" boilerplate when
applying such a single-argument annotations, right?

 

[Mark Space]

PS: The article is rather funny. Statements like "Zope, it turns out,
had already solved most of the problems I had with my homegrown

In Python! Lots of Java solutions out there too if you just want a
quick download. (Not you personally, you-generically. You<P> as it
were. )

<http://java-source.net/open-source/content-managment-systems>

Lots of CMS out there, not to mention other web frameworks. Me thinks
the author of the article is setting up straw men that he can easily cut
down. I wonder how his arguments would fare against a more reasonable
opponent....

 

[Arne Vajhøj]

In Python! Lots of Java solutions out there too if you just want a
quick download. (Not you personally, you-generically. You<P> as it
were. )

<http://java-source.net/open-source/content-managment-systems>

Lots of CMS out there, not to mention other web frameworks. Me thinks
the author of the article is setting up straw men that he can easily cut
down. I wonder how his arguments would fare against a more reasonable
opponent....

Java is certainly behind when it comes to number of CMS systems.

But he specifically mentioned app servers. Java is far ahead
when it comes to number of app servers.

Arne

 

[Mark Space]

When I think of how Java and C++ treat differently the
"range" of a public/protected/private keyword, I'd be
very much surprised by one instance of an Annotation
being ever defined to be applied to each of a group of
items.

I think there's other reasons why that would never happen, including
that braces at the class level look a lot like static initializer
blocks, and the language (or the compiler) would have to be extended to
add them.

Still I think it would be worthwhile to add some kind of "annotated
block" at the class and the method level.

 

[Ken Tilton]

In most programming languages, parameters of procedures are
strict (they are evaluated at the time of the call). This
gives the reader of an invocation of a procedure some basic
information that is always valid. (In languages with
call-by-value only, one even can deduce that a call will never
alter an argument variable.)

Macros might have lazy parameters (they do not need to
evaluate all of their arguments), which opens more
possibilities for the interpretation of a macro call than for
the interpretation of a procedure name - even in the presence
of a good mnemonic macro name. They also might modify an
argument variable or do other things procedures can't do
and are overall more powerful than procedure calls.

We might have a forest for the trees situation here, trying to make
sense out of the value of macros by this bizarre metric of how much gets
done with arguments. That is what happens when smart people get to
bullshitting. A simpler approach to the question can be had from simple
application programmers like me, who would point out that we use macros
to hide repetitive boilerplate. Wow. That means the essence of what is
going on at any point in the code is not hard to find, everything that
is not essence is handled by the macro-expansion. The moral of the story
is that the last thing we want to know is what is being done with the
arguments, we just want the name of the macro to be honored by its
performance.

When things go wrong... can you say macroexpand? Sher ya can.

kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/

"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.

"My sig is longer than most of my articles."
-- Kenny Tilton

 

[thufir]

Sooner or later you'll have to forget about college, and move on to
learning.

Well, everything else being equal, college would be an asset.


-Thufir

 

[thufir]

Can't you just add a (custom) annotation, e.g. "@JavaBean", and use apt
to generate the getters/setters? (Or possibly the newer
javax.annotation* stuff?) You could add options to such an annotation
e.g., read-only.
Then add the one extra line in your ant script to build code.

I think an annotation to do that would great


-Thufir