newbie inquiry

newbie inquiry

[Steven Shaw]

Recently, I've been reading about Modula-3. I got exciting about it but
recently found out that it's pretty much dead. Ada, on the other hand, has
been around awhile and recently because part of the "standard" GCC distro.
I'm hoping that Ada can be my m3. I'm quite new to Ada. I've read the
lovelace tutorial and found some other useful material (but I haven't read
it all yet). There's alot of info out there... If there are any comparisons
with m3 that would be useful for me.

Features I kinda know Ada has (but might be wrong)
    * modules
    * fixed string and dynamically growing strings (excellent)
    * generics

Features I'm hoping Ada has:
    * gc
    * multiple interface inheritence (like Java, m3 doesn't have it)
    * fast language interoperability with C (ffi and data sharing)
    * ability to put data/objects into shared-memory for sharing between
processes
    * speed of C?
    * libraries for database access, sockets/protocols, xml

I read somewhere that Ada doesn't have GC. I think I heard that gnat
supports gc. How does this work out for you? Does this mean you have to use
free() when using the standard library?

Would Ada be as good a choice as C for writing an OS? a dbms?

The Ada spec is very big. Is it all implemented in gnats? Are there features
in the spec that could/should be avoided?

cheers,
Steve.

Re: newbie inquiry

[Jean-Marc Bourguet]

"Steven Shaw" <steve.shaw@uq.net.au> writes:

> Recently, I've been reading about Modula-3. I got exciting about it but
> recently found out that it's pretty much dead. Ada, on the other hand, has
> been around awhile and recently because part of the "standard" GCC distro.
> I'm hoping that Ada can be my m3. I'm quite new to Ada. I've read the
> lovelace tutorial and found some other useful material (but I haven't read
> it all yet). There's alot of info out there... If there are any comparisons
> with m3 that would be useful for me.
> 
> Features I kinda know Ada has (but might be wrong)
>     * modules
>     * fixed string and dynamically growing strings (excellent)
>     * generics
> 
> Features I'm hoping Ada has:
>     * gc

No.  Controlled types can help.  Good design reduce also the need.

>     * multiple interface inheritence (like Java, m3 doesn't have it)

No.  AFAIK, there is an extension proposed for normalisation.  Gnat
has also an extension, I don't know if they are the same.

>     * fast language interoperability with C (ffi and data sharing)
Yes

>     * ability to put data/objects into shared-memory for sharing between
> processes

You can define memory pool for this.

>     * speed of C?

If you use C level structure.

>     * libraries for database access, sockets/protocols, xml

see http://adapower.com/, http://libre.act-europe.fr/ and recent posts.
> 
> I read somewhere that Ada doesn't have GC. I think I heard that gnat
> supports gc.

False for most meaning of "support".

>  How does this work out for you? Does this mean you have to use
> free() when using the standard library?

No. (In fact that would be Unchecked_Deallocation).

> Would Ada be as good a choice as C for writing an OS? a dbms?

People here would argue that's a better choice for a pure technical
point of view.
 
> The Ada spec is very big. Is it all implemented in gnats?

In Gnat yes.  (Gnats is another thing).

> Are there features in the spec that could/should be avoided?

There are things that can be misused, but I know of non that are to be
avoided at all cost.

A+

-- 
Jean-Marc

Re: newbie inquiry

[Pascal Obry]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> 
> >     * multiple interface inheritence (like Java, m3 doesn't have it)
> 
> No.  AFAIK, there is an extension proposed for normalisation.  Gnat
> has also an extension, I don't know if they are the same.

I don't think the last point is true ! GNAT does not have interface
inheritence.

> 
> >     * fast language interoperability with C (ffi and data sharing)
> Yes

See Interfaces.C, Interfaces.C.Pointers and Interfaces.C.Strings +
pragma Import/Export.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: newbie inquiry

[Ed Falis]

On 12 Jun 2002 20:09:56 +0200
Pascal Obry <p.obry@wanadoo.fr> wrote:

> 
> Jean-Marc Bourguet <jm@bourguet.org> writes:
> 
> > 
> > >     * multiple interface inheritence (like Java, m3 doesn't have
> > >     it)
> > 
> > No.  AFAIK, there is an extension proposed for normalisation.  Gnat
> > has also an extension, I don't know if they are the same.
> 
> I don't think the last point is true ! GNAT does not have interface
> inheritence.

While Ada has no specific syntax for multiple inheritance, access
discriminants can be used to implement its effects via idiom.

- Ed

Re: newbie inquiry

[Jean-Marc Bourguet]

Pascal Obry <p.obry@wanadoo.fr> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
> 
> > 
> > >     * multiple interface inheritence (like Java, m3 doesn't have it)
> > 
> > No.  AFAIK, there is an extension proposed for normalisation.  Gnat
> > has also an extension, I don't know if they are the same.
> 
> I don't think the last point is true ! GNAT does not have interface
> inheritence.

You are right.  There is such an extension in JGNAT but it is not
available (or at least is not documented) in GNAT.  I don't know why I
though it was.

Yours,

-- 
Jean-Marc

Re: newbie inquiry

[Stephen Leake]

"Steven Shaw" <steve.shaw@uq.net.au> writes:

> Features I kinda know Ada has (but might be wrong)
>     * modules

Called 'packages'

>     * fixed string and dynamically growing strings (excellent) 

yes

>     * generics

yes

> Features I'm hoping Ada has:
>     * gc

I assume you mean "Garbage Collection" here. The Ada standard allows
garbage collection. Most implementations don't provide it. Those
targeted at the Java virtual machine do provide it.

>     * multiple interface inheritence (like Java, m3 doesn't have it)

The Ada standard does not provide this. The Ada compilers targeted at
the Java virtual machine have extensions that do provide it.

>     * fast language interoperability with C (ffi and data sharing)

I'm not clear what you mean. If you mean Ada functions can efficiently
call C functions, and vice versa, then yes, Ada has this.

>     * ability to put data/objects into shared-memory for sharing between
> processes

This is not in the Ada standard, nor in any other language standard,
that I know of. I don't know of any language that has the notion of
"process"; many have "task" or "thread", but they share an single
address space. 

This is typically done by importing an operating system function,
which can easily done by Ada code.

>     * speed of C?

Yes, some Ada compilers produce machine code that is as fast as that
produced by some C compilers, for equivalent input source code. The
converse is also true :).

>     * libraries for database access, sockets/protocols, xml

Yes, although probably not as much as C or C++ or Java or Cobol.

> The Ada spec is very big. 

In page count, it's smaller than the C++ spec.

> Is it all implemented in gnats? 

In GNAT, yes. Other compilers implement most of Ada; they leave out
some of the optional annexes.

> Are there features in the spec that could/should be avoided?

No. Unless you are doing hard real-time, but that's not a language
implementation issue.

-- 
-- Stephe

Re: newbie inquiry

[Mark Johnson]

Stephen Leake wrote:
> 
> "Steven Shaw" <steve.shaw@uq.net.au> writes:
> [snip]
> >     * ability to put data/objects into shared-memory for sharing between
> > processes
> 
> This is not in the Ada standard, nor in any other language standard,
> that I know of. I don't know of any language that has the notion of
> "process"; many have "task" or "thread", but they share an single
> address space.
> 
I am not sure if the OP meant "process" when he could have meant "Ada
task". If you replace process with Ada task, the answer becomes - yes,
Ada does support access to data and objects in shared memory (ARM
chapter 9). If they do mean process - then I agree with you.

>[snip]
> > Are there features in the spec that could/should be avoided?
> 
> No. Unless you are doing hard real-time, but that's not a language
> implementation issue.
> 
For the most part I agree as well. However, if you really care about
performance - you should probably measure it to determine what you
should or should not avoid. Each Ada compiler is a little different. One
may do exception processing well, another may do better task switching
and protected objects. 
  --Mark

Re: newbie inquiry

[Larry Kilgallen]

In article <ae7rpt$kfi$1@bunyip.cc.uq.edu.au>, "Steven Shaw" <steve.shaw@uq.net.au> writes:

> I read somewhere that Ada doesn't have GC. I think I heard that gnat
> supports gc. How does this work out for you? Does this mean you have to use
> free() when using the standard library?

The Ada language definition is susceptible to a garbage-collecting
implementation, but typical implementations (including GNAT) do not
provide it.  The general answer as to "why not?" seems to be that
there is not much demand for garbage collection from Ada customers.
An earlier (from my observation point on the Internet) pointed to
Controlled Types, a more efficient mechanism to perform some (but not
all) of the work done by garbage collection.  But some situations in
Ada are quite different from in other languages.  Let us say you are
going to call a function What_Size to determine how big you need to
allocate a temporary array.  In Ada that could be:

	My_Size := What_Size;
	declare			-- scope of My_Array
		My_Array : FirnBlatt_Array ( 1 .. My_Size);
	begin			-- scope of My_Array
		null;	-- here we would make use of My_Array
	end;			-- scope of My_Array

That is it.  When one gets to "end;" the runtime-sized My_Array is gone,
with no need to explicitly call a deallocation function.

> Would Ada be as good a choice as C for writing an OS? a dbms?

Yes, because Ada has the option of automatically providing lots
of runtime checks on the sanity of your data.  If you think those
are slowing your program down, it is possible to suppress some or
all of those checks in the final production program, yielding the
equivalent of the unchecking C program.  But so long as Ada can
still find errors in your test runs with those checks, Ada is able
to contribute something to your project -- letting you know early
on what is wrong with your program rather than simply failing with
an illegal memory reference that is difficult to analyze.

> The Ada spec is very big. Is it all implemented in gnats? Are there features
> in the spec that could/should be avoided?

One reason the Ada specification is so big is that is fully specifies
the behavior in many areas that might have been omitted in specification
of an earlier language.

GNAT implements the whole thing.

You should avoid any features you don't really need in your program.
I have been using Ada for 14 years, and I do not think I have ever
used a floating point number.  It took a while before I started using
the "exit when" feature.  For a long time I did not use tasking.  That
is not because tasking is bad, but because it was not needed for the
programs I had to write.

Re: newbie inquiry

[Jeffrey Carter]

Steven Shaw wrote:
> 
> Are there features
> in the [Ada] spec that could/should be avoided?

There are many features that could be avoided. You can avoid tasking if
your problem doesn't require it. You can avoid exceptions if you're
doing correctness proofs using SPARK. You can avoid certain numeric
types if your problem doesn't require them. I have yet to have a need
for decimal fixed point types. Other people probably have to use them
all the time.

Some people suggest that you should avoid asynchronous transfer of
control. Some people suggest that you should avoid the use clause. Some
people suggest that you should avoid the goto statement. One thing many
people, including me, think should be avoided, but many other people do
frequently, is declare derived types where the parent type is neither a
predefined type nor declared in the same declarative region as the
derived type.

A better rule is that there are features that should be used
judiciously. A feature should not be used if it makes the software hard
to read and understand, and should be used if it makes the software
easier to read and understand. There are certainly circumstances in
which very skilled, experienced, and knowledgeable people advocate using
use clauses and goto statements.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: newbie inquiry

[Ted Dennison]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3D07AB92.9181741D@acm.org>...
> Steven Shaw wrote:
> > 
> > Are there features
> > in the [Ada] spec that could/should be avoided?
> 
> control. Some people suggest that you should avoid the use clause. Some

That's a good point. The "use {package};" clause is very
contraversial. I *never* use it. However, some people who's opinions I
respect have no problem with it. A newbie should avoid using it
entirely until they have their feet under them sufficently to make an
intelligent decision.

What I remember from Modula-2 style was that you never saw anyone
using module dot notation to refer to objects in other modules.
However, it was typcial to just import the specific objects you
require from a module, so that you could always figure out where
everything came from without having to look in other source files. The
"use" clause is like a naked (full) import of a module in Modula-2.
Using full package dot notation is the only alternative to that you
get in Ada.

So you can think of the "no use" camp in Ada as equivalent to the
"import with" folks in Modula-2. It can look a bit verbose at first,
but its actually nice once you learn the possiblities (hint: start
thinking of the package name as part of the object name).

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: newbie inquiry

[Freddy]

Ted Dennison schrieb:
> What I remember from Modula-2 style was that you never saw anyone
> using module dot notation to refer to objects in other modules.

Not correct. Me, my friends and my colleques _always_ use "IMPORT x;  
x.<anything>".
But - mostly, because the original standard from N. Wirth did offer only
the "IMPORT x;" or you would have to mention _everything_ "FROM x IMPORT
a,b,c ...". There was _no_ "IMPORT ALL x;" in Wirths definition.



What I most miss in Ada is the "ARRAY OF BYTE" procedure parameter,
which catches up _any_ actual parameter. Especially for communication
routines (files, serial, ip) I liked it.


Sometimes even an SET type would be nice.

Re: newbie inquiry

[Ted Dennison]

Freddy wrote:
> Sometimes even an SET type would be nice.

Well, as I said, you sort of have one with arrays of booleans. It 
doesn't handle large sparse sets as well as my old M2 compiler did, but 
I rarely need those.

Re: newbie inquiry

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> Freddy wrote:
> > Sometimes even an SET type would be nice.
> 
> Well, as I said, you sort of have one with arrays of booleans. It 
> doesn't handle large sparse sets as well as my old M2 compiler did, ...

Really?  I was under the impression that Modula-2 compilers implemented
sets as packed arrays of booleans, and don't do anything special for
sparse sets.  What did your old M2 compiler do?

- Bob

Re: newbie inquiry

[Ted Dennison]

Robert A Duff wrote:
> Ted Dennison <dennison@telepath.com> writes:
> Really?  I was under the impression that Modula-2 compilers implemented
> sets as packed arrays of booleans, and don't do anything special for
> sparse sets.  What did your old M2 compiler do?

Dang you! First you make me climb up into the attic to look at my old 
Amiga Modula-2 manual, then you end up being right. :-)

Re: newbie inquiry

[Ted Dennison]

"Steven Shaw" <steve.shaw@uq.net.au> wrote in message news:<ae7rpt$kfi$1@bunyip.cc.uq.edu.au>...
> Recently, I've been reading about Modula-3. I got exciting about it but
> recently found out that it's pretty much dead. Ada, on the other hand, has
> been around awhile and recently because part of the "standard" GCC distro.

I was an old Modula-2 user for many years before I started using Ada.
I think you'll find the transition is one of the easiest language
transitions you will ever make. You can sort of think of Ada as an
industrial-strength Modula.

> I'm hoping that Ada can be my m3. I'm quite new to Ada. I've read the
> lovelace tutorial and found some other useful material (but I haven't read
> it all yet). There's alot of info out there... If there are any comparisons
> with m3 that would be useful for me.

I wish I knew more about Modula-3. Compared to Modula-2, the only
thing you really don't have is the "set" type (but in a way you do,
because boolean ops work on arrays of booleans). There's no way in Ada
to specify which objects in a package (module) you are using rather
than just importing them all. You can't defer the definition of a type
declared in the specification until the body unless it is an access
type in Ada (for M2 it could be any scalar). I think that's about it
on the Modula-2 side. Everything else on the chart is an advantage for
Ada.

> Features I kinda know Ada has (but might be wrong)
>     * modules
>     * fixed string and dynamically growing strings (excellent)

The dynamicly growing strings are in the standard library. But there
are a lot of tricks you can use with Ada so that you never need to use
them.

> Features I'm hoping Ada has:
>     * gc

The language is defined so that an implementation *could* implement
garbage-collection. Gnat does not, in the general case (for most
targets). However, every compiler does implement a kind of
garbage-collection where all storage for the type gets cleaned up when
the type declaration goes out of scope. It doesn't happen by default
though, you have to use a special construction to tell the compiler
you want to do it.

You can also use controlled types to clean up an object's garbage
automaticly when the object goes out of scope.

Generally dynamic storage reclamation is not a huge issue in Ada,
because the lanuage is designed in such a way that you will typically
not need to dynamcally allocate memory. That's why no one has bothered
to put automatic garbage collection in their compilers, even though
its allowed for by the language.

>     * multiple interface inheritence (like Java, m3 doesn't have it)

Java and M3 don't have it for a very good reason. Like everything else
in Ada, this was thouroughly thought out, and MI was not put in. The
language still supports all the stuff you might want to use MI for
though. There's a good discussion of this in the Ada rationale at
http://www.adaic.org/standards/95rat/RAThtml/rat95-p2-4.html#1 . You
may want to read it if you feel this is going to be an issue for you.

>     * fast language interoperability with C (ffi and data sharing)

You can specify that a subprogram spec is actually implemented in any
other supported language (including C). The compiler will then call it
using that language's calling convention, just like C code would. So
it should be just as "fast" as a call to it in the native language.

Of course C interfaces are ungodly ugly for a trained Ada programmer,
so we typically will write (or use someone else's) wrappers around the
C interface routines, to give us a more Ada-like interface. That of
course slows things down a bit, but in my book its a worthwhile trade.
If you don't think so, you don't have to use a wrapper I suppose. :-)

>     * ability to put data/objects into shared-memory for sharing between
> processes

As someone else pointed out, Ada's supported concurrency model is
"tasks", which are ususally implemented as OS threads when such exist.
All tasks in a program can see the global data in any packages they
"with" (import). Of course, that's not always a very safe way to
communicate. Generally you'd use the rendezvous mechanisim (or
protected types).

>     * speed of C?

Theoreticly, Ada can be made *faster* than C, with the same amount of
effort. In practice, comparable compilers are about the same speed,
but we are usually willing to sacrifice a wee bit of speed to keep
type and range checks (so that our code isn't chock full of buffer
overflow exploits like C code always is). But if you don't want the
checks, you can dispense with them.

>     * libraries for database access, sockets/protocols, xml

This stuff isn't (yet) in the standard library. However, if you are
going to be using Gnat on Windows or Linux, all that stuff is
available as free software downloads (well..I'm not sure about the DB
stuff. I never use databases).

> I read somewhere that Ada doesn't have GC. I think I heard that gnat
> supports gc. How does this work out for you? Does this mean you have to use
> free() when using the standard library?

Again, I almost never use "new", and when I do its usually once at
system startup. So this is really a non-issue for your average Ada
user. The only time it gets to be a real pain is when interfacing with
a lot of C code that does it.

> Would Ada be as good a choice as C for writing an OS? a dbms?

I'm not a DB guy, but it would certianly be a far better choice for
writing an OS. Thousands of security experts and script kiddies would
be looking for constructive things to do right now if Windows had been
written in Ada.

> The Ada spec is very big. Is it all implemented in gnats? Are there features
That's a myth. Ada is a large language compared to C and Pascal, and
back in their heyday was when people started saying this. Ada is
actually much smaller than C++, and is certianly not significantly
bigger than any other modern system programming language.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: newbie inquiry

[Caffeine Junky]

On Thu, 13 Jun 2002 11:19:45 -0400, Ted Dennison wrote:


 
>> Would Ada be as good a choice as C for writing an OS? a dbms?
> 
> I'm not a DB guy, but it would certianly be a far better choice for
> writing an OS. Thousands of security experts and script kiddies would be
> looking for constructive things to do right now if Windows had been
> written in Ada.

I'm not so sure about that Mr. Dennison. One thing I've learned from my
extensive experience with Windows(was an NT Admin for 4 years) and my
regular perusals of the Bloatbusters hall of fame(www.radsoft.net) is
that Microsoft can fuck up even the most trivial of applications,
regardless of what language is being used.
One thing Ada would have done is clarified whether Microsoft fucked up
deliberately or accidentaly, as one really has to work hard to create some
of the screwups I've had the unfortunate "pleasure" to deal with. 

Ada is an awsome tool. I use it alot now that I've finally gotten a
handle on it. But it's no silver bullet. The only thing that can really
garauntee quality is the quality of the people behind the software.

Yet, I must agree; from my standpoint, Ada appears to be an excellent systems
language. It's saved me hours of hairpulling. How much more so for the
hackers and engineers mounting the challenge of creating real OS.

Anyways, my .02 worth

Re: newbie inquiry

[Ted Dennison]

Caffeine Junky wrote:
> On Thu, 13 Jun 2002 11:19:45 -0400, Ted Dennison wrote:
>>writing an OS. Thousands of security experts and script kiddies would be
>>looking for constructive things to do right now if Windows had been
>>written in Ada.
> 
> 
> I'm not so sure about that Mr. Dennison. One thing I've learned from my
> extensive experience with Windows(was an NT Admin for 4 years) and my
> regular perusals of the Bloatbusters hall of fame(www.radsoft.net) is
> that Microsoft can fuck up even the most trivial of applications,
> regardless of what language is being used.

:-)

Actually, though there is little room for doubt on this one. You 
*cannot* get buffer overflow exploits in Ada without disabling 
constraint checking (or using Unchecked programming). The worst that 
would happen is that all such attacks would turn into DoS attacks (as 
the constraint error takes your kernel down).

> Ada is an awsome tool. I use it alot now that I've finally gotten a
> handle on it. But it's no silver bullet. The only thing that can really

Actually, by Brooks' definition, its a "brass bullet". :-)

Re: newbie inquiry

[Darren New]

Ted Dennison wrote:
> Actually, though there is little room for doubt on this one. You
> *cannot* get buffer overflow exploits in Ada without disabling
> constraint checking (or using Unchecked programming).

Nowadays, I think it's a minority of security breaches that take advantage
of buffer overflows. Inappropriate scripting certainly wouldn't be solved
solely with Ada.

For example, the security hole whereby Netscape 4.x sends the URL of the
previous page as the referrer to the next server even when you didn't get to
the next server by following a link has nothing to do with buffer overflows. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: newbie inquiry

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3D096346.F92BEF64@san.rr.com>...
> Ted Dennison wrote:
> > Actually, though there is little room for doubt on this one. You
> > *cannot* get buffer overflow exploits in Ada without disabling
> > constraint checking (or using Unchecked programming).
> 
> Nowadays, I think it's a minority of security breaches that take advantage
> of buffer overflows. Inappropriate scripting certainly wouldn't be solved
> solely with Ada.

Scripting is more of a virus issue than a security one. I suppose
someone could create themsevles a trojan to give themselves access to
a system, but that requires a culpable host to trick into running the
trojan for you. Thus its a much better technique for some kind of
scattershot mass attack (like viruses) than for targeting a specific
system. I believe crackers and "script-kiddies" still use buffer
overflow exploits as their stock and trade.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: newbie inquiry

[Darren New]

Ted Dennison wrote:
> Scripting is more of a virus issue than a security one. 

Err, viruses aren't a security problem?

> trojan for you. Thus its a much better technique for some kind of
> scattershot mass attack (like viruses) than for targeting a specific
> system. I believe crackers and "script-kiddies" still use buffer
> overflow exploits as their stock and trade.

Oh. OK, if you're talking about breaking into a *specific* system, yah, that
and social engineering.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.