RE: accumulator generator (Java)

["Anton van Straaten" <address@hidden>]

> Did you discover this in the process of performing
> this experiment or in something else (I'd imagine
> something else, but I'm curious to hear it from you).

Something else.  When I first came across anonymous inner classes in Java, I
experimented with them for a variety of things, such as for example wrapping
database transactions:

	new my.Transaction() {
		protected Object body() throws Exception {
			// logic for specific transaction goes here
		}
	}.run();

...which allows centralizing of common behavior like for example transaction
begin/commit/rollback, exception handling, and logging, which otherwise must
be repeated and scattered throughout a program.  However, access to the
enclosing closure is so restrictive that it's difficult to write this kind
of code in real life without continually bumping into the restrictions.  I
came across the Jikes anomaly when code that I had written, which worked
fine, wouldn't build under the Sun compiler.

> Which makes me wonder about the ever-present push to get generics
> in Java. I tend to think generics are a Good Thing, but if the
> object approach is the most innate, how would generics have to
> be implemented to be seen as a universal boon that didn't upset
> Java programmers?

I don't think generics are at odds with Java at all - in fact, it sorely
needs them, IMO.  I first recall investigating Pizza
(http://pizzacompiler.sourceforge.net/) in 1997, and thinking that it made
so much sense, it was only a matter of time before it made it into core
Java - 5 years maybe?  Ah, the optimism of youth! :)

I'd argue that without generics, Java is not as Java-like as it could or
should be, since its static typing, which is such a strong feature of the
rest of the language, can't be applied to e.g. elements of collections.
Lack of generics also leads to the need for lots of repetitive boiler-plate
code to handle different data types.  Addressing those kind of things via
generics could fit right into Java without requiring much change in paradigm
or mindset, although as a side-effect, a paradigm change would become
possible.

If one argues that Java should be deliberately restrictive in order to
reduce the possible complexity of code written in it, then I can see an
argument against generics.  I don't really buy that argument, but I can see
the point if one is targeting corporate programmers who are most comfortable
when cranking out boilerplate code, and who prefer to implement something
the long way around because they can more easily conceive and grasp it.  But
that results in less flexible systems and puts upper bounds on the degree of
complexity that can practically be addressed by such systems.  Of course,
this may be acceptable for that market.

> This, of course, gets back to the idea that each language has
> it's own feel and that idioms and practices from other languages
> don't necessarily translate, a la the Python v. Lisp thread.

Although non-applicability of idioms across languages is very common, it's
easy to put things into that category incorrectly.  As has just been pointed
out, for example, "reduce" can apparently be used quite elegantly in Python,
so the fact that most current Python users don't use it probably reflects
their preferences, knowledge, and the language's history much more than
anything innate to the current design of the language.

> SICP has a similar point, in that you construct an object system out of
> closures. I look at closures being more generic than objects, whereas
> objects have very specific properties. I suppose it depends on what I'm
> doing and what I'm doing it with at the time that would determine whether
> or not I found my objects as lame closures or closures as lame objects.
> I tend to feel that, between the two, I would rather have real closures,
> and if necessary, I'll build my own object system thank-you-very-much
> over having to be constrained in an "objects only" universe. But then,
> I still liking hacking in Smalltalk for fun sometimes.

I agree on preferring real closures, and I say that as someone who learned
and used objects (and even designed part of a commercial OO language) long
before ever encountering closures.  But I think one of the appeals of
closures is that they are more atomic, and better suited to low-level
construction of whatever it is that you want to construct.  Aside from the
fact that a native object system may have certain benefits in terms of
language integration and performance, most people don't want to have to
construct their own object system, and don't feel as though they need the
ability to pick between alternative object systems, or embed sublanguages in
the language they're using.  They like having their choices narrowed
somewhat - which goes back to what I said about Java above.

The flip side of this exact issue inhibits the commercial prospects of a
language like Scheme (which of course wasn't exactly intended as a
commercial language) - in real Scheme implementations, there are too many
competing object systems, with no standard, and the only widely adhered to
language standard (RnRS) is so wonderfully open as to guarantee that no two
language implementors will ever agree on anything...  :)

This all ties closely into PaulG's latest succinctness=power message.  Yes,
succinctness=power, but there are clearly cases where one wants to
deliberately limit power, for all sorts of reasons.  A good trick would be
to provide the desired power in a way that's sufficiently controllable for
users who want to impose certain kinds of limitations be able to do so,
without preventing users who want more freedom from having that.

> On a completely different note, has anyone else seen the work
> Chris Double has been doing with GOO (nee Proto) and .NET?
> <http://radio.weblogs.com/0102385/>

I hadn't, so thanks!

Anton