Re: Ada to C Translator

["Frode Tennebø" <frodet@nvg.org>]

Robert Dewar wrote:

> In article <alpl29.aph.ln@leia>,
>   Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> 
> > I'm not sure what type of application you have, however 15
> > years ago  there were a lot fewer languages than today.
> 
> That seems clearly false. What is your authority for this
> statement/guess. Perhaps you mean that there are fewer
> languages with which you are familiar (given the rest of
> the message that seems a possibility).

MMmmmm....not. If you take the languages you had 15 years ago, add up 
the numbers of languages invented in the last 15 years, you get more 
languages today than 15 years ago. :)

> > How many of those languages are alive today?
> 
> Virtually all of them. Nothing is more discouraging than seeing
> supposedly knowledgable Ada folks decide with no evidence that
> other languages have disappeared from sight. It is indeed a
> common malady to assume that any language you do not bump into
> every day has disappeared (for example, I often meet people who
> think that PL/1 has disappeared). But surely Ada folks should
> try to avoid this mistake, of all people!

I realise that this was a rather misleading statement and you are of 
course totally correct, Robert. But, let me rephrase the statement:
Of all the languages available for general programming, which ones 
would these older than say, 5 years, would you choose for a current 
programming task?

There will always exist code for any language ever conceived, but is it 
practical to select PL/1 now if you are considering ports to both Linux 
and Windows?

> 
> > Can you get an actively maintained compiler for Cobol on a
> > modern platform?
> 
> A staggeringly ignorant question :-) Yes, of COURSE you can,
> and the amount of legacy COBOL out there is huge. Furthermore,
> new applications are being generated in COBOL all the time
> (that should not be surprising, COBOL is still the most
> suitable language for fiscal applications -- yes, you can make
> a reasonable technical argument for Ada-95, but most of the
> people making language decisions assume that Ada has
> disappeared -- see paragraph one above). As for active
> maintenance, yes, there are certainly active COBOL compiler
> maintenance groups around (e.g. for Computer Associates Realia
> COBOL for IBM PC's, or don't these count as modern platforms in
> your lexicon? :-)

IBM PC's modern? Let me think... :)

Well, again it I spoke before I thought. COBOL might very well be the 
one language with most lines (or whatever unit one counts) in 
existance, but I was not aware of efforts to maintain it. I was not 
aware of IBM's effort here. I should have research more - will I learn? 
I DID learned of: http://cobolforgcc.sourceforge.net/ which looks 
rather cool. :)

> 
> > What about Forth?
> 
> Again, just because you do not bump into it every day, does not
> mean it is dead, especially when you have made ZERO attempt to
> find out facts. Of *course* Forth is alive and well, and is
> used in many applications areas. There is by the way a VERY
> nice Forth interpretor for the Palm Pilot, which has been used
> to generate a number of Palm applications.

http://www.forth.org/ - say no more.

> 
> > The only laguage I can think of other than Ada and C which
> > has a active compiler support is Fortran - even Pascal is
> > struggeling.
> 
> Again, the lack of awareness in this statement is remarkably
> parochial -- even peculiar, given its inclusion of Ada as one
> of three languages still in use -- that would surprise a LOT of
> people:-) There are hundreds of languages for which there is
> active compiler support, and active application communities,
> especially if you use Ada as a standard for what these terms
> mean!

*sigh*

modula2/3, rexx, pascal, basic, etc.....I'm ashamed. 
*Argh* Can I please delete my previous posting? Does the time of 
posting give ANY leniancy? :)

> By far the most widely used language for PC development is
> Visual Basic (although almost never taught in universities,
> contrary to other claims you made). And for sure there will
> be compiler support for this for a long long time.

Perhaps not in Universities in the US, but certainly VB is tought in 
colleges both in the US (I believe) and here in Norway. However, 
compiler support is limited to ONE vendor and one (set of) platform.

> 
> > My point is that with Ada, you will most likely get a
> > maintained compiler for a current platform in 15 years. Will
> > this be true for C++?
> 
> Yes, of course it will. Ada advocacy is not helped by FUD like
> this which is clearly unfounded. I agree that Ada compilers
> will be maintained for 15 years, but that is because I know the
> business strategy and plans of Ada Core Technologies. The fact
> of the matter is that in terms of future maintenance of
> compilers, C++ is in a VERY secure position (as is COBOL
> incidentally :-)

I would guess that COBOL is more so than C++. The way C++ compilers 
refuses to cooperate with each other and the way standards seems to be 
broken gives me a rather dim view on the survival of C++. My own 
experiences with Sun C++ (various version), egcs, gcc and various 
libaries which refuses to compile code the other compiler excepts, etc. 
It's a jungle out there....

However, I do agree that FUD is not helping any case anywhere. And I 
was not intensionally trying to spread FUD, even though in retrospect 
it might have been perceived as such.

> 
> > Also, you are switching to NT 4 NOW? NT has already reached
> > EOL.
> 
> Again, that is unsupported FUD. I am the last person to write
> strong words of support for NT, but to say that NT has reached
> end of life is absurd.

True, I can't support it by hard facts (how do one present personal 
opinions about anything without it becoming FUD)? MS will never 
publicly discontinue such a high-volume product!

However, juging by the rather abrupt lack of support from MS on NT 
issues, the lack of updated drivers and new drivers for new hardware 
for NT - again, this is a personal opinion based on perosnal experieces 
(take a look at ATI Radeon VE, MS Media Player, etc) - and the way MS 
previously has dealt with 'technology changes', ie. the rather abrupt 
termination of MS DOS, Windows 3, NT 3.51 and W95 for that matter, 
leads me to deduce that this will also be the case for NT4.

If I were to move to any MS platform now (heaven forbids!) NT4 would 
not be a preferred choice for myself.

> 
> > If  you had written any legacy application with C++ on
> > Windows 3.11 five  years ago - how easy would it be to port
> > it to any platform today?
> 
> It would vary on how well it was written, because you were
> using a non-standardized language, still in flux, on an
> obsolescent operating system, yes, you may have more troubles,
> but the difficulty in porting programs is often more related to
> quality of code than operating environment.

Quality of code is a very important factor, but the lack of standards 
(including OS calls, graphics libraries AND programming language) 
should not be dismissed.

> 
> > How about in 10 years?
> 
> I don't think it would be any harder to do this port ten
> years from now than now, probably easier, because more tools
> will be around to help.

I dissagree. I don't believe relevant tools will be available for any 
15 year old technology. Technology change, and those responsible for 
the change are very often more focused on the change itself than the 
implication it has for the past or the future.

I'm speaking from experience. Working for a company with a high 
level of old technology, I see on a regular basis that we have to open 
back-doors, perform compromsises or otherwise do some black magic to 
allow for upgrades of legacy software. The only time this went rather 
smoothly was with Ada.

In '85 I wrote a rather simple, but lengthy script (then it would be 
called a program :) in MS DOS batch language using ED. I'm sure I can 
find a 5.25" drive, load the file and edit it somewhere. But how do I 
port it to run on NT? I wont! I'll write it from scratch.

Just think about the trouble I would be in if you had the entire set of 
source code on 8" floppies. :)

> 
> Of course I agree that porting Ada code to C++ just for the
> sake of porting it seldom makes sense, but let's try to keep
> the arguments real. Ada advocacy is not helped by extreme
> statements about other languages that are insupportable.

I'll put my act together.

> 
> > However, I would get your application running on an older
> > version of GNAT for DOS
> 
> That seems a poor suggestion, this is a bad environment for the
> port, and will make the job much harder (I speak from the point
> of view of our experience in helping customers port millions of
> lines of legacy code to GNAT).

You are the authority here. I'm not familiar with the DOS port of GNAT 
at all. However, from experience, it usually reduces the complexity to 
do one step at a time, ie. legacy Ada/DOS -> GNAT/DOS -> GNAT/other os.
But since there is no current DOS port of GNAT, the reduction in 
complexity might (as for this case)  be outweighed by the old age.

> 
> > Depending on the cost structure of your system, a W2K license
> > can be  significant compared to eg. Linux or BSD or even
> > Solaris these days.
> 
> Indeed, and a Linux license is cheaper than a DOS license, so
> the conclusion here should be that Linux is an obvious target.
> It also supports development work much more reliably than any
> of the Microsoft operating systems in our experience.

:)

> > I performed the major part of 'porting' a 200K SLOC (sic) of
> > code from  SunAda 3 running on Solaris 2.5.1 to GNAT on
> > Solaris 8 in less than 200
> > hours.
> 
> One hour per thousand lines of code is actually rather slow
> as a porting rate from our experience, especially for a fairly
> small program (we have frequently helped with porting very
> large applications in much less time than this on an absolute
> basis, let alone a relative basis). 

*stab-in-the-hearth* Actually, half the time was spent on two 
part-systems (out of app. 30) with rather nasty circular dependencies.

> But milage can vary, we
> have at this stage a LOT of experience in such porting, which
> can make things much more efficient, and as I said earlier,
> difficulty in porting can reflect poor coding of the original
> (the big issue being whether implementation dependent and
> system dependent code is properly isolated).

Which was true (circular deps). But without the excellent Ada83->Ada95 
portability I might still have been hard at work. I might add that 
another ~200 hours were spent converting ~2000 lines of C in the same 
project, and my guess is that this will have to be redone for Linux or 
whatever.

I have great respect for all other programming languages. Ada was not 
my first (nor second or third - heck - I didn't even like it at first:) 
language, and I learned most of the others before Ada. I still program 
the occasional Basic or Pascal and enjoy it. :)

Again, no FUD was intended. And my point was to emphasise the absurdity 
of porting from a perfectly viable source for a portable Ada port to a 
entirely different language on a specific platform. The stab at the 
other languages was ill-conceived and is herby retraced (However: If 
the original platform was Fig Forth/Dos 4 I'm not so sure my advice 
would be the same. :)

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |