Re: GoTo in Java



"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:drbib30gt6@xxxxxxxxxxxxxxxxxxxx
>
> In article <S9SBf.194761$OU5.25957@clgrps13>, "Oliver Wong"
> <owong@xxxxxxxxxxxxxx> writes:
>
>> Availability of software would no longer be a problem or factor in OS
>> selection.
>
> This seems rather optimistic. We've had this technology for decades.
> Software availability isn't a technological problem; it's one of
> marketing and consumer perception.

I don't know about the rest of the world, but in my experience, and in
the experience of my close relatives, the most important factor to OS
selection is availability of software.

My mom is a (natural language) translator who occasionally works from
home. She wants Microsoft Word on her home computer. She doesn't want *a*
word processor, she wants that specific one. Why? Because that's what her
company uses internally, and they make use of the more obscure features. If
OpenOffice (or some similar suite) opens an MS word file sent by her
employer, and silently ignores sections it doesn't understand (e.g. editor's
annotations), then she can't do her job properly.

My younger brother wants to play Star Wars Knights of the Old Republic,
Beyond Good And Evil, etc. He doesn't want to play, e.g. solitaire,
minesweeper. WineX's DirectX emulation is spotty at best. Yeah, there are
"good" games for Linux, like perhaps Unreal Tournament. But he doesn't want
to play Unreal Tournament; he wants to play the Star Wars game.

>
>> The source code within a single file (or "compilational unit") could
>> be
>> written in a dozen different programming languages, and with a
>> sufficiently
>> smart IDE, you could just highlight any block of code and translate it to
>> the language of your choice.
>
> Compilation loses information. Decompilation can't put it back.
> While you can decompile MSIL into C# and other .NET languages, you
> aren't restoring everything that was in the source - you can't,
> because MSIL doesn't capture everything that was in the source.

[this next paragraph appeared later in Michael's post, but I'm moving it up
here to address this and the previous paragraph at the same time]

> And if this hypothetical system did encapsulate enough information
> from the source code to make this plausible (which would have to
> include, say, identifier names, and comments, and such), you'd have
> intellectual property issues. There's already plenty of concern in
> the software industry over decompilation of high-information formats
> like Java bytecode and MSIL - that's why there's a healthy market
> for obfuscators.

Agreed, and I realized what I had proposed is difficult and has been
tried before. I know I implied otherwise in my original post (I had fully
formulated the idea in my head), but there's no reason why the IDE couldn't
target two or more target languages.

What I mean is that, when you actually have the source code file in
front of you (e.g. written in 12 different languages), you have ALL the
information there. The comments, identifier names, etc. are all present in
that file. The IDE could then compile this to an IL specifically designed to
be "easy to translate" when using the "View as Java..." feature.

Later on, when you plan on actually releasing the software to the
public, the IDE would then compile it to a different IL, or to native
binary, stripping all comment and identifier data.

I suppose architectural-design wise, you'd have some language neutral
IDE/platform (e.g. Eclipse), and you'd have language-specific plugins that
would provide the facilities for syntax highlighting, compiling to
translatable-IL and publishable-IL, and decompiling from translatable-IL.
You'd then have plugins that would provide facilities for compiling from
publishable-ILs to Java Bytecode, MSIL, win32/x86 binaries, etc.

>
>> You could write your simple OCaml code, and me, not being an OCaml
>> guy,
>> would highlight it, right click, and choose "View as Java", say to myself
>> "Oh... so that's what this does..." and change it back and continue
>> coding
>> some other part of the system.
>
> I think you overestimate the ability of the average programmer, or
> for that matter the exceptional programmer, to interpret arbitrary
> chunks of decompiled code. There is considerable literature on the
> subject (or at least on "intelligent" decompilation), and it's not
> what I would call encouraging.

Agreed again, though I'd probably have an easier time (in the short run)
deciphering the decompiled Java than the OCaml code, especially if the IDE
also provides the the tools to refactor the decompiled Java code into
something more readable, while helping me guarantee that I'm not changing
any of the behaviour of the program. In the long run, obviously, it's much
better for me to actually learn OCaml, but then again, perhaps this
automated translation can assist me in learning OCaml so that once I've
translated enough of it to Java, I can start having a basic level of reading
comprehension.

- Oliver


.