Static type checking: hybrid mode in Groovy

[Robert Klemme]

Folks,

we recently had this discussion about the benefits of STC: Groovy now
takes a hybrid approach and allows to use both. For the interested
reader:

http://www.jroller.com/melix/entry/groovy_static_type_checker_status

They are trying to have the best of both worlds.

I find this quote noteworthy:

"One of them is that Java programmers who discover Groovy are often
amazed about the conciseness of the language as compared to Java, and
start programming in Groovy like they would in Java, that is to say
with types and leveraging the syntax of Groovy. The key here is that
many programmers never use the dynamic features of Groovy, but rather
use the language as a "better Java syntax"."

Kind regards

robert

 

[Roedy Green]

"One of them is that Java programmers who discover Groovy are often
amazed about the conciseness of the language as compared to Java, and
start programming in Groovy like they would in Java, that is to say
with types and leveraging the syntax of Groovy. The key here is that
many programmers never use the dynamic features of Groovy, but rather
use the language as a "better Java syntax"."

The verbosity of Java has always bothered me. Early on I lobbied for
various measures to put it on a diet. The biggest win was for:each.
The Java creators are only now beginning to relax their resistance to
syntactic sugar to make programs terser, hence easier to type and
proofread.

I think the problem was/is:

1. Sun was far more interested in the JVM than the Java language. In
their view, Javac.exe was just a preprocessor for the JVM byte code.
It was a necessary kludge, but of no interest in itself. The innards
of the JVM is the exciting part. Java the language is pretty dull and
clumsy. The WORA comes from the JVM, not a major revolution in the
language.

2. People who write system code think a long time and produce a small
number of carefully-chosen keystrokes, overwhelmingly comments.
Application programmers crank out reams and reams of twaddle. Thus
system programmers have little motivation to be interested in
terseness.

 

[Lew]

Robert Klemme wrote, quoted or indirectly quoted someone who said :

The verbosity of Java has always bothered me. Early on I lobbied for
various measures to put it on a diet. The biggest win was for:each.
The Java creators are only now beginning to relax their resistance to
syntactic sugar to make programs terser, hence easier to type and
proofread.

Conciseness is overrated.

I think the problem was/is:

1. Sun was far more interested in the JVM than the Java language. In
Evidence?

their view, Javac.exe was just a preprocessor for the JVM byte code.
It was a necessary kludge, but of no interest in itself. The innards
of the JVM is the exciting part. Java the language is pretty dull and clumsy.

Unsubstantiable opinion.

The WORA comes from the JVM, not a major revolution in the
language.

2. People who write system code think a long time and produce a small
number of carefully-chosen keystrokes, overwhelmingly comments.
Application programmers crank out reams and reams of twaddle. Thus

Oh, really?

Are you an application programmer?

system programmers have little motivation to be interested in
terseness.

Wow.

 

[Gene Wirchenko]

The verbosity of Java has always bothered me. Early on I lobbied for
various measures to put it on a diet. The biggest win was for:each.
The Java creators are only now beginning to relax their resistance to
syntactic sugar to make programs terser, hence easier to type and
proofread.

I can live with some verbosity. There will always be edge cases
that require special handling. Where I take issue with Java is that
normal, run-of-the-garden case often require verbosity. A bit here, a
bit there: it adds up to a tangle.

In the preprocessor that I was working on, an if condition ended
up taking quite a bit of screen width. I added a method so it would
simplify this. In many other languages, all I would have to have
written was something like:
if (cParsedWord=="$define")
Instead, I had to write:
if (cParsedWord.equals("$define"))
Without that method, it was something like:
if (cParsedWord.Value.toString().equals("$define"))
The method that hid the verbiage was in this class:
VRStringB
(
StringBuilder Init
)
{
this.Value=Init;
}

boolean equals
(
String theString
)
{
return this.Value.toString().equals(theString);
}

void Set
(
String theString
)
{
this.Value.replace(0,this.Value.length(),theString);
}
}
And I had that class in the first place, because Java does not have
call-by-reference.

Death by a thousand cuts.

[snip]

Sincerely,

Gene Wirchenko

 

[markspace]

written was something like:
if (cParsedWord=="$define")
Instead, I had to write:
if (cParsedWord.equals("$define"))
Without that method, it was something like:
if (cParsedWord.Value.toString().equals("$define"))

In all honesty, I prefer the last one. At least I can see what is going
on, and I don't think it is long at all. There are plenty of good
examples where Java is verbose. This isn't one of them.

And overriding "equals" in this way is pernicious.


[[Snipped a lot of very nasty source code]]

void Set
(
String theString
)
{
this.Value.replace(0,this.Value.length(),theString);
}
}

Death by a thousand cuts.

If you're referring to whomever invented that source formatting style,
then yeah, it's grody. But that's not Java's fault.

 

[Gene Wirchenko]

In all honesty, I prefer the last one. At least I can see what is going
on, and I don't think it is long at all. There are plenty of good
examples where Java is verbose. This isn't one of them.

Um, the condition is twice the length of other languages'
equivalents.

And overriding "equals" in this way is pernicious.

Why? I was checking for equality.

[snip]

Sincerely,

Gene Wirchenko

 

[Andreas Leitgeb]

Conciseness is overrated.

It surely is in languages like Perl.

It is underrated in many other languages,
and it was much underrated in Java up to 1.4

 

[Roedy Green]

Conciseness is overrated

What sort of apps do you write? Over my lifetime I have done a bit of
everything from device drivers, to a Forth engine, to new methods of
solving differential equations to online banking. That experience
gives me a right to an opinion about how Java fits into the overall
scheme of things.

I have talked with Bill Joy and watched Mr. Gosling lecture. I think I
understand what makes them tick. They are both very intelligent people
who have no interest whatsoever in process of cranking out guis.

 

[Arved Sandstrom]

What sort of apps do you write? Over my lifetime I have done a bit of
everything from device drivers, to a Forth engine, to new methods of
solving differential equations to online banking. That experience
gives me a right to an opinion about how Java fits into the overall
scheme of things.

I have talked with Bill Joy and watched Mr. Gosling lecture. I think I
understand what makes them tick. They are both very intelligent people
who have no interest whatsoever in process of cranking out guis.

Yeah, but that last phrase in that last sentence is not the same thing
as your assertion that "application programmers crank out reams and
reams of twaddle". Or for that matter, your related statement that
"People who write system code think a long time and produce a small
number of carefully-chosen keystrokes, overwhelmingly comments".

"Cranking out guis" != application programming. And it sounds like
you've got an obsolete and somewhat quaint picture of system programming.

As an example of software that most definitely doesn't fit your
worldview, try most anything by James Clark, including groff, and highly
influential XML and SGML parsers. Hint: none of these are systems software.

AHS
--
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

 

[Lew]

What sort of apps do you write? Over my lifetime I have done a bit of

Everything imaginable over the years, from device drivers to web apps to enterprise apps to desktop apps to GUI-driven apps to middleware to back-end components to Android mobile apps. FORTRAN, assembler, C, C++, SQL, Java and others for programming languages, plus a fair amount of things like shell, Perl, Javascript and such for scripting. (I forbear to mention JCL.) Mainframes, minicomputers, PCs, mobile, embedded. Big shops, solo programmer, government agencies, private businesses.

everything from device drivers, to a Forth engine, to new methods of

I haven't written a Forth engine but I've written some toy Forth programs.

solving differential equations to online banking. That experience

Similar. I've worked on scientific, financial, health-care, government andprivate-industry apps.

gives me a right to an opinion about how Java fits into the overall
scheme of things.

Yes, it would do that. And ...?

We all have the right to an opinion about how Java fits into the overall scheme of things, even those of us with minimal experience. The question is whether our opinion has merit.

Yours does, AFAICT.

My experience is also quite extensive.

I have talked with Bill Joy and watched Mr. Gosling lecture. I think I
understand what makes them tick. They are both very intelligent people
who have no interest whatsoever in process of cranking out guis.

So?

I'm sorry, Roedy, but how does all this tie in to this discussion?

 

[Robert Klemme]

Folks,

we recently had this discussion about the benefits of STC: Groovy now
takes a hybrid approach and allows to use both. For the interested
reader:

http://www.jroller.com/melix/entry/groovy_static_type_checker_status

They are trying to have the best of both worlds.

Interesting: the discussion solely seems to revolve around the "better
syntax" quote and nobody talks about the hybrid type checking approach.
It's always fun to see how threads evolve in totally unexpected
directions.

Kind regards

robert