[Fenfire-dev] Why (Java) interfaces matter

[Benja Fallenstein]

Hi all,

This mail is only very distantly related to Fenfire, but I don't know
where else to discuss this, so I'm sending it here. ;-) This is really
about programming language design, although there's a small
implication for FF here.

Python doesn't, currently, have interfaces (although Guido van Rossum
is actually pondering to add them in one of the next versions). At the
face of it, this seems quite in line with the Pythonic ideal not to
make you write unnecessary stuff; after all, interfaces don't *do*
anything by definition, and in Python with its duck typing (you can
call .foo() on anything, and only if the object at runtime won't have
that method will this raise an error), you don't need interfaces at
all.

Still, after having developed a lot in Java, when I went to code some
stuff in Python I noticed I was really missing interfaces, even though
I usually love Python and hate Java because it makes me type all that
unnecessary code, unlike Py. So how come I was missing interfaces?

Thinking about it, it turns out that the reason is that by writing
interfaces first, I can start to figure out the design of a module
before filling in all the details. The interfaces always evolve during
implementation, but I can *start* the design by taking a first cut at
the interfaces.

This matches with the thing that many people say, that languages
should be good tools for thinking in.

Now, with Python, I could of course open emacs and take some free-form
notes to the same effect. The main reason that I prefer to write a
Java interface to taking notes is, I think, that it makes me feel more
productive. That's because when writing the free-form notes, I feel
like I could just jump into writing the code and save time, but when
I'm writing an interface I'm doing something I actually *have* to do.

This reason is probably a bad one. If I have already figured out
things in enough detail that I can start writing the implementation,
I'm just wasting time when writing the interface. If I haven't, it
would seem that taking free-form notes is no less productive than
writing the Java interface.

However, there are two better reasons that Java interfaces are good.

First, they are more formal. This means that they produce (force) more
exact thinking than free-form notes. At the point where the design has
become clear enough to write interfaces, but not yet clear enough to
implement, the formality forced by interfaces is useful to make the
become even clearer.

Second, they are understood by the compiler. When writing something
that the compiler doesn't understand, I feel much less useful than
when writing something that it does understand, at least for formal
stuff. The compiler understanding what you're writing actually has two
distinct benefits in itself: First, it can *check* what you've
written, and second, it can do stuff with it.

There are ways to annotate your Java source code with formal
descriptions specifying what methods do, but the compiler doesn't
understand them, so it neither checks them nor does anything useful
with them. That is, I suppose, why I don't put such annotations in
(more precisely, why I see no reason to put them in).

Now the point I'm driving to is not to say, "interfaces are good,
every language should have them." Rather, it is a general point about
language design: Languages are for humans to think in, not just for
computers to execute. Therefore, it is good if a language supports the
thinking process at the stage before the design has crystallized
enough to implement it. However, language constructs are only of
interest if the computer can "understand" them -- check them, and
preferably do something based on them.

Therefore, a goal in language design could be to find more and more
abstract, but formal, specifications that can be given at earlier and
earlier points in the process of designing a program -- i.e., with
less and less knowledge about how the program is actually going to
work.

I think formal specifications can be one interesting way to do this.
They allow you to specify what an algorithm should do before figuring
out how it will do it, and after you have written the algorithm you
can prove that it actually has the intended behavior, which will allow
you to be sure that it is bug-free even if you don't understand it
100% (it isn't that unusual for me to write an involved algorithm
without understanding it 100%), so they are actually *useful*.

Formal specifications are a great example of something that the
language doesn't need to force you to write, but that can be very
useful if you in fact do happen to write it.

I don't think that formal specifications are the only thing to think
about here, though; I think their value is probably more for designing
the small (designing individual methods, not designing complete
applications), and you already have to have thought out things in
quite a lot of detail before you use them. So I think it's worth
thinking about things that could be applied earlier in the design
process.

The relation to Fenfire is that it should be a tool / contain tools
for refining hazy ideas to detailed ones.

The End.

- Benja