Suitability of Ada as a general-purpose language

On 30.07.12 17:26, Dufr wrote:

> My worry, which I hope you can dispel, is that the compiled code of my
> (subset-)Ada program may still be less efficient in term of executable
> file size and of execution speed.

Why would that be? Ada was designed so that it would be good
for hard real-time systems. Responsiveness and compact code
are a must. Overhead is an enemy. Checks can be controlled.

Fewer features (of a profile/subset) may even mean a smaller
run-time system.

> Just for a reality check, how big is the executable file of the Hello
> World program? (in simple text mode to standard output).

The size of an executable will depend on whether the run-time system
is a dynamically linked library as usual, or whether you link all
of the Ada run-time system (and other libraries). A few ten KiB
in the first case.


> Also, would there be really so much syntax overhead (verbosity, for
> one), even if I decide to use only a subset of the language (leaving
> out advanced features like concurrency etc)?

An Ada subset means fewer features, but the amount of syntax adding
to its readability is not changed much. Usually, having to clearly
state their wishes as program text helps the programmers to (later)
actually understand what they have written.

On Mon, 30 Jul 2012 09:07:29 -0700 (PDT), Ludovic Brenta wrote:

> Cons of Ada relative to Pascal:
> - object-oriented features are implemented in a way quite unique
> among programming languages.

If under uniqueness you understand consistency, then yes, Ada is unique in
that regard, at least among OOPLs I know.

> You may have to re-learn OOP if you
> know it from another language and you may find the Ada way counter-
> intuitive.

They should learn that some things they took for granted were wrong. OO is
not the only thing Ada does right where other languages messed up. You
already mentioned Pascal syntax issues (else- and semicolon-problems etc).
It is difficult to find something that Borland Pascal does better than Ada.
Certainly, not OO. Maybe the finally-clause? Though I do not like it
either. Even the IDE is now worse comparing to the GPS.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

BTW Dufr

If it's not a secret, maybe you could tell people what sort of libraries you normally use, you might get some good pointers about using them from Ada

On Jul 30, 8:03*pm, Patrick <patr...@spellingbeewinnars.org> wrote:
> BTW Dufr
>
> If it's not a secret, maybe you could tell people what sort of libraries you normally use, you might get some good pointers about using them from Ada

Actually, I have not been programming much as yet. I expect to find
the libraries that I need within the Ada userland. What I expect to
need, at this early stage, are libraries for text processing, which I
guess are available as native Ada libraries. Then I may need some
basic (client-side) email functionality, and some library that allows
me to retrieve webpages and ftp resources. Any suggestion on these?

hmmm. The other list members will be able to provide better answers but some quick thoughts...

I think the Ada curl binding might be out of date. It would however be very easy to write a few functions in C and then call them from Ada and utilize CURL this way.

Perl like text processing will not be good. You could do the same for the PCRE C library as mentioned for CURl or if you want to write a real parser, Ada's rich data structures and good proformance would make this ideal.

Don't know anything about email code..

HTH

On Mon, 30 Jul 2012 08:26:23 -0700, Dufr wrote:

Of these two languages, I see Ada as stable or increasing in usage, and
with better long term prospects.

> However, I have not been able to make up my mind on one point: would I
> have to pay a penalty in terms of performance and efficiency if I
> decided to use a large language like Ada, even if only a subset of it?

In performance terms you will lose nothing with Ada, and probably come
out ahead vs Pascal. (There are probably fewer people caring about Pascal
tools and tuning them.)

Executable size is a poor measure of efficiency; the Ada runtime system
(RTS) provides a LOT of facilities that "Hello World" doesn't need. Any
decent sized application will need them, whatever language it is written
in.

It is probably not worth crafting a specially small RTS just to make Ada
look good on "Hello World" benchmarks! However it could be done... the
AVR-Ada compiler for tiny embedded processors has effectively no RTS, and
I am seeing executables of 1K or so to control two stepper motors (Arduino
+ Motorshield).

> Also, would there be really so much syntax overhead (verbosity, for
> one), even if I decide to use only a subset of the language (leaving out
> advanced features like concurrency etc)?

Versus Pascal : not much. Versus C or Perl? A lot but it's worth it :-)

- Brian

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
news:jv70gq$v6u$1@dont-email.me...
....
> Executable size is a poor measure of efficiency; the Ada runtime system
> (RTS) provides a LOT of facilities that "Hello World" doesn't need. Any
> decent sized application will need them, whatever language it is written
> in.

Right. We used to tell people that back in the early days of Ada, but few
people bought that argument.

> It is probably not worth crafting a specially small RTS just to make Ada
> look good on "Hello World" benchmarks! However it could be done...

It's not really the runtime so much as to how smart the binder is at not
including unneeded stuff. Janus/Ada has subprogram-level trimming of all Ada
code and the entire runtime; we got executables in the 5-7K range on MS-DOS.
For Windows, we can't do as well, because we get all kinds of cruft from the
OS interface. But it's still reasonably small. After all, hardly any program
uses all of the routines in Text_IO (in programs we checked, the average was
less than 40%). Janus/Ada also trims subprograms that are primitive for
tagged types but never called (this requires tracking dispatching calls) --
we did that to make Claw programs have sane sizes.

The real problem is having to use system linkers, which never have the
needed facilities (at least, not facilities that actually work). Janus/Ada
always pre-links the Ada code in order to do proper trimming, but that adds
a step so I understand why other compilers don't use it.

Of course, this effort is worthwhile on any program where the size is
relevant; it's just not silly benchmarks (although its more obvious with the
benchmarks).

Randy.

On Monday, July 30, 2012 8:45:45 AM UTC-5, Vasiliy Molostov wrote:

> cons is that you will stuck with c.l.a.

Given the signal-to-noise ratio here due to the wide breadth of experienceddevelopers that frequent this newsgroup, I'm hard-pressed to see how relying on c.l.a. for Ada assistance could be considered a "con"!

Even so, it's not the only choice. Tagging a question on StackOverflow withthe "Ada" tag (http://stackoverflow.com/questions/tagged/ada) will bring it to the attention of a small cadre of experienced Ada developers. And the Ada subreddit (http://www.reddit.com/r/ada)is an ongoing source of links toAda news, projects, and announcements.

Ada has a presence on SourceForge, GitHub, and RosettaCode, providing a rich source of Ada examples for use and learning.

There may not be as many "Ada Articles" as there are for other programming languages, but there's a lot fewer garbage articles and information.

Marc A. Criley
Ada Sub-reddit moderator

On Monday, July 30, 2012 12:43:46 PM UTC+1, Dufr wrote:

> I have a dilemma: whether to learn Ada or Delphi/Object Pascal (I have a only Pascal background, and I wish to stick with Pascal-like languages). My target would be to write day-to-day (business, educational, etc), relatively simple desktop applications.

I have and always will maintain that with Pascal you are limited as to how far you can go, standard Pascal doesn't have a lot, so you have to rely on different dialects. Whereas with Ada the language will grow as you do.

Also, even though you cannot really judge a language on the size of it's hello world program and how that size compares to other languages, I thought I'd do a test on 32-bit debian:

with ada.text_io; use ada.text_io;

procedure hello is
begin
put_line ("hello world");
end hello;

$ /usr/bin/gnatmake -O2 hello.adb
$ ls -l hello
-rwxr-xr-x 1 laguest laguest 16563 Aug 2 00:39 hello
$ strip hello
$ ls -l hello
-rwxr-xr-x 1 laguest laguest 9128 Aug 2 00:39 hello

and then:

$ /usr/bin/gnatmake -O2 hello.adb -cargs -fdata-sections -ffunction-sections -largs -Wl,--gc-sections
$ ls -l hello
-rwxr-xr-x 1 laguest laguest 12842 Aug 2 00:43 hello
$ strip hello
$ ls -l hello
-rwxr-xr-x 1 laguest laguest 8584 Aug 2 00:43 hello

Should give you an idea.

Luke.

Le Tue, 31 Jul 2012 06:19:58 +0200, Randy Brukardt <randy@rrsoftware.com>
a écrit:

> "Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
> news:jv70gq$v6u$1@dont-email.me...
> ...
>> Executable size is a poor measure of efficiency; the Ada runtime system
>> (RTS) provides a LOT of facilities that "Hello World" doesn't need. Any
>> decent sized application will need them, whatever language it is written
>> in.
>
> Right. We used to tell people that back in the early days of Ada, but few
> people bought that argument.

(playing the devil's advocate)

Does that mean that “not decently sized� applications are not Ada's
target? Then, any one can define what “decently sized� is? It's not fair
that when a compiler fails in an aspect (an aspect which is not relevant
to its main audience, I agree), to get the point away with pretexts.

The Hello World program here, is a place‑holder for tiny applications.
There may be good reasons for people to expect tiny applications to have
tiny executable images: there may be a lot of them, whose size cumulates,
and they may be launched often for a short time, in sequence; better a
tiny executable image here. Then, the big Hello World image can give
people an honest enough feeling of bloating or else poor dependencies
management capabilities.

GNAT producing big executable images for tiny applications, and GNAT
purpose not being at producing efficient executable image for that kind of
application, is not a reason to push that issue away.

--
“Syntactic sugar causes cancer of the semi-colons.� [1]
“Structured Programming supports the law of the excluded muddle.� [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

On Fri, 03 Aug 2012 21:21:15 +0200, Yannick Duchêne (Hibou57) wrote:

> Does that mean that “not decently sized� applications are not Ada's
> target? Then, any one can define what “decently sized� is? It's not fair
> that when a compiler fails in an aspect (an aspect which is not relevant
> to its main audience, I agree), to get the point away with pretexts.
>
> The Hello World program here, is a place‑holder for tiny applications.
> There may be good reasons for people to expect tiny applications to have
> tiny executable images: there may be a lot of them, whose size
> cumulates, and they may be launched often for a short time, in sequence;
> better a tiny executable image here. Then, the big Hello World image can
> give people an honest enough feeling of bloating or else poor
> dependencies management capabilities.
>
> GNAT producing big executable images for tiny applications, and GNAT
> purpose not being at producing efficient executable image for that kind
> of application, is not a reason to push that issue away.

You make a good case. And I am seeing executables of under 1K on the AVR,
so it is definitely possible (though without much library or any RTS).
I haven't tried linker settings or "strip" or other tools to see how
small an executable I can get on Linux.

But reducing executable size shouldn't be something we have to work to
achieve; the tools should do it for us. Randy points out that non-Ada
specific tools may not be well suited to helping us...

- Brian

Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> пи�ал(а) в �воём
пи�ьме Fri, 03 Aug 2012 23:21:15 +0400:

> Le Tue, 31 Jul 2012 06:19:58 +0200, Randy Brukardt
> <randy@rrsoftware.com> a écrit:

> Does that mean that “not decently sized� applications are not Ada's
> target?

Ada main target are processors (hardware), while typical "Hello world"
rely on console output and/or libc stdout file operations (e.g. implies
file system operations, including mapping of errno to exceptions and the
rest), and therefore it is for testing something about related to high
level I/O primitives and are environment dependent. So, the test to
establish and compare sizes of "Hello World" executable is dumb (due to
irrelevant conclusions about result).

To get the benefit on image size a developer can restrict compiler with
usual basic operations, e.g. to build "The Hello World program here, as a
place‑holder for tiny applications" a developer can import I/O operations
similar to competitors (since test environment is the same, I suppose),
e.g. using puts(3) from libc instead of ada.text_io.put_line. In this case
you might want to discover that these image sizes are closest to be
similar to ones in C. With more ada related restrictions applied to ada
compiler you can get image sizes even smaller than you can imagine.

How much Ada with gcc (e.g. GNAT) can take in image size was tested by
Stephane Carrez
(see http://www.vacs.fr/wiki/index.php/VA...s:Software:Gel - "GNU
Ada compiler works for creation of a 256 bytes program"), obviously clear.

Regarding to Janus, on some targets its run-time is based on direct
interfacing with environment, and the resulting image size can be even
smaller than the same in C (where libc acts as an interface to the same
environment).

As you can see, ada is just more flexible than C (or any other competitor)
in building images of any desired/required size, and even makes this
comparison incorrect and meaningless.

--
�апи�ано в почтовом клиентебраузера Opera: http://www.opera.com/mail/

Marc C <mc.provisional@gmail.com> пи�ал(а) в �воём пи�ьме Tue, 31 Jul 2012
18:28:58 +0400:


> On Monday, July 30, 2012 8:45:45 AM UTC-5, Vasiliy Molostov wrote:
>

>> cons is that you will stuck with c.l.a.

>
> Given the signal-to-noise ratio here due to the wide breadth of
> experienced developers that frequent this newsgroup, I'm hard-pressed to
> see how relying on c.l.a. for Ada assistance could be considered a "con"!


> Marc A. Criley
> Ada Sub-reddit moderator


It was a joke of course, ada is everywere for now.

--
�апи�ано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Dufr wrote:

> What I expect to need, at this early stage, are libraries for text
> processing, which I guess are available as native Ada libraries.

Depending on what you mean by text processing, you may find them in the
standard libraries, as a part of the GNAT libraries or as third-party
Open Source libraries.

> Then I may need some basic (client-side) email functionality, and some
> library that allows me to retrieve webpages and ftp resources.

AWS has these features included.

Greetings,

Jacob
--
"USA fights for the right of the individual."
"Yes. Those of the individual George W. Bush."
-- with thanks to Olfax

Dufr,

> Actually, I have not been programming much as yet. I expect to find
> the libraries that I need within the Ada userland. What I expect to
> need, at this early stage, are libraries for text processing, which I
> guess are available as native Ada libraries.

Ada.Text_IO.*
Ada.Strings.*

GNAT.AWK
GNAT.Regexp
GNAT.Regpat
GNAT.Spitbol.*

> Then I may need some
> basic (client-side) email functionality,

AWS.SMTP.*

> and some library that allows
> me to retrieve webpages

AWS.Client.*

> and ftp resources. Any suggestion on these?

Don't know for ftp.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B