Re: Newbie Needs Ada Advice

[ezkcdude <zamir.evan@gmail.com>]

On May 8, 11:11 am, Markus E Leypold
<development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote:
> ezkcdude <zamir.e...@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.

Sorry about the "top posting". I never really thought about that.

As for your reply, thanks, so much! You guys are awesome. I'm not sure
I'm any closer to an answer, but at least, I know a lot of the
questions involved. At this point, that's enough for me.