Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Generics - Is this possible?

Reply
Thread Tools

Generics - Is this possible?

 
 
Patricia Shanahan
Guest
Posts: n/a
 
      04-22-2008
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
 
Reply With Quote
 
 
 
 
lstephen
Guest
Posts: n/a
 
      04-23-2008
>
> 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();


>
> --
> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>


Levi
 
Reply With Quote
 
 
 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-23-2008
Patricia Shanahan <(E-Mail Removed)> wrote:
> 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.


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.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-23-2008
Peter Duniho <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-23-2008
Andreas Leitgeb <(E-Mail Removed)> wrote:
> 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).

 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      04-23-2008
lstephen wrote:
>> 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();
>
>
>> --
>> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

>
> 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)

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-23-2008
Lew <(E-Mail Removed)> wrote:
> Andreas Leitgeb wrote:
>> while (state!=null) { state = state.transit(); }
>> could be just a cheap wrapper for spaghetti code.


> 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.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-23-2008
Peter Duniho <(E-Mail Removed)> wrote:
> 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.

>> 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.

> 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.

>> 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?


> 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.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-24-2008
Peter Duniho <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
generics depending on generics Soul VHDL 0 02-02-2009 09:14 AM
Can't convert a generics list of objects into a generics list ofinterfaces Juergen Berchtel Java 1 05-20-2005 02:07 PM
generics in TB valentin tihomirov VHDL 4 12-18-2003 07:04 PM
Integers only as generics? Acciduzzu VHDL 4 09-23-2003 12:45 AM
Re: Multi-dimentional arrays in components using generics Willem Oosthuizen VHDL 1 07-09-2003 12:13 PM



Advertisments