Time to join the fold?

Time to join the fold?

[Mike Silva]

Sometime this year my company will embark on a bigger and better version of
their industrial controller product family.  The current product uses a 16
bit chip programmed in C (I'm the main programmer, BTW), while the next
generation will be 32 bit (not yet chosen).  While I don't know Ada, I've
lurked here for a while, and have been reading the "Ada vs C++ vs Java"
thread with great interest.  Now I feel that I would be remiss not to
investigate Ada (Ada95 specifically) as an alternative to migrating our
current C code to the new products, and have ordered some books to start
learning the language.

Now for my questions (all assuming that I determine that switching to Ada is
a good idea).  First, how long would it take me (a long-time C [and a bit of
C++] programmer) to get productive in Ada?  Second, what is the best way to
present the case to my boss?  He's open-minded, but switching to a new
language that I don't know is bound to require plenty of justification.  I
know of most of the main Ada web sites and the success stories and "why Ada"
articles they have, but I was wondering if some of you might have further
opinions and/or experiences in "converting" a project or company to Ada.
Thanks a bunch for any insights.

Mike Silva

Re: Time to join the fold?

[Tucker Taft]

Mike Silva (mjsilva@jps.net) wrote:

: ...
: Now for my questions (all assuming that I determine that switching to Ada is
: a good idea).  First, how long would it take me (a long-time C [and a bit of
: C++] programmer) to get productive in Ada?  

Not long.  If you tend to be a C programmer who writes one ".h"
file for every ".c" file, and who tries to minimize the amount of
information exposed in the .h file, then you already know the fundamental
idea of a package and a private type, with a separation between package 
spec and body.  Using packages right is really the key to using Ada,
and to some extent using appropriate modularization via .h/.c pairs
is the key to using C right.

One of the great things about Ada is that the compiler is so picky,
that it helps you learn the rules of the language more quickly.
You can make that even better by minimizing your use of predefined
numeric types like "Integer," but instead defining your own numeric 
types with the appropriate range.  Then the compiler will help more in
catching the use of the wrong type as an array index, or the wrong
type passed to a function or procedure.

: ... Second, what is the best way to
: present the case to my boss?  He's open-minded, but switching to a new
: language that I don't know is bound to require plenty of justification.  

Almost all of the Ada 95 compilers have excellent interoperability with
C.  Rather than trying to rewrite the whole thing right away, pick
a well defined abstraction (i.e. one of those .h/.c pairs), and rewrite
that in Ada.  For fun, you might want to pick one that has been a major 
source of bugs in the past.  For simplicity, pick one that has relatively
few external interface points exposed in the .h, but plenty of groddy
internal interactions in the .c.

Or pick a new abstraction associated with some particular enhancement,
and write that part in Ada, while the main part of the program is still
in C.

: I know of most of the main Ada web sites and the success stories and "why Ada"
: articles they have, but I was wondering if some of you might have further
: opinions and/or experiences in "converting" a project or company to Ada.

Start with a small piece, and work up slowly.  Try to keep track of
how many bugs are caught by the compiler, caught by run-time checks,
or left to you to track down at run-time.  I think you will be very
impressed with how few bugs make it through to the painful debugging
stage.  A remarkable percentage of mistakes, sometimes even relatively
deep "logic errors," are caught by the compiler and the compiler-generated 
run-time checks.

My usual analogy is giant slalom gates on a ski slope.  Any hacker
on skis can make it through one giant slalom gate.  But if you
start to pepper the slope with slalom gates, only a skier who has
a deeply correct approach to skiing can make it through them all.

Each compile-time and compiler-generated run-time check is trivial
in its own right, just checking that two types match, or that a value
is in some range.  But for a program to make it all the way through
all of these consistency checks, it needs to be internally consistent
and logical in a deep sense.  Otherwise it is almost certain to be
tripped up by one of these "trivial" checks.  And based on empirical
experience, a program with a bug generally gets tripped up by
one of these checks remarkably close to the source line where the
underlying flaw resides.

: Thanks a bunch for any insights.

: Mike Silva

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Time to join the fold?

[Steve Whalen]

What Tucker said... AND

From a technical management perspective, I'll try to
throw in another "dimension" to the guess work on:

    How long will it take for an experienced programmer
    coming from C or Assembler or other language 
    that does not "impose" significant type and structure 
    discipline on the programmer, to become productive in
    Ada95.

Obviously, there's no real answer: maybe a few months,
maybe never, depending on the person and support they
get (or don't get).

However, you have one important, but usually overlooked 
advantage to learning and using Ada95 effectively: 

    You already know your problem domain.

The only way I can think of to illustrate my "dimension"
is with the dreaded "hypothetical": the scenario:

    Experienced Assembly language programmers (of "equal" 
    talent/productivity) are both assigned to learn a new 
    problem domain AND a new language and implement a small 
    system (both are learning the same new problem domain, 
    one will program in C, the other Ada95).

I can almost guarantee you that the person learning C will
appear to be more productive early on in the "race" because
the compiler will not place any roadblocks in their way.

The C programmer will probably have a functioning program
before the (frustrated) Ada95 programmer has gotten the first 
program to compile.
 
However, toward the end of the "race", the Ada95 programmer
should have a (correctly) functioning SYSTEM, while the
C programmer is still debugging PROGRAMS (because of the
deep logic flaws that untyped languages tend to encourage,
or at least give you no help in finding).

From my experience, I'd say you are in a BETTER position to
switch to Ada95 than most, because you alread have a working
"program", and therefore, a thorough knowledge of your problem domain
(although as Tucker points out, you may have logic bugs you'll
discover in your current system just from trying to properly
define them to Ada95).

I'd present Ada95 to management as a way to produce a higher 
quality end product, and NOT oversell it as a way to get 
"something" functioning the fastest. Maybe another way to
say it: C will almost always win the race to get the
first "something" running, but Ada95 will win the race to 
get a stable, quality product into customers hands. 

Steve

P.S. Please note that I did not include C++ in the "early race
winning" category on purpose.  While I don't want to start another
Ada95 vs C++ war, my oveservation is that while C++ has some neat
features, I see too many projects that spin out of control because
with C++ you don't get the "mandatory benefits" that come with the
strongly typed/structured approach of Ada95, but you do get much of
the complexity/power.

To badly paraphrase a quote I once saw attributed to C++'s designer: C
makes it easy to shoot youself in the foot, C++ makes it a little
harder to shoot yourself, but when you do, you blow your whole leg off
[end of bad paraphrasing job]...

My observation from real world C++ projects (most poorly managed) is
that C++ makes it pretty easy to blow up whole city blocks, especially
when there is weak management of the system design and development
process.

In less than perfect environments, I think you still get a lot of
Ada95's benefits, often in spite of the environment. However, it IS
possible to have a management and environment so undisciplined that
I'd recommend C over Ada95 too (and for the same reasons I recommend
Ada95 over C++ "in general": fewer city blocks blown up, and the
project eventually gets done (if not done "well")).


-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Time to join the fold?

[Matthew Heaney]

"Mike Silva" <mjsilva@jps.net> writes:

> Now I feel that I would be remiss not to investigate Ada (Ada95
> specifically) as an alternative to migrating our current C code to the
> new products, and have ordered some books to start learning the
> language.

Reading books is good, but be sure to play around with the language as
you're learning it by writing and compiling toy examples.  (Or
not-so-toy examples.)  There's no substitute for just getting in there
and writing programs.

There are a couple of free compilers you can use: either GNAT or student
edition from Aonix.  

As you use the language, feel free to post here on comp.lang.ada
questions you have about the language, or the best way to do this or
that, etc.  In general, comp.lang.ada has a pretty good signal-to-noise
ratio, and you should have no trouble getting substantive answers to
your questions.

> Now for my questions (all assuming that I determine that switching to Ada is
> a good idea).  First, how long would it take me (a long-time C [and a bit of
> C++] programmer) to get productive in Ada?

In my case, I came from a Fortran background.  My first Ada programs
looked a lot like Fortran programs, because I hadn't groked the Ada
mind-set yet.  

The first reaction you'll probably have (if you're like me) is, "Damn
this language is a pain in the ass," because nothing you write will
compile right way.  There is a certain way of thinking about how to
write Ada programs (as there is in any language) that will take a few
days or weeks to master.

However, there's a huge payoff, because once you do get something to
compile, there are going to be far fewer bugs in the compiled program.
You'll spend your time adding functionality to a working program,
instead of trying to figure out why you keep dumping core.

To learn a language, I'm a big fan of just getting in there and writing
programs.  Nothing beats the interaction of programmer and compiler.
Reading books is good, because the book will answer questions you had,
and give you ideas you didn't think of.  But, you'll have those
questions and appreciate those ideas, only because you've been writing
and compiling real programs.

So you can be programming in the C subset of Ada in just a few hours.
But understand that you're not done: there's a certain way of thinking
in Ada that's different from C, and you have to make an effort to
discover what that mind-set is.  That's the thing that will take longer.

> Second, what is the best way to present the case to my boss?  He's
> open-minded, but switching to a new language that I don't know is
> bound to require plenty of justification.

You only need to say one thing: you'll save lots of money.  In the end,
it's going to be a lot cheaper for a compiler to find bugs at compile
time, than it is to pay a human to find the bug at run time.

Programming is a labor intensive activity, and any tool you can use to
reduce that labor is going to pay hansomly, because the cost of human
labor is very high.

Re: Time to join the fold?

[Tom Moran]

>The C programmer will probably have a functioning program
>before the (frustrated) Ada95 programmer has gotten the first 
>program to compile.
As a former, and still occasional, C programmer, I don't find that to
be the case.  Do you have any data?

Re: Time to join the fold?

[Tom Moran]

>However, there's a huge payoff, because once you do get something to
>compile, there are going to be far fewer bugs in the compiled program.
  I like to think of a C compiler as being like a 2nd grade teacher.
Lots of encouragement.  An Ada compiler is more like 4th grade - more
criticism, but useful criticism.  Mostly the Ada compiler catches dumb
mistakes, many of which C would have let pass, but sometimes Ada says
"you can't do this" about something basic in your approach - and on
re-thinking, you realize your approach was indeed flawed.  
>Nothing beats the interaction of programmer and compiler.
Boss and knowledgeable assistant in the case of Ada, vs C's master and
dumb slave.

Re: Time to join the fold?

[Larry Kilgallen]

In article <78abg4$cnc$1@its.hooked.net>, "Mike Silva" <mjsilva@jps.net> writes:

>                First, how long would it take me (a long-time C [and a bit of
> C++] programmer) to get productive in Ada?

That should not be a problem if you really want to learn it.
Read some of the great textbooks out there to get a feel for
programming in Ada.  When you start to think in terms of
arrays rather than pointers to arrays, for instance, you
are starting to get into the spirit of things.

>                                        Second, what is the best way to
> present the case to my boss?  He's open-minded, but switching to a new
> language that I don't know is bound to require plenty of justification.

You should be able to say:

	1) On paper, it appears Ada provides the following benefits...

	2) I have tried some sample work similar to what we do in
	   our business and my own experiments show Ada is the best
	   choice.

If you cannot answer "yes" to number 2 (for whatever reason),
then you should not make a change based just on the internet
comments of a bunch of zealots :-).

Larry Kilgallen

Re: Time to join the fold?

[Steve Whalen]

Tom Moran <tmoran@bix.com> wrote:
: >The C programmer will probably have a functioning program
: >before the (frustrated) Ada95 programmer has gotten the first 
: >program to compile.
: As a former, and still occasional, C programmer, I don't find that to
: be the case.  Do you have any data?

I'm not sure I understand the question. I was talking about
experienced programmers, with NO Ada or C experience, using C or Ada
for the first time on a real, non-trivial project.

My "data" is annecdotes from others and my own experience (both as a
programmer and project manager).

Over the years, I've had at least half a dozen competent assembler
programmers work on projects where they had to learn and use C.  They
all got non-trivial programs running in a few days. Most were still
trying to get "sub-systems" debugged a few months later (especially in
the days before our modern debuggers).

I've had a similar number of competent assembler programmers starting
on Pascal or Ada projects who were still bitching about just getting
programs to compile a week or two later.  However, they had rock solid
"sub-systems" a few months later.

Of course the people and problem domains were not as direct a test as
my hypothetical, but assembler (and frequently C) programmers
(including me) don't seem to really think about data structure and its
impact on system structure very deeply until a strongly typed language
starts making them work harder to get the data structures right,
before any serious procedural code is written.

I think the order in which we learn languages IS an important
influence on how we think as programmers and system designers.  I
think whoever said that any programmer who learned Basic early had
their mind turn to mush, and was useless as a programmer after that,
overstated the case, but only by a little bit. To confess my own bias:
the order in which I made serious use of languages (and got paid for
it) was: Assembler to COBOL to Pascal to C to Ada to C++ to Perl
(skipping other lesser known or less used languages like TAL or Mumps
or RPG, etc.).  I've learned something from all the languages, but I
learned most about high quality, reliable programming from the
strongly typed languages (Pascal & Ada in particular).

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Time to join the fold?

[Tom Moran]

>I was talking about
>experienced programmers, with NO Ada or C experience, using C or Ada
>for the first time on a real, non-trivial project.
Ah, I thought you were talking about programmers experienced in the
language, presented with a new project.
  It was a long time ago, but I vaguely recall C as being difficult to
learn - "if" statements with semicolons as statement
separators/terminators, pointers instead of arrays etc.  I came then
from an Algol/Fortran/COBOL/asm background.

Re: Time to join the fold?

[Mike Silva]

I want to thank everybody who has responded to my questions, both here and
in private.  Your comments have been quite interesting and helpful.  I spent
the weekend perusing "Ada95 for C and C++ Programmers" and "Concurrency in
Ada" (others are also on the way) and my head is naturally swimming.  FWIW
here are some of my very early impressions:

- Ada is wordy.  Luckily I'm a touch typist <g>.  However, I recognize that
I sometimes get myself into trouble in C because it *is* so easy to write a
quick function, and then another, and then...  Presumably the Ada
requirement (as I perceive it) to "spell it all out" helps encourage "think
twice, write once" programming.

- Ada is powerful.  As I read along I found myself consistently thinking "C
is more versatile here", only to learn on the next page that Ada, perhaps
via one of the libraries, has multiple ways to do it, some of which are more
powerful than the the equivalent C mechanisms.  Which leads to

- Ada is big.  This is intimidating, but more than that I feel like I've
entered a very large candy store.  It appears that there are functions (in
the broad sense), somewhere in the core language or one of the standard
libraries, to do *anything*.  I get the sense of a *very* well thought out
and self-contained universe.  The concurrency facilities, to choose just one
example out of many, seem quite exciting.

Now for another question.  Some people have mentioned getting into the Ada
"mind-set".  What are the main components of this mind-set?  What, IOW,
should I pay special attention to in order to avoid simply writing "C in
Ada" (whatever that might mean).  Thanks again for the help.

Mike Silva

Re: Time to join the fold?

[Pat Rogers]

Mike Silva wrote in message <78i8s4$hth$1@its.hooked.net>...
>I want to thank everybody who has responded to my questions, both
here and
>in private.  Your comments have been quite interesting and helpful.
I spent
>the weekend perusing "Ada95 for C and C++ Programmers" and
"Concurrency in
>Ada" (others are also on the way) and my head is naturally swimming.
FWIW
>here are some of my very early impressions:
>
>- Ada is wordy.  Luckily I'm a touch typist <g>.  However, I
recognize that
>I sometimes get myself into trouble in C because it *is* so easy to
write a
>quick function, and then another, and then...  Presumably the Ada
>requirement (as I perceive it) to "spell it all out" helps encourage
"think
>twice, write once" programming.

Ada plays to the economic reality: programs are read (many) more times
than they are written.  Hence, the syntax supports the reader more
than the writer.  You'll play both parts, and appreciate it when in
the former role.

<snip>

>Now for another question.  Some people have mentioned getting into
the Ada
>"mind-set".  What are the main components of this mind-set?  What,
IOW,
>should I pay special attention to in order to avoid simply writing "C
in
>Ada" (whatever that might mean).  Thanks again for the help.


IMHO, the essence of Ada is support for Abstract Data Types.
Understand Ada's direct support for ADTs and you will have the bulk of
the sequential part of the language (including OOP).  That is what
somebody else (IIRC it was Tucker) meant when they answered that you
would get up to speed quickly if you already used your .h files to
hide implementation details in C.  ADT support encompasses packages,
private types, exceptions, subprograms... and really, the tasking
types too.  Get that and you will be a good Ada programmer.


---
Pat Rogers                          Training & Development in:
http://www.classwide.com    Deadline Schedulability Analysis
progers@acm.org                 Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: Time to join the fold?

[dennison]

In article <78i8s4$hth$1@its.hooked.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:

> Now for another question.  Some people have mentioned getting into the Ada
> "mind-set".  What are the main components of this mind-set?  What, IOW,
> should I pay special attention to in order to avoid simply writing "C in
> Ada" (whatever that might mean).  Thanks again for the help.

For the most part, that's just something you'll have to work out. (Is there a
support group for recovering C coders?)

One good example that does spring to mind is string handling. C coders want
to be able to assign a length 5 string into a length 12 string because strcpy
would do that for them. So their first try tends to be:  Str : String(1..12);
begin  Str := "hiho!";

Which won't work in Ada because the two arrays aren't the same size. Then
they will try using a loop or slice to assign the 5 characters only. Then
they try to print the twelve character string. This won't do what they want,
because Ada strings aren't null terminated. Then they discover that they have
to instantiate a generic routine to ouput a number as a string, and they are
liable to get insanely frustrated.

The problem is that the approach is all wrong. Ada developers tend to handle
strings as literals or constants whenever possible. The '&' operator on
strings makes this much easier to deal with. Scalar numbers can be converted
to strings inline w/ "'image". In a severe jam a declare block can be used to
get a localized constant string, or one of the ada.strings packages can be
used.

This is just one example of many. I guess the main point is that you have to
think in terms of the tools at your disposal, not in terms of the tools you
*don't* have.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Time to join the fold?

[robert_dewar]

In article <78i8s4$hth$1@its.hooked.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:

> - Ada is wordy.  Luckily I'm a touch typist <g>.
> However, I recognize that
> I sometimes get myself into trouble in C because it *is*
> so easy to write a
> quick function, and then another, and then...  Presumably
> the Ada
> requirement (as I perceive it) to "spell it all out"
> helps encourage "think
> twice, write once" programming.


That may be so, and if so, good :-)

But that is not the goal of the syntax design. Rather in
Ada we completely favor the reader over the writer, we
don't care if the writer has to work a bit harder if it
helps the reader. So the way to judge Ada code is by how
easy it is to read, not how easy it is to write!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Time to join the fold?

[Jean-Pierre Rosen]

Mike Silva a �crit dans le message <78i8s4$hth$1@its.hooked.net>...
>Now for another question.  Some people have mentioned getting into
the Ada
>"mind-set".  What are the main components of this mind-set?  What,
IOW,
>should I pay special attention to in order to avoid simply writing "C
in
>Ada" (whatever that might mean).  Thanks again for the help.
>
Short answer:
C programmers write quickly and have lot of fun debugging programs.
The ultimate experience for the Ada programmer is to spend two days
getting the program through the compiler, but then it works like a
charm from the first run on.

* Ada programmers hardly know what a debugger is
* Ada programmers don't know the syntax of a make file
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Time to join the fold?

[dennison]

In article <78julr$nd8$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> The ultimate experience for the Ada programmer is to spend two days
> getting the program through the compiler, but then it works like a
> charm from the first run on.

Eww. I hate seeing people put it this way, because it really isn't true. It
usually only takes me a few minutes to placate the compiler (less if I take
the intelligent approach and check things every few minutes with the compiler
while I'm coding). But I almost always have a bug or two in any reasonablly
complicated algorithm.

The difference is that my C code (usually toy school projects) always seems
to be a veritable cornucopia of bugs. I have bugs masking bugs masking bugs.
Think of a heaving, teaming mountain of cockroaches which must be removed
one-by-one... Yuk! Why put myself through that grief when I don't have to?

T.E.D. (who hates working w/o a debugger, and knows the syntax of a makefile
very well)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Time to join the fold?

[Pascal MALAISE]

dennison@telepath.com wrote:
> 
> In article <78julr$nd8$1@platane.wanadoo.fr>,
>   "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> >
> > The ultimate experience for the Ada programmer is to spend two days
> > getting the program through the compiler, but then it works like a
> > charm from the first run on.
> 
> Eww. I hate seeing people put it this way, because it really isn't true. It
> usually only takes me a few minutes to placate the compiler (less if I take
> the intelligent approach and check things every few minutes with the compiler
> while I'm coding). But I almost always have a bug or two in any reasonablly
> complicated algorithm.

I fully agree with you. My point of view is that the level of
abstraction
of the language helps me foccusing on the algorithm and I don't spend
time
and energy thinking of arrays from 0 to N-1, strings of length N but
size N+1,
looking ant man pages for the order of memcpy and bcopy arguments...
(You guessed I program in C as well :-).
This applies when coding, debugging, re-reading, modifying the code, but
doesn't mean that the Ada code does not need to be commented.

On the other hand, the level of abstraction is not too high. I still can
have
the control of the size and performances of the program.
I still can have, if I want, a good idea about how my source is
translated to the
machine code.
I still can interface with C for signals, OS and X calls.

Ada is just the best compromise between abstraction an pragmatism.

-- 
Pascal MALAISE
(priv) mailto:malaise@magic.fr
(prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Re: Time to join the fold?

[Steve Whalen]

Mike Silva <mjsilva@jps.net> wrote:
[snip]
: Now for another question.  Some people have mentioned getting into the Ada
: "mind-set".  What are the main components of this mind-set?  What, IOW,
: should I pay special attention to in order to avoid simply writing "C in
: Ada" (whatever that might mean).  [snip]

Spend more time thinking about your application's data, and your
application "as data" (by "application as data" I mean revisit program
logic, and see if it can be better represented in a "soft" data
structure somewhere).

Here's what I mean by spending more time thinking about your data. As
assembler or C programmers, we tend to describe data to the compiler
just clearly enough so we can start coding.

I think a key difference of an Ada "mind-set", is that I now work much
harder to tell the compiler everything I know about the data, with as
much precision as I can, so I can get the compiler's strong typing
facilities working for me.

Even more importantly I want to benefit from thinking more deeply
about WHY some data should be a represented one way, instead of
another.

I've had programmers switching to Ada, ask for help in getting this
"mind-set". One thing that seemed to help, was when I assigned them to
take some data structure they were working with, and create as many
different representations of the data structure in Ada as they could
(i.e. compile & use them in a simple program).

Usually, at the end of the first few meetings, I'd send them back to
look at other ways to represent the data & use more features of the
language (i.e. go back and read about ...).  Once they had a fairly
complete set of the ways you could represent the data, I'd have them
explain why each one was a good way to represent the data for this
particular application, or why it was bad, or why it was best.

After a while, a "mind-set" starts to develop, and you learn how
important it is to describe your data to Ada properly, so Ada can help
you the most.  This "mind-set" gets reinforced when you find doing all
this extra (or more painstaking) work helps you locate deeper logic
flaws in your systems.
 
Bottom line: Getting the data structures and representations right
lets Ada help you build higher quality applications.

Steve
-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Time to join the fold?

[Matthew Heaney]

dennison@telepath.com writes:

> In a severe jam a declare block can be used to get a localized
> constant string, or one of the ada.strings packages can be used.

Rather odd to describe using a declare block to declare a string object
only in a "severe jam," since this is the normal, intended usage!

   declare
      Name : constant String := Get_Name (File);
   begin
   ...


Or

   declare
      Name : String := Get_Name (File);
   begin
      Make_Uppercase (Name);
      ...

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[Matthew Heaney]

dennison@telepath.com writes:

> In article <m3aeyz8mw1.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> > dennison@telepath.com writes:
> >
> > > In a severe jam a declare block can be used to get a localized
> > > constant string, or one of the ada.strings packages can be used.
> >
> > Rather odd to describe using a declare block to declare a string object
> > only in a "severe jam," since this is the normal, intended usage!
> >
> 
> True, that is what they are there for. But my style is to avoid declare
> blocks if I can help it. Typicaly I'd try to break off a proper subroutine
> first. When I do use declare blocks, its usually just to provide a localized
> exception handler (and in that case of course the "declare" isn't nessecary).
> 
> I'm not entirely sure I can defend this aversion to declare blocks in a
> rational way, so if anyone has a rationale as to why its perfecly acceptable
> to have declare blocks liberally sprinkled throught their code, I'm all ears.


The purpose of a declare block is to localize an object declaration, so you
can minimize the distance between the declaration of object and its
actual use.

The purpose of a subprogram is algorithmic abstraction.  A declare block
is not an abstraction of an algorithm.

I do "liberally sprinkle my code" with declare blocks, especially for
declaring the result of a function that returns an unconstrained array
(i.e. string).  This localizes the object, and avoids an assignment of a
string value to a string object, so there won't be any length mismatch
problems.

The point of this thread is about how to effect an ada mind-set.  The
liberal use of declare blocks is a common Ada idiom.

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[Larry Kilgallen]

In article <794gg7$ib$1@nnrp1.dejanews.com>, dennison@telepath.com writes:

> I'm not entirely sure I can defend this aversion to declare blocks in a
> rational way, so if anyone has a rationale as to why its perfecly acceptable
> to have declare blocks liberally sprinkled throught their code, I'm all ears.

I use declare blocks for objects that are only of very local interest
because it makes it clear to the reader that there is no need to look
elsewhere for any references.

Perhaps subconsciously I think I may be adding runtime efficiency,
but obviously compilers could do this work as well with "just in time"
initialization in order to avoid initialization overhead during those
invocations which will never use the object.  I have no guarantee
that would be a priority for compiler implementers, and in one recent
situation I had decided _not_ to use declare blocks because initialization
of some rarely-used objects was tricky enough that I wanted to initialize
every time, to maximize the chances of run-time error detection even if
the path using the object would not be traversed.  It worked -- a defect
in my data assumptions was detected on a run where the object would not
actually have been used.

Larry Kilgallen

Re: Time to join the fold?

[Robert I. Eachus]

In article <swhalenF67p8v.HGq@netcom.com> Steve Whalen <swhalen@netcom.com> writes:

 > Spend more time thinking about your application's data, and your
 > application "as data" (by "application as data" I mean revisit program
 > logic, and see if it can be better represented in a "soft" data
 > structure somewhere)...
 > Even more importantly I want to benefit from thinking more deeply
 > about WHY some data should be a represented one way, instead of
 > another...
 > Bottom line: Getting the data structures and representations right
 > lets Ada help you build higher quality applications...

   Amen!  I find that effort devoted to the package specifications,
which contain most of the data types, either exported or in the private
part, is the key part of programming in Ada.  Once you know which
types should be used where and why, writing the code is easy.

   But there is another part to Ada think.  In many languages you are
looking for a model which best fits the solution.  In Ada it is almost
always a big win to fit the model to the problem space.  Generics and
generic instantiation can be used to map a solution onto your problem.

   To take one simple example, if you are going to sort a list the
ordering relation is a generic argument that can be a quite complex
function of the data.  If the sort order changes, you change that
function, not the data.  But if your requirements change in such a way
that you need to represent additional aspects of reality in the data,
this requires additional modifications.

   Hmmm... Not quite simple expressed that way.  Say you have a
bibliography.  The effort required to sort by author, title, Library
of Congress number, or even author's middle name, is small, assuming
that all are present in the data.  Your problem space is a
bibliography, the sort package's problem space is lists to be sorted,
and all you have to do is provide the glue.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Dynamicly declaring arrays (was: Time to join the fold?)

[dennison]

In article <m3aeyz8mw1.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dennison@telepath.com writes:
>
> > In a severe jam a declare block can be used to get a localized
> > constant string, or one of the ada.strings packages can be used.
>
> Rather odd to describe using a declare block to declare a string object
> only in a "severe jam," since this is the normal, intended usage!
>

True, that is what they are there for. But my style is to avoid declare
blocks if I can help it. Typicaly I'd try to break off a proper subroutine
first. When I do use declare blocks, its usually just to provide a localized
exception handler (and in that case of course the "declare" isn't nessecary).

I'm not entirely sure I can defend this aversion to declare blocks in a
rational way, so if anyone has a rationale as to why its perfecly acceptable
to have declare blocks liberally sprinkled throught their code, I'm all ears.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[William Clodius]

robert_dewar@my-dejanews.com wrote:
> <snip>
> That's misleading of course, this is the date of
> standardization, and cannot be compared with the M2 date,
> since there was no ISO standard for M2 as far as I know.
> <snip>

Modlua 2 was standardized in 1996 over the objections of the USA, Japan,
and the Netherlands. The document includes a number of extensions to
Wirth's original language, clarifies a number of ambiguities, and
provides a detailed semantic description using the Vienna definition
model. The base language (subsequent publications have added object
orientation and generics) is 707 pages long. There was a strong feeling
by many observers that the extensions and the reliance on VDM got out of
hand, given that Wirth's original definition was, I believe, well under
50 pages.

Further information can be found in comp.lang.modula2

For what its worth Modula 1 predates Ada though not widely used.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[robert_dewar]

In article <794gg7$ib$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> I'm not entirely sure I can defend this aversion to
> declare blocks in a rational way, so if anyone has a
> rationale as to why its perfecly acceptable to have
> declare blocks liberally sprinkled throught their code,
> I'm all ears.

Why on earth does it need a rationale to use a feature
in the language that is obviously useful and has an ancient
and well accepted understanding as useful (blocks were
after all in Algol-60).

THe principle of using blcoks to make temporaries as
local as possible is of course familiar to any programmer
in an algol style language.

People can have allergies to anything, but a person with
an allergy to strawberries cannot reasonably ask a normal
healthy person to give a rationale for eating strawberries.

In this case we have a thread that clearly shows a use of
declare, and the response "that's nice, but I don't like
to use declare blocks" is indeed not convincing!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[news.oxy.com]

robert_dewar@my-dejanews.com wrote in message
<7963q0$ail$1@nnrp1.dejanews.com>...
>In article <794gg7$ib$1@nnrp1.dejanews.com>,
>  dennison@telepath.com wrote:
>> I'm not entirely sure I can defend this aversion to
>> declare blocks in a rational way, so if anyone has a
>> rationale as to why its perfecly acceptable to have
>> declare blocks liberally sprinkled throught their code,
>> I'm all ears.
>
>Why on earth does it need a rationale to use a feature
>in the language that is obviously useful and has an ancient
>and well accepted understanding as useful (blocks were
>after all in Algol-60).
>
>THe principle of using blcoks to make temporaries as
>local as possible is of course familiar to any programmer
>in an algol style language.


I could also mention that this was also used  in   Modula-2 as well (inner
modules).
Modula-2 had many features that later was implemented in Ada.
E.g. module in Modula-2 corresponds to package in Ada, IMPORT clause in
Modula-2 corresponds to WITH clause in Ada ,concept of "safe&reliable"
programming, concept of hiding implementation details using module
specifications  e.t.c.

Ability to reduce the living scope and name scope  of any king of objects
within large program can significantly increase the reliability of the
program.

Local blocks are especially useful in conjunction with some of other
powerful Ada features and give you ability
 1. To use  USE  and/or  USE TYPE clauses within declaration block so you do
not need to type fully qualified names and at the same time there is no
possibility of names clashes within program scope
 2. To locally  rename long packages and function names and create local
instances of  generic packages.
   2.1. both  1 &2  greatly increase readability of the program and show
programmer intentions.
 3. To declare local objects that should  be deleted on exit of the block
scope.
     This is very useful in conjunction with the use of controlled types
that is used to implement some kind of user defined garbage collection;
 4.  To define  local exception handlers  within block.

This list is not full. It is just short outline.
The real feeling of all that things will come with time and experience.

Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: Time to join the fold?

[news.oxy.com]

robert_dewar@my-dejanews.com wrote in message
<78irk3$d28$1@nnrp1.dejanews.com>...
>In article <78i8s4$hth$1@its.hooked.net>,
>  "Mike Silva" <mjsilva@jps.net> wrote:
>
>> - Ada is wordy.  Luckily I'm a touch typist <g>.
>> However, I recognize that
>> I sometimes get myself into trouble in C because it *is*
>> so easy to write a
>> quick function, and then another, and then...  Presumably
>> the Ada
>> requirement (as I perceive it) to "spell it all out"
>> helps encourage "think
>> twice, write once" programming.
>
>
>That may be so, and if so, good :-)
>
>But that is not the goal of the syntax design. Rather in
>Ada we completely favor the reader over the writer, we
>don't care if the writer has to work a bit harder if it
>helps the reader. So the way to judge Ada code is by how
>easy it is to read, not how easy it is to write!


As a comment to this I would like to  suggest quote from  Guutier "A good
laugh .." post:

>Frederic wrote:

>> Ridiculous. Tell me one thing you can do in C you cannot do in Pascal.

>Write code, that looks like THIS:    ;-)))

>  ==================================================================
>  #include <io.h>
>  float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
>  (h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<L?--_
>  %6:6:7)+"World! \n",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}
==================================================================

Maybe it is easy to write such kind of things but it is not possible to read
it and  to understand it.

Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[nabbasi]

In article <7973lb$mdl$1@remarQ.com>, "news.oxy.com" says...
>
 
>Modula-2 had many features that later was implemented in Ada.

didn't Modula-2 come after Ada? 

Nasser 

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[dennison]

In article <7973lb$mdl$1@remarQ.com>,
  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:

> Ability to reduce the living scope and name scope  of any king of objects
> within large program can significantly increase the reliability of the
> program.

I tend to find when I need this feature there is also some conceptual detail
that could be abstracted away as well, so I'll just create a new subroutine.
Its very rare that I write a routine with more than about 10 semi's from
"begin" to "end".

Assuming it can be inlined, I don't see where I loose anything by using a
subroutine over a declare block. There are additionally several advantages to
subroutines, both conceptually and syntacticly.

>
> Local blocks are especially useful in conjunction with some of other
> powerful Ada features and give you ability
>  1. To use  USE  and/or  USE TYPE clauses within declaration block so you do
> not need to type fully qualified names and at the same time there is no
> possibility of names clashes within program scope

That's a pretty good one. I don't do "use" clauses, but blocks could be useful
for "use types" (or in Ada83, operator function renames).

>  2. To locally  rename long packages and function names and create local
> instances of  generic packages.

I don't like to use renames. Its one more thing for the poor sap trying to
figure out my code to keep track of. But I suppose localizing the renames
would lessen the problem a tad.

>  3. To declare local objects that should  be deleted on exit of the block
> scope.
>      This is very useful in conjunction with the use of controlled types
> that is used to implement some kind of user defined garbage collection;

Bingo! That's a good one. I do have one example in code I wrote recently that
does just that.

>  4.  To define  local exception handlers  within block.
That's one use of them I do need quite a bit (but technicly, those are just
"begin...end" blocks :-) ).


T.E.D. (please don't flame me; I'm just looking to improve my technique.)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[robert_dewar]

In article <7973lb$mdl$1@remarQ.com>,
  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
> I could also mention that this was also used  in
> Modula-2 as well (inner modules). Modula-2 had many
> features that later was implemented in Ada.

I don't believe that Modula-2 had much influence
on the Ada design, but I may be wrong. Certainly
the design of the modules facility for Algol-68
(in which incidentally I participated, it was
basically a three person effort, me, Charles
Linsdsay, and Hendrick Boom) did have some
influence.

Is the time right for Modula-2 to have
influenced the design (the time period was
1975-1978). I thought M2 was later than this,
but I may well be mistaken.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[dennison]

In article <797595$ede@drn.newsguy.com>,
  nabbasi@earthlink.net.NOSPAM wrote:
> In article <7973lb$mdl$1@remarQ.com>, "news.oxy.com" says...
> >
>
> >Modula-2 had many features that later was implemented in Ada.
>
> didn't Modula-2 come after Ada?

According to FOLDOC (
http://www.instantweb.com/foldoc/foldoc.cgi?query=modula-2 ) Modula-2 was
designed by Niklaus Wirth in 1978. The last *requirements* document for Ada
(Steelman) was completed in 1978. The language design was not completed until
1983.

For more info on the history of Ada, see http://www.adahome.com/History/ and
the links contained therein.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[robert_dewar]

In article <797io4$jt7$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> The language design was not completed until 1983.

That's misleading of course, this is the date of
standardization, and cannot be compared with the M2 date,
since there was no ISO standard for M2 as far as I know.

The design of Ada in terms of major features (blocks yes or
no?) was complete long before then. The 1979 preliminary
Ada document really had most of the design complete, and it
was just polishing from there on.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[Al Christians]

M2 does have an ISO standard. 

See:
	http://sc22wg13.twi.tudelft.nl/

These include object-oriented extensions. 

Al



robert_dewar@my-dejanews.com wrote:
> 
> In article <797io4$jt7$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > The language design was not completed until 1983.
> 
> That's misleading of course, this is the date of
> standardization, and cannot be compared with the M2 date,
> since there was no ISO standard for M2 as far as I know.
> 
> The design of Ada in terms of major features (blocks yes or
> no?) was complete long before then. The 1979 preliminary
> Ada document really had most of the design complete, and it
> was just polishing from there on.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[dennison]

In article <797q7f$r60$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <797io4$jt7$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > The language design was not completed until 1983.
>
> That's misleading of course, this is the date of
> standardization, and cannot be compared with the M2 date,
> since there was no ISO standard for M2 as far as I know.

Apparently there is an ISO standard. I couldn't dig up a date on it, but it
appears to have occurred significantly after the original design of the
language. That is fairly similar to the situation with K&R C vs. ISO C. But
your point is quite valid.

Niggles about the exact dates notwithstanding, it is fairly clear that
Modula-2 does *not* postdate Ada. I think the best way to think of them is as
"sister" languages.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[Robert I. Eachus]

In article <7992oe$ram$1@remarQ.com> "news.oxy.com" <Vladimir_Olensky@oxy.com> writes:

  > I think it does not matter much which was defined first and whether M2
  > influenced design of Ada 83 or not.
  > The people that were designing Ada 83 can only answer this question.

   Actually it is the people who designed Ada 79 (Preliminary Ada) and
Ada 80 that you should ask.  In any case, Robert Dewar was a
participant, so he can answer the question. ;-) Niklaus Wirth, was
not, to my knowledge a participant, and as far as I can tell, the
Wirth language that had the most impact on Ada 79 was Algol-W (from
1967).  Much of that was in the I/O area, and was substantially
revised in Ada 80 and Ada 83.

 > It may be so that experience with M2 was known to some members of Ada design
 > team and it could have some influence on them. Anyway that is
 > already part of the history. 

    Actually, I would say that the greater flow was from Ada 83 to
Modula-3 (Note: 3 not 2).  Of course, the lack of available
implementations seems to have driven Modula-3 from the scene.






--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Modula 2

[William Clodius]

Robert A Duff wrote:
> <snip>
> Wirth's language descriptions are quite short, primarily because he
> tends to leave out a lot of important details, IMHO.  That's his style.
> I would expect a definition of any of Wirth's languages, suitable for
> standardization, would be much longer than Wirth's original, even if
> there were *no* extensions or use of VDM.
> <snip>

Yes it would be longer, but not fifteen to twenty times longer. Note for
example that ISO Pascal ISO 7185:1990 is 78 pages long, which is two to
three times the size of Wirth's original definition, and extended Pascal
is 214 pages long, about six to eight times the size of Wirth's original
definition after adding numerous extensions. (Yes I agree page count can
be misleading, but that is the main data I have at the moment.)

Wirth's Modula 2 was a more complicated than his Pascal, but not a lot
more complicated. A Modula 2 standard giving the main syntax and
semantics in 100-125 pages and additional libraries in 100-125
additional pages would have been viewed as a reasonable extension and
clarification.

To put it into other perspectives:

	The Modula 2 base language document is (in terms of page count) almost
40% larger than the Ada 95 standard, without providing object
orientation or generics. Including the separate later documents giving
these extensions results in a nominal definition well over 50% larger
than the Ada standard, but still less functional than Ada 95.

	The Modula 2 base language document is (in terms of page count) about
2% smaller than the C++ standard. The library is not nearly as
functional as that of C++.

	Algol 68's two level grammar, that provides precision comparable to the
VDM, was used to define a language of comparable complexity (excluding
libraries) in complete detail in, Robert Dewar will probably correct
this, I believe a little under 200 pages.

	The VDM specification has not fulfilled the role the committee espected
for it when standardization started. They hoped to be able use the VDM
as input to automatic tools to verify the self consistency of the
standard, but resource limitations kept the tools from being completed.
It has instead resulted in extra work that delayed publication and made
the standard more difficult to read for those unfamiliar with VDM (most
compiler writers and reviewers of the draft standard are unfamiliar with
VDM).

	The exception handling mechanism specified in the Modula 2 document is
very different from PL/I, Ada, or C++, and was widely viewed as an
unwise experiment for a language standard.

	The libraries as a whole were rather experimental and had little match
to those described by Wirth in his Modula 2 texts.

	Some "countries", e.g., Sweden, that did not file formal objections to
the standard, included comments to the effect that the standard when
adopted would kill the language.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[news.oxy.com]

robert_dewar@my-dejanews.com wrote in message
<797hjv$ivm$1@nnrp1.dejanews.com>...
>In article <7973lb$mdl$1@remarQ.com>,
>  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
>> I could also mention that this was also used  in
>> Modula-2 as well (inner modules). Modula-2 had many
>> features that later was implemented in Ada.
>
>I don't believe that Modula-2 had much influence
>on the Ada design, but I may be wrong. Certainly
>the design of the modules facility for Algol-68
>(in which incidentally I participated, it was
>basically a three person effort, me, Charles
>Linsdsay, and Hendrick Boom) did have some
>influence.
>
>Is the time right for Modula-2 to have
>influenced the design (the time period was
>1975-1978). I thought M2 was later than this,
>but I may well be mistaken.
>


I think it does not matter much which was defined first and whether M2
influenced design of Ada 83 or not.
The people that were designing Ada 83 can only answer this question.

At the end of 70's there was some ideas in the air and they could be caught
and materialized into language specifications by different groups of people.
If we look at the history of science/technology we can find many examples
when isolated scientists and research groups in different countries were
catching and materializing the same ideas independently.
M2 was materialization of such ideas and they were embodied by Niklaus Wirth
in a way how he felt them.
As far as I remember it also was a part of his work on the "Lilith"
supercomputer project (probably I misspelled it) where M2 was used to write
OS for that machine.
Of course first M2 definition was published before Ada 83 definition as well
as first M2 implementations were available before first Ada implementations.
I have somewhere at home this M2 specification and can try to find it to
verify the date.
It may be so that experience with M2 was known to some members of Ada design
team and it could have some influence on them.
Anyway that is already part of the history.

What I found to be very interesting is that  GDB that comes with GNAT 3.11p
supports M2.
I found the following in the GDB manual (exact copy):
------------------------------------------------------------
|     Supported languages
|     ===================
|     GDB 4 supports Modula-2, Fortran, Ada, C, and C++.
|     ...
|     Modula-2
|      --------
|      The extensions made to GDB to support Modula-2 only support output
|  from the GNU Modula-2 compiler (which is currently being developed).
|  Other Modula-2 compilers are not currently supported, and attempting to
|  debug executables produced by them is most likely to give an error as
|  GDB reads in the executable's symbol table.
----------------------------------------------------------------------
It seems that it may happen that soon we will have an ALL IN distribution
package under GNU project.
History is about to finish one more circle.


Here I would like to add one more thing:
It is important to have some kind of internal feeling of the new ideas and
fresh vision of the old ones to feel the future and be able create something
that will have impact on the evolution as a whole. Such feeling is called
intuition and it is usually based on a large variety of experiences and
knowledges that are stored somewhere deeply in mind on sub-consciousness
level (after person mind filters out everything that is insignificant).

One of such old-new ideas is the implementation of the easily available
universal Ada RAD toolkit ("Ada Delphi").  If it has good materialization it
(as I feel it) can have great impact on the Ada future.
The more people feel like it the more chances for this to happen.


Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[Robert A Duff]

William Clodius <wclodius@lanl.gov> writes:

>...There was a strong feeling
> by many observers that the extensions and the reliance on VDM got out of
> hand, given that Wirth's original definition was, I believe, well under
> 50 pages.

Wirth's language descriptions are quite short, primarily because he
tends to leave out a lot of important details, IMHO.  That's his style.
I would expect a definition of any of Wirth's languages, suitable for
standardization, would be much longer than Wirth's original, even if
there were *no* extensions or use of VDM.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: M2 history - relations to Ada

[Jean-Pierre Rosen]

news.oxy.com a �crit dans le message <79c1lk$nub$1@remarQ.com>...
>This is very good clarification indeed !
>Probably a lot of people just do not know about this.
>For them Bill Gates, Microsoft and DOS are all the same  legend.
>
BTW, I've heard that the original name for the OS that Microsoft
bought was QDOS.
It meant "Quick and Dirty Operating System"...
Sigh
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: M2 history - relations to Ada

[Jerry van Dijk]

Chris Morgan (mihalis@ix.netcom.com) wrote:

: > Just one small point of clarification about this "history:"
: > Gates didn't write DOS. Microsoft, which had been writing language
: > translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle Computer
: > Products.

: Didn't SCP nickname it QDOS or "quick and dirty operating system" and
: wasn't it just a rip off of CP/M?

Yep, and to finish this soap, it was written by Tim Patterson.

:-)

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: M2 history - relations to Ada

[David C. Hoos, Sr.]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Robert Lanziner-Furtenbach wrote in message <36BA2F44.6E678680@vlbg.at>...
>
>
>Aron Felix Gurski wrote:
>>
>> David C. Hoos, Sr. wrote:
>> >
>> And what's more, it was originally called QDOS: Quick and Dirty Operating
>> System. Of course, that name is not something that IBM would market, so
the
>> name got changed when IBM came into the picture.
>> --
>
>As far as i know, it�s name was DOS86 as a implementation of CP/M for
>8086.
Here's the sequence and the real names:

Digital Research was too slow in getting CP/M-86 completed to meet the needs
of some hardware manufacturers.  As a consequence, Tim Paterson of Seattle
computer Products put together the product originally named QDOS (Quick and
Dirty Operating System), later named 86-DOS, which was the name it had when
Microsoft bought it.

I know this story very well, for I was involved with implementation of
C/PM-86 for a pre-IBM-PC 8086 (not 8088) computer, in 1979, or so.  I was
one of those who thought Microsoft should stick to doing language
translators, and leave the OS to Digital Research, so I had my train hitched
to the wrong engine, as it turned out.

David C. Hoos, Sr.

Re: M2 history - relations to Ada

[news.oxy.com]

news.oxy.com wrote in message <7992oe$ram$1@remarQ.com>...

>robert_dewar@my-dejanews.com wrote in message
>>I don't believe that Modula-2 had much influence
>>on the Ada design, but I may be wrong. Certainly
>>the design of the modules facility for Algol-68
>>  <....> did have some influence.

>>Is the time right for Modula-2 to have
>>influenced the design (the time period was
>>1975-1978). I thought M2 was later than this,
>>but I may well be mistaken.

>I think it does not matter much which was defined first and whether M2
>influenced design of Ada 83 or not.


>Of course first M2 definition was published before Ada 83 definition as
well
>as first M2 implementations were available before first Ada
implementations.
>I have somewhere at home this M2 specification and can try to find it to
>verify the date.

*****************
I did some small historical research and found the following:

Below you will find some info from Niklaus Wirth papers and from his
"Programming in Modula-2".

Modula-2 is direct descendant of Pascal and  Modula.
Modula was specified and implemented in 1975.
In 1977 project "Lilith" was started in "Institute fur Informatic". This
project was aimed to develop hardware and software for new minicomputer
(prototype of modern PCs ?). System OS should be written using high-level
language.
The outcome of that was language Modula-2.
First Modula-2 implementation was on PDP-11 in 1979.
In March 1980 first public specification was published.
In 1981 M2 was passed to external users.
First specification size was 32 pages (text body) and  4 annexes took 31
page (in my text  so t may vary depending on font size).
High level OS independent multitasking Module "Processes" was based on ideas
of "Modula-1" and "Concurrent Pascal".

But most interesting is below.

When I was looking through Niklause Wirth description of language predefined
modules I found to my great surprise that he defined root Module "Windows"
and two descendant from it, namely  "TextWindows" and "GraficWindows" as
well as "Menu" and "CursorMenu" modules that were used to create GUI for
"Lilith" OS written in Modula-2.

How about that, then!  First "Windows" was created before Bill Gates wrote
his "DOS" for IBM PC.
Just imagine. It was almost ten years before Microsoft Windows appeared. And
it was multitasking system.

If Niklaus Wirth would be not only scientist but also a businessman and
registered "Windows" as his trademark we could have Niklaus Wirth "Windows"
instead Bill Gates  MS-Windows much yearlier. Maybe Bill Gates would be then
just  programmer in N.Wirth Company.  But of course N.Wirth was about ten
years ahead of time and there were not freely available personal computers
that. May be IBM did a great mistake choosing B.G. "DOS" as an OS for their
PC ?
If they selected "Lilith" as prototype than we could have now completely
different world !
I have some "Lilith" screen shorts. You won't believe ! It is almost the
same Windows.
This was as  a lightening that enlightened some deep corners of my memory.
Now I remember that in the very beginning of 90's   when I was using
TopSpeed Modula-2 in our  Research Institute ( I set it up as a mandate
language for a group of programmers that were writing some pieces of
software for my equipment)  we were using  module "Windows" very
extensively. When I heard about MS-Windows my first though was that this was
some new module for M2 but I was wrong then.


There is one more thing that comes to my mind now.
Twenty years have left since windows GUI concept was implemented by Nicklaus
Wirth and we are still talking about necessity of Windows GUI oriented Ada
RAD Toolkit with very little progress. This is amazing.

History is a great teacher in all times.


Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: M2 history - relations to Ada

[Chuck Clark]

I thought xerox had the first color 'windows' type system
in the late 60's or 70's but never followed throught with it
and got out of computers all together for some other
product.


> When I was looking through Niklause Wirth description of language predefined
> modules I found to my great surprise that he defined root Module "Windows"
> and two descendant from it, namely  "TextWindows" and "GraficWindows" as
> well as "Menu" and "CursorMenu" modules that were used to create GUI for
> "Lilith" OS written in Modula-2.
>
> How about that, then!  First "Windows" was created before Bill Gates wrote
> his "DOS" for IBM PC.
> Just imagine. It was almost ten years before Microsoft Windows appeared. And
> it was multitasking system.
>
> I

Re: M2 history - relations to Ada

[David C. Hoos, Sr.]

news.oxy.com wrote in message <79bp1n$fd5$1@remarQ.com>...
<large snip>
>How about that, then!  First "Windows" was created before Bill Gates wrote
>his "DOS" for IBM PC.
Just one small point of clarification about this "history:"
Gates didn't write DOS. Microsoft, which had been writing language
translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle Computer
Products.

Re: M2 history - relations to Ada

[news.oxy.com]

David C. Hoos, Sr. wrote in message ...

>news.oxy.com wrote in message <79bp1n$fd5$1@remarQ.com>...
><large snip>
>>How about that, then!  First "Windows" was created before Bill Gates wrote
>>his "DOS" for IBM PC.
>Just one small point of clarification about this "history:"
>Gates didn't write DOS. Microsoft, which had been writing language
>translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle
Computer
>Products.


This is very good clarification indeed !
Probably a lot of people just do not know about this.
For them Bill Gates, Microsoft and DOS are all the same  legend.


Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: M2 history - relations to Ada

[G.S. Vigneault]

On Thu, 4 Feb 1999 14:50:47 +0300, "news.oxy.com"
<Vladimir_Olensky@oxy.com> wrote:
>David C. Hoos, Sr. wrote in message ...
>>news.oxy.com wrote in message <79bp1n$fd5$1@remarQ.com>...
>><large snip>
>>>How about that, then!  First "Windows" was created before Bill Gates wrote
>>>his "DOS" for IBM PC.
>>Just one small point of clarification about this "history:"
>>Gates didn't write DOS. Microsoft, which had been writing language
>>translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle
>Computer
>>Products.
>
>
>This is very good clarification indeed !
>Probably a lot of people just do not know about this.
>For them Bill Gates, Microsoft and DOS are all the same  legend.
>
>

  Not a "legend" -- a "legacy" !!

  Greg_

  http://www.netcom.ca/~telic

Re: M2 history - relations to Ada

[robert_dewar]

In article <79bp1n$fd5$1@remarQ.com>,
  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
> news.oxy.com wrote in message
<7992oe$ram$1@remarQ.com>...
> The outcome of that was language Modula-2.
> First Modula-2 implementation was on PDP-11 in 1979.
> In March 1980 first public specification was published.

So that settles it, Ada definitely precedes M2, since the
first public specification (preliminary Ada) is 1979. Note
that this is the right level to compare with the public
"specification" of M2. If you want to compare final
ISO standard dates, then of course Ada also precedes M2.

Going over some notes, and discussions, it is clear to me
that my recollection is accurate, there was no very
specific input from M2 to Ada, the timing as shown from the
above was just wrong.

However, of course, M2 and Ada are related in the sense of
being Algol-like languages developed at the same time in
the same mix of ideas. Probably the threads of input are
a bit different. For example, it is clearly the case that
Algol-68 had a significantly greater influence on Ada than
on M2 (considering the history this is not surprising :-)



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: M2 history - relations to Ada

[Chris Morgan]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> Just one small point of clarification about this "history:"
> Gates didn't write DOS. Microsoft, which had been writing language
> translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle Computer
> Products.

Didn't SCP nickname it QDOS or "quick and dirty operating system" and
wasn't it just a rip off of CP/M?

-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net

Re: M2 history - relations to Ada

[Aron Felix Gurski]

David C. Hoos, Sr. wrote:
> 
> news.oxy.com wrote in message <79bp1n$fd5$1@remarQ.com>...
> <large snip>
> >How about that, then!  First "Windows" was created before Bill Gates wrote
> >his "DOS" for IBM PC.
> Just one small point of clarification about this "history:"
> Gates didn't write DOS. Microsoft, which had been writing language
> translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle Computer
> Products.

And what's more, it was originally called QDOS: Quick and Dirty Operating
System. Of course, that name is not something that IBM would market, so the
name got changed when IBM came into the picture.
-- 
        -- Aron

+-------------------------------------------------------------------------+
|     _   NB: Om du vil svare med e-post,     |"Sometimes the magic works,|
| __/\_\      m� du fjerne "spam-block."      | sometimes it doesn't."    |
|/\_\/_/      fr� adressa mi.                 |                           |
|\/_/\_\  NB: If you want to reply by e-mail, |    -- Chief Dan George,   |
|   \/_/      you have to remove "spam-block."|       in "Little Big Man" |
|             from my address.                |                           |
+-------------------------------------------------------------------------+

Re: M2 history - relations to Ada

[Robert Lanziner-Furtenbach]

Aron Felix Gurski wrote:
> 
> David C. Hoos, Sr. wrote:
> >
> And what's more, it was originally called QDOS: Quick and Dirty Operating
> System. Of course, that name is not something that IBM would market, so the
> name got changed when IBM came into the picture.
> --

As far as i know, it�s name was DOS86 as a implementation of CP/M for
8086.

And it took incredible 3 month to change the OS to support the hardware.
An former MS-programmer said that it only took 1 month to make a working
product. But then came meta-programmer bill and reprogrammed all parts.
the result was DOS 1.0. ;-)

btw the first useable version (i say) was 3.2

bye Robert



-- 
Robert Lanziner-Furtenbach
BeDeveloper: E-16249
mailto:rlf@vlbg.at or
mailto:rlf@rlf.freeservers.com
http://rlf.freeservers.com

Re: M2 history - relations to Ada

[Grant Edwards]

Chris Morgan (mihalis@ix.netcom.com) wrote:

: > Just one small point of clarification about this "history:"
: > Gates didn't write DOS. Microsoft, which had been writing language
: > translators -- e.g., BASIC and FORTRAN -- _bought_ DOS from Seattle Computer
: > Products.
: 
: Didn't SCP nickname it QDOS or "quick and dirty operating system" and
: wasn't it just a rip off of CP/M?

Definitely.  

The FCB structure was almost identical, the layout of .com files was
the same.  You could call BIOS routines by doing a jump to address
0005 just like CP/M.  The systems calls were the same as CP/M, etc.

Of course, parts of CP/M were pretty transparently borrowed from RSTS
and possibly other systems at DEC (which is where Gary Kildall worked
before he became Digital Research and started selling CP/M).

-- 
Grant Edwards

grante@visi.com

Re: M2 history - relations to Ada

[Robert Lanziner-Furtenbach]

Robert Lanziner-Furtenbach wrote:

> 
> As far as i know, it�s name was DOS86 as a implementation of CP/M for
> 8086.
> 
> And it took incredible 3 month to change the OS to support the hardware.
> An former MS-programmer said that it only took 1 month to make a working
> product. But then came meta-programmer bill and reprogrammed all parts.
> the result was DOS 1.0. ;-)

And all not working parts were called features.
Btw, Bill says in his autobiography, that he had to make major changes
(freely translated
back from the german version), and he is telling truth, really

As far as i know is the name QDOS a (later) joke.
In the late 80s the were some projects like
QDFG (quick and dirty frame grabber).
Maybe the name was "created" at that time.


bye Robert

-- 
Robert Lanziner-Furtenbach
BeDeveloper: E-16249
mailto:rlf@vlbg.at or
mailto:rlf@rlf.freeservers.com
http://rlf.freeservers.com

Re: M2 history - relations to Ada

[Andreas Borchert]

On Thu, 04 Feb 1999 04:10:07 -0600, Chuck Clark <c.clark@mail.utexas.edu> wrote:
> I thought xerox had the first color 'windows' type system
> in the late 60's or 70's but never followed throught with it
> and got out of computers all together for some other
> product.

Indeed and before the development of Lilith, Wirth spent a sabbatical
year at PARC.

Andreas.

-- 
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany
E-Mail: borchert@mathematik.uni-ulm.de
WWW:	http://www.mathematik.uni-ulm.de/sai/borchert/
PGP key available via ``finger borchert@laborix.mathematik.uni-ulm.de''