Re: GoTo in Java


"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:1138390683.396793.322920@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Someone else then translates it to
>> C++. Then I come back, and notice there's a C++ version now. I tell my
>> IDE
>> to translate it to Java, and get something not too bad. I can clean it up
>> a
>> bit, and add it to the docs too.
>
> While that mechanism may be a nice toy for learning different languages
> it would be useless for production code. Who is going to ensure that
> your 'cleaned up' Java now works the same as the Fortran code. If a
> change is made to the C++ how does the Java get the same change.
>
> In may examples what is the Java equivalent of 'for record in file:' ?
> It is several lines of class methods and a while loop. If the Java is
> modified then how could it ever get back to being just the one line ?
>
> Source code translations have been tried for several decades and they
> just don't work. For example you cannot translate C code into Java and
> expect it to magically become object orientated.

I guess I'm assuming an ideal situation where public interfaces will
never be modified. Since it is documented, presumably the function written
in some language as part of some library is part of the public interface of
that library. That means that its behaviour should never change, what kind
of arguments it expects should never change, what values it returns should
never change, etc.

I'm hoping that in practice, changes to the public API will be rare, so
that the few times that the behaviour/input/output does change, the person
commiting that change to the shared source code repository will just delete
all the documentation (since (s)he cannot be expected to be familiar enough
with all programming languages to ensure that the documentation for each
language is still accurate).

As long as the "example usage" rely only on the documented behaviour,
and then the Java example doesn't actually have to do the same thing as the
C++ example, as long as it gives a typical usage of the function being
documented.

I'm not saying this source code translation tool should be used to take
a perfectly good C program, turn it into Java, and then compile the Java and
run it. That's pointless, as you could just compile the C program directly
and run that. I'm focusing more on its usage as a documentation and code
comprehension tool. I fleshed the idea out in a responce to Michael Wojcik's
post in which I mention two Intermediate Languages. I guess I'll invent two
new terms to help distinguish between the two ILs involved.

Executable Intermediate Language, or EIL, is the IL designed to have
good runtime performance. The "front-end" compilers for various languages
will heavily optimize the EIL, potentially making it indecipherable to human
readers, and mangling variable names, unroll loops, inline function calls,
and generally just completely destroy the original structure of the program.
Then "back-end" compilers can translate EIL to Java Bytecode, MSIL, or
native win32/x86 binaries, for example.

Documentary Intermediate Language, or DIL, is the IL designed to be easy
to translate. The "front-end" compilers will try to preserve as much
semantic and structural information as possible in DIL. The DIL, for
example, will have a way to preserve comments in the original source code.
DIL will be what's processed for translating source code from one
programming language to another.

.NET is a big step towards the system I'm thinking, where everyone
writes code in whatever language they are most familiar with, and it all
compiles to MSIL and can inter-operate cleanly. MSIL could be the EIL I
mentioned earlier. AFAIK, there is nothing like a DIL in the .NET platform
(or any other platform that I know of either).

I was working on a project where I had some ASP.NET code interfacing
with COBOL. The code I had kept on silently failing (basically the IIS
server was giving that "Internal Error" message), and documentation on the
library we were using was sparse (it was Transoft TGA,
http://www.transoft.com/platforms/hp_homestead.htm).

I got a .NET introspection tool and opened up the Transoft .NET classes,
and decompiled them to C#. After doing some manual tracing through the code,
the problem was discovered and fix (this was a while ago, so I don't
remember all the details).

It would have been nice if this introspection tool was actually part of
the IDE (Visual Studio) in this case, so that I could step through it in the
debugger, instead of "playing computer" and computing all the values of all
the variables in my head or on paper.

Maybe Transoft actually did write TGA in C#. Or maybe they wrote it in
VB.NET, or COBOL.NET. It didn't matter, as my tool could decompile it to C#
(with meaningless local variable names), and that was a BIG help in getting
me to understand how the library worked.

The above was accomplished with only EIL. The process could have been
made much easier, and the tools much more powerful and smarter if the "DIL"
concept existed too.

If I could do this for ALL source code, then that'd be great. I could
actually contribute code to my favorite open source programs that aren't
written in Java. I decompile (via DIL) their code into Java to get an idea
of how it works, and then write my additional modules in Java, and send it
in. They'd then combine my Java with their C++ code (or whatever language
they're using), which would ideally be trivial since they're all compiled to
the same EIL anyway.

The idea is to increase interoperability of programming languages. EIL,
which already exist (Java and .NET), allows computers to "understand"
programs written in different languages, but it doesn't help *humans*
understand programs written in different languages. That's what DIL is for.

- Oliver


.

Relevant Pages

  • Re: Head-in-the-Sand Liberals (LA Times Columnist)
    ... You claimed to have known several computer languages, ... If you lie about knowing computer languages, ... of the programming loop for a functional ... You also don't know Java. ...
    (rec.org.mensa)
  • Re: How come Ada isnt more popular?
    ... Most programming languages were terrible at that time, ... And we talked about "Why isn't Ada more popular?". ... Adopting Java ...
    (comp.lang.ada)
  • Re: performance question
    ... that let me mix different programming styles more freely. ... When I started learning Java, my biggest problem was that I ... I've noticed that people often prefer to take shortcuts when writing code - ... deficiencies in the model and/or the existing languages that implement ...
    (comp.lang.java.programmer)
  • Re: Bloody Java again
    ... I passed my Java exams last year but really have ... Erlang's concurrent programming is rather abstract and high-level. ... He is not being asked to grade umpteenth different languages. ... Student: "It's all in the program, ...
    (comp.lang.functional)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... >>A few years ago I started learning Smalltalk. ... >>features in alternative languages. ... > know that there is widespread ignorance about programming language features ... eiffel developers even though the type system in eiffel is superior to Java. ...
    (comp.object)