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've been following this thread with some interest and I understand what
Oliver is trying to do. It is a noble idea, but I think Richard has hit the
nail on the head in this (and previous) posts.

The effort involved in source transalation, and the risks, do not match the
rewards.

The point that is being missed entirely here is that the real solution is to
NOT maintain source code. (In any language...)

Because of its COBOL and procedural programming roots, this forum is excited
by language discussions and the problems attached to source languages. Yet I
see people every day, with no knowledge of ANY programming labguage (apart
from scripting, which is not maintained in the traditional sense of code
maintenance) producing really impressive applications that run on the web,
access databases, share information, and produce reports.

Component based development means you write code once and do NOT maintain
it. (I know there are many places that don't adhere to this and they try and
maintain the components. There is only marginal gain over a normal source
code maintaining shop if you do this.) The idea is to decompose
functionality to lower levels than has traditionally been the case, write
flexible generalised solutions to these low level functions then leave them
alone! All you have to do is build the components into applications. You
should never change a component once it is written and its methods, events
and properties are established. If you need to 'enhance' it write a wrapper
that interfaces to it and extends it for that specific case, or write a new
component.

The true benefits of code reuse are not gained if you keep rewriting the
code. Encapsulate functionality and reuse it. Do it once; do it right.

Fortunately, modern evironments are so component rich (even though many
people do not realise the thousands of components that are provided free
with your OS) that people are starting to simply plug things together and
achieve impressive results. Scripts do not require thousands of lines of
procedural code to achieve what WOULD require thousands of lines of
procedural code, and maintenance is not a problem.

The rule of source code is over. The future belongs to object code. It will
be developed (once :-)) in whatever language is most appropriate for it and
things like ILs and CLRs will level the playing field. I have one
application where components written in VB, C++, and PowerCOBOL all play
together nicely on a single windows screen. The user is unaware of what the
functionality is written in (and doesn't care), and I have NEVER changed
these components in any way. (I couldn't if I wanted to, because I don't
have the source for some of them...) This application has been live for
several years, has had enhancements made to it, and has had some minor
changes to its functionality. New screens have been added and some of the
components mentioned appear on the new screens as well (there is only ever
one copy of them in the system). The less source code you have to look
after, the less risk to your investment.

Maintining source code is yesterday's technology.

Having said that, I do realise that 'today' we have a huge investment in
procedural source that HAS to be maintained so I don't think this discussion
is pointless...:-)

But I also think people need to start thinking 'beyond the square'. Todays
kids are doing it. In 50 years the idea of sitting down and 'programming' a
computer line by line, will be a quaint curiosity, like us using flint tools
or speaking Latin in the Supermarket.

Pete.




.

Relevant Pages

  • Re: Something has to be tested and maintained was Re: GoTo in Java
    ... I am on record as saying that maintenance of source code is self defeating. ... every module or program when new functionality is added. ... is that a brick is a brick; it has the attributes and behaviours of a brick. ... to translate it to Java, and get something not too bad. ...
    (comp.lang.cobol)
  • Something has to be tested and maintained was Re: GoTo in Java
    ... to translate it to Java, and get something not too bad. ... Source code translations have been tried for several decades and they ... Because of its COBOL and procedural programming roots, ... Encapsulate functionality and reuse it. ...
    (comp.lang.cobol)
  • Re: OT: The Geek defense
    ... even if you don't cover the cost of development hours. ... least in Java. ... It isn't about source code and call structures; ... functionality you require is and break it into small components that can be ...
    (comp.lang.cobol)
  • Re: CLOS and databases
    ... As a lisp liking Java person, here are the points you need to address to ... metadata about packages, classes, fields, and methods, called javadoc. ... available in the MOP is stored in Java source code for compile-time ... needed to implement the functionality in Java is ...
    (comp.lang.lisp)
  • Re: Help me!! Why java is so popular
    ... He is arguing that Java performance is less than C/C++ ... No, I'm assuming it takes longer to translate a thing and run it, than ... the JVM, abc gets translated to native code and executed -- Java class ... ready to go so it's executed -- which instance of abc's execution ran ...
    (comp.lang.java.programmer)