Generics - Is this possible?

[Patricia Shanahan]

Andreas Leitgeb wrote:
....

Unless we can prove, that "nice" Java is also Turing complete, it *is*
a justification, because using spaghetti code *may* be inevitable.

....

Without a specification for "nice" Java, it is, of course, impossible to
prove *anything* about it.

Here's a challenge. Specify your "nice" Java, and I'll do one of the
following:

1. Prove that "Nice" Java is Turing complete, if we ignore the
finiteness of memory and disk space.

2. Identify a java.util class that is currently implemented in Java
without depending on native code and that I claim cannot be written in
"nice" Java.

Patricia

 

[lstephen]

Why restrict that the type-in is the type-out? The method I suggested
allows the caller to specify the type-out. Maybe you want to convert a
List to a Set while applying this mapping, or visa versa.

For me, I think it's mainly a conceptual thing. If you want to map and
convert a List to a Set, that seems more appropriately represented as
two operations.

e.g., map(list, function).toSet();


Levi

 

[Andreas Leitgeb]

Without a specification for "nice" Java, it is, of course, impossible to
prove *anything* about it.

I feared/expected this question would come up some day
So what are the criteria to determine merely Java-wrapped
spaghetti code from, well, the rest.

Obviously, it's not the "switch" as such, because that could be
equivalently done with a couple of "if"s, or even by invoking
overridden methods through an interface-typed variable, to
which instances of different Implementations get assigned
as a means of state-transition. Thus, even
while (state!=null) { state = state.transit(); }
could be just a cheap wrapper for spaghetti code.

If I were to restrict the loops to "provably" terminating (or
not terminating) ones (which I had in mind, previously), then
it would no longer determine spaghett'ity but only complexity
of the implemented problem. Especially my sample spaghetti
could turn out to be provable, for some implementations
of the called methods.

How could one even make a characterization of implementations of
statemachines, without making it a trivial one like "all are".

From "http://en.wikipedia.org/wiki/Structured_programming":

" Some programs, particularly parsers and communications protocols,
" have a number of states that follow each other in a way that is
" not easily reduced to the basic structures.

I wonder, if the "not easily" refers to the process of wrapping
them in a "goto-free" language (which I'd see as rather easy, as
long as the language provides variables, unpredetermined loops
and conditionals),
or if it refers to some concept that I'm still searching for.

 

[Andreas Leitgeb]

You would have to first justify some spaghetti code as being a desirable
implementation of some goal or specification,

If spaghetti code *were* a desirable implementation, there'd not be a
reason to convert it to anything else

The question is rather why such an implementation even exists:
- it might have been written in a spaghetti language (and an
according programmer's mindset) in the first place.
(BASIC, FORTRAN, machine code, Java bytecode, ...)
- it was the "easiest" way to model some unstructured
specification, like a parser or network protocol.

What one can do about them, is to identify (as exactly as
worth the effort) all jump targets, and split the spaghetti
at those places into separate chunks.

In some cases, one can arrange these chunks as nested conditional
blocks and loops even with the restriction that no other conditions
and no other holders of state information may be used than
those in the original code)

That was my original idea of a "conversion" in contrast to
mere wrap-up.

Where such a conversion is not possible, the only way left is to
introduce new state-information that vaguely represents the
instruction pointer for the original code.
That is: emulation/wrapping of the original.

Now, all that said, I believe that the following is a fair representation
of the code you posted:

Yes it is. (further shortened just for sake of short quotations)

while (blah() || !foo() ) { while (!snarf()) {} }

Really nice: it doesn't require any extra state variables.

Translating one single example doesn't actually prove anything, except
possibly that coming up with code that's _really_ spaghettied beyond all
salvation is probably harder than one might think.

How could one tell spaghetti code that allows this kind
of conversion from other that doesn't, and does this
other kind even provably exist?

But it should at least suggest to you that even code that
look unstructured may in fact have structure after all.

Indeed, I wasn't aware it would be so easy

 

[Andreas Leitgeb]

Obviously, it's not the "switch" as such, ...

How could one even make a characterization of implementations of
statemachines, without making it a trivial one like "all are".

I now know why I failed: The restriction I had in mind wasn't
really on the resulting (Java) code, but on the structurization
itself:

If, for the conversion to "goto-free" a new explicit state-
variable is introduced that mimics the instruction pointer
in the spaghetti language, then it's wrappage, otherwise
it's structurization.

The result of a structurization may still show all signs of
statemachines or whatsoever, namely if the original spaghetti
code implemented such a machine (apart from having been
interpreted by one, e.g. the CPU).

 

[Daniel Pitts]

For me, I think it's mainly a conceptual thing. If you want to map and
convert a List to a Set, that seems more appropriately represented as
two operations.

e.g., map(list, function).toSet();


Levi

I hate to say it, but that's just not the Java way.
When programming in Python, write Python, but in Java, write Java.

I can see the usefulness of your "map" utility, but think about this...
The only way to pass in a "function" is to create a class that
implements your interface.
A for-each construct is fewer lines of code (and an easier-to-understand
construct)

 

[Andreas Leitgeb]

That is not inherently spaghetti code.

I didn't say it was. But it *could* be - not really
spaghetti code, but a cheap wrapper for it.

It seems to me that your thesis boils down to the proposition
that certain people can write lousy code in any programming style.

The proposition itself is of course true, but that
wasn't a point which I was ever trying to make, or
intended to have my points boil down to.

In the end, it's about some state-variables that can be eliminated
by proper structuring, and others whose attempt for elimination has
not been successful (or not even been tried) so far.

Pete meanwhile showed successfully the elimination of the
state-variable from my own small wrapped-spaghetti example.

 

[Andreas Leitgeb]

My point with the phrase "desirable implementation" was taking as
granted your assumption that there's a _reason_ the code is
spaghetti code.

I did address this aspect in the very next paragraph (which you didn't
quote): It might have been either historical reasons, or an utterly
unstructured specification.
Each of these reasons does not rule out the existence of a structured
solution, and still gives some reason to why a structured solution was not
originally achieved. The "incompetent programmer" is, of course, a third
possible reason, quite distinct from the former two.

And that is a perfectly reasonable solution in a language without a "goto"
statement, IMHO. I personally would prefer such a solution in any case,

So, you find your translation of my sample less attractive than my sample?
Or did I just misunderstand the alternatives you had in mind for your
preference. There surely exist even less attractive solutions than
wrapping.

I don't know the answer to the question. My only real exposure to these
kinds of questions is the book "Gödel, Escher, Bach" and it's been some 20
years since I read it.

But you do have that advantage I think I tried once, but
found myself incapable of understanding it - my thoughts just
kept drifting away, until I gave up on it.

In the real world, in practice, I have never seen spagehtti code
that _couldn't_ be converted, thus I don't worry very much about
the lack of a "goto" statement.

I do believe in a practical difference, whether such a conversion
takes an extra state-variable, or not. However, the lack of
"goto" in Java is indeed just a very minor syntactic issue.

 

[Andreas Leitgeb]

A "historical reason" doesn't justify spaghetti code. It might explain
it, but it doesn't justify it.

With this meaning of "justify", the question about existence
of justified spaghetti code is identical to the question
I posed.

You misunderstand. [...]

That's fine. I'd have been upset otherwise