Re: Newbie Needs Ada Advice

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

ezkcdude <zamir.evan@gmail.com> writes:

> Markus, thanks for the advice. I'm one of those people who loves to do
> the "right" thing, and it seems to me like Ada is, in theory, a great
> programming language. Of course, one has to be practical. The main

In theory.

> issues that I am trying to wrestle with is how I would implement a GUI
> and, in general, handle graphics (display, manipulation, input/
> output). 

I've been using GtkAda in the past. It is workable, but one has to
realize that GUIs are a problem in themselves: Lot's of
text-to-whatever-type conversion when you read stuff from the GUI back
into your program (and if you have, say 70 fields of all different
types in you program that means you have (at least) 140 functions
text->typed data and typed-data->text. Some kind of generic,
meta-programming or generation from definition obviously must take
place then.

GUIs are also rather stateful and inherently concurrent (you cannot
prevent the use from clicking button X while you're processing another
data entry event that might disable X).

It boils down to the result that GUIs introduce a huge load of
complexity into programs where a sequential interaction would be
trivial.

About GtkAda: 

 - Docs: The docs are somewhat spurious: You have to be able to read
   the original Gtk-Docs against them and then you still have to be
   able to read the source to find out what really happens. Good
   examples are rare.

 - License: Is pure GPL whereas Gtk is LGPL. This might not matter to
   you, but I've really been bitten by the license change from GMGPL
   with linking exception, and further enraged by the abolutely
   surreal prevarication I got from AdaCore (always offensively trying
   to imply that there never was a linking exception w/o actually
   saying so -- probably because this would have clashed with the hard
   evidence :-) when asking when the license change took place -- so I
   won't forget to mention it here.

 - Portability: last time I checked, GtkAda only worked with Gnat (and
   specific versions too). So you'll be locked to Gnat (probably)
   which opens up all those can of worms with the different licensing
   and maturity of the compilers (which you should try to research for
   yourself, since that is a really long story).

> Java seems much more ready-made for these tasks at the moment, and I
> don't see the Ada packages have that much enthusiasm or
> support. It's unfortunate, because like I said, Ada seems like the
> "right" language to me for most of what my objectives are.

c.l.a folks will now hate me: Have you considered a language like
Ocaml? As with Java there is garbage collection, which is a real boon
with a dynamic GUI, the lablgtk docs are comparably good and the
functional style of programming interacts really well with GUI
programming.

> One idea I have, and I'd love to hear advice or comments, is to use
> Ada as the "engine" for my program, and somehow use Java to create the
> GUI and deal with images. Does this seem like a possibility?

"Remote widget protocols" like this (i.e. haveing a separate process
as display server to which you talk in a high level protocol and
instantiate complete widgets) have been created in the past (wether in
Ada I don't know). Perhaps you can find some information about this
somewhere. it is certainly an option, but you'll still have the
necessity to design the protocol (not so easy) and a useful GUI
abstraction (though that might not be as difficult as it looks, since
you would probably try for an application specific GUI abstraction.

And never forget: Don't believe me. Do your own research to bolster
whatever you gather from what I say. There are much too many unfounded
assertions floating around in usenet.

Let me add a personal judgement: 

| I'm one of those people who loves to do the "right" thing, and it
| seems to me like Ada is, in theory, a great

I suspect that Ada is not the right language for a lot of things any
more. "Right" is defined by the context and what is available, also by
who has to maintain the code later. Going for a dual-language strategy
on a non-embedded platform seems to me the right thing today: A
language with garbage collection and type system you're comfortable
with for the high level stuff and C for the lowlevel / driver stuff
(of course you have to know how to write C ... :-). The high level
language should work with Gtk or another portable toolkit
(wxwidgets? Qt? Any other?).

Suggestions are:

  - Phyton + C: Very popular, but no type systems. Rumoured to be
    slow. Good syntax (i.e. readable)

  - Perl + C: Very large number of libs in CPAN, but lots of them of
    dubious quality. Bad, really

  - Ada + C: No GC in Ada (you can add the Boehm collector
    though). I'm doubtful about continued (and comparable and
    affordable) support on Unix AND Windows platforms.

  - Java + C: Never tried native function interfacing in Java, but its
    rumoured to be possible. I don't like the "everything is an object
    way though". It makes for clumsy callback definitions and Java
    before 1.5 is definitely hampered by the absence of parametric
    polymorphism or generics (which you need to define generic
    containers in a type safe way).

  - Of course the C#/.NET/Mono way: I've even seen projects that
    intended to GUIs for operating machines that way.

The '+C' seems to be a constant. If you want to program portable GUIs
(i.e. on Windows and Unix) the most efficient approach would be to look
for the protable GUI toolkits (not many), then look for their language
support, look how mature and maintained it is (that kicks all
languages that have had one Gtk-whatever release 2 years ago and than
never again) and you're left with only a handful.

The other possible approach is, of course, to write a "control kernel"
in some suitable language and interface it with a suitable GUI by
sockets and/or pipe with some out-of-the-box or even self styled RPC
mechanism. You already mentioned that.

Regards -- Markus

PS: And please don't top post.