comp.lang.ada
 help / color / mirror / Atom feed
From: dennison@telepath.com (Ted Dennison)
Subject: Re: newbie inquiry
Date: 13 Jun 2002 08:19:45 -0700
Date: 2002-06-13T15:19:45+00:00	[thread overview]
Message-ID: <4519e058.0206130719.7e4a68e2@posting.google.com> (raw)
In-Reply-To: ae7rpt$kfi$1@bunyip.cc.uq.edu.au

"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)



  parent reply	other threads:[~2002-06-13 15:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-12 16:09 newbie inquiry Steven Shaw
2002-06-12 16:26 ` Jean-Marc Bourguet
2002-06-12 18:09   ` Pascal Obry
2002-06-12 19:50     ` Ed Falis
2002-06-14  7:27     ` Jean-Marc Bourguet
2002-06-12 18:04 ` Stephen Leake
2002-06-12 21:22   ` Mark Johnson
2002-06-12 18:05 ` Larry Kilgallen
2002-06-12 20:14 ` Jeffrey Carter
2002-06-13 15:35   ` Ted Dennison
2002-06-13 20:12     ` Freddy
2002-06-14  2:49       ` Ted Dennison
2002-06-15 21:38         ` Robert A Duff
2002-06-16 22:16           ` Ted Dennison
2002-06-13 15:19 ` Ted Dennison [this message]
2002-06-13 23:26   ` Caffeine Junky
2002-06-14  2:55     ` Ted Dennison
2002-06-14  3:29       ` Darren New
2002-06-14 18:56         ` Ted Dennison
2002-06-14 19:05           ` Darren New
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox