From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ffe4fb1477fe67e6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Newbie Needs Ada Advice References: <1178212418.538270.283700@c35g2000hsg.googlegroups.com> <1178635220.859690.3310@y80g2000hsf.googlegroups.com> From: Markus E Leypold Organization: N/A Date: Tue, 08 May 2007 18:11:48 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:fnmLqaADGTv1+wfYOFxAfefXpK4= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.74.36.55 X-Trace: news.arcor-ip.de 1178640207 88.74.36.55 (8 May 2007 18:03:27 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!news.germany.com!storethat.news.telefonica.de!telefonica.de!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:15645 Date: 2007-05-08T18:11:48+02:00 List-Id: ezkcdude 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.