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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,470860aa3e635a7 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 02 Oct 2007 21:02:23 -0500 From: "Steve" Newsgroups: comp.lang.ada References: <13duou81kg3sd1c@corp.supernews.com> <13f3e0vbb05s47c@corp.supernews.com> <13f6eg0te46m2a3@corp.supernews.com> <4xsl4zw3bp.fsf@hod.lan.m-e-leypold.de> Subject: Re: GNAT for MS Visual Studio Date: Tue, 2 Oct 2007 19:03:23 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Original Message-ID: <5o6dnYC_A-KyZZ_anZ2dnUVZ_tSknZ2d@comcast.com> X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 24.20.111.206 X-Trace: sv3-YbpUbPrysE/nGE5kakVgtzqTghLqDLOwKTuhyAmNCQsiE0Qg4tABiMh91V5GGWeJqXgJW1F/RwHUkwJ!H2BjTu6C9vH8EsHGyTcVOpJEWO0GRQJTL8sTKRkIP9uIzlKs3iSSSYSeYsREuD/by+3n2UN/hij1!1raUnzti1WEpbSceFEbuMsItM9h4lw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.35 Xref: g2news2.google.com comp.lang.ada:2261 Date: 2007-10-02T19:03:23-07:00 List-Id: "Randy Brukardt" wrote in message news:fdsf0r$q0t$1@jacob-sparre.dk... > "Steve" wrote in message > news:YcCdnaCp_dEWKmLbnZ2dnUVZ_qqgnZ2d@comcast.com... > ... >> > That is perhaps the main point in my slightly jumbled commentary: GUI >> > builders don't allow you to build abstractions. Using GUI builders >> > doesn't scale and doesn't promote reuse (of GUI subsystems). >> >> With the .NET framework you can create a base form and derive other forms >> from the base form. If that doesn't promote re-use, I don't know what > does. > > Whether that is really reuse depends on what you mean by "derive". If the > derivation is one-time (a copy), then there is little effective reuse, > because every change to the base would have to be manually reflected in > the > copies. (This is the only kind of derivation I have seen in GUI builders, > admittedly I haven't looked at many.) And as you have pointed out, a > system > that doesn't change is not very likely. > What I mean by derive is in the sense of deriving classes. A "form" in .NET is derived from a base form class. You may add various controls to a form using visual tools. When you derive one form from another, you get the controls from the original form in addition to any controls you add to the derived form. If you add controls to the base form, they show upon all of the derived forms. > OTOH, what I want (and have done in some of my Claw programs) is to create > a > dialog (could call it a form if you like) that takes parameters. In my > case, > it was a name and a registry location. Thus, the dialog would work the > same > way for each use, but get data (and have an appropriate title) from > different locations for different uses. It turned out that writing that > abstract GUI module by hand (once) allowed it to be used twenty or so > times: > in GUI builder code. And of course fixing a bug in it will fix all of the > uses at once. With .NET to create a form you create an instance of a class and call the ShowWindow method. After creating the instance you can do anything you want to tailor it's behavior prior to calling ShowWindow. > > I could have used the GUI builder to create it, but I would have ended up > with twenty copies that would each have to have been changed for any minor > correction -- which hardly would have saved any development time. > > ... > ... >> If the effort to develop a GUI interface takes days, weeks, or months. >> Careful design is critical. The resources invested in development are >> significant, and it is important to get it right the first time. >> >> If the effor to develop the GUI part of the interface takes minutes, > careful >> design OF THE GUI is less critical. The design of the business part of > the >> application is still critical, but since changing the GUI is trivial it >> becomes less importaint to get it right the first time. > > But there is no possibility of the GUI taking minutes. You have to at the > very least type in the names of the labels for the controls/widgets, > possibly define some of the data types, etc. Only the very smallest GUIs > can > be done in "minutes". (There is one exception: the direct conversion of a > record type into a dialog, which can be automated if you don't care about > the result apperance. But that only would work for very simple systems - > no > menus or dynamism is possible for that.) What I should have said was something like GUI elements. Certainly creating an entire interface will take more than minutes, but creating each individual form may only take minutes. Creating the entire interface may take days or weeks with a high level tool. > ... >> In my programmers Utopia, a GUI Ada tool would magically appear. > > You should say "an Ada GUI tool THAT I FIND ACCEPTABLE", because of course > there are many Ada GUI tools out there. You said you tried them and didn't > like them, which surely is a reasonable opinion, but you should at least > acknowledge that others may find them quite useful. > I acknowledge that these tools may be useful. But the fact that some programmers consider hand coding to be comparable to using the tools is not a strong indication of their usefulness. >> People (like me) who constantly experiment with different development > tools would >> try it and discover the wonders of Ada. The market share of Ada would > grow, >> Ada vendord would thrive, and Ada would gain mainstream acceptance. > > My experience in the Ada business suggests that no single 'X' could be a > magic bullet that would increase the acceptance of Ada. If you actually > tried to make 'X' available, by the time you got it done, the world would > have moved on. (i.e. Claw). If there is any magic way to increase Ada > usage, > it would be to get ahead of the curve on something (multi-core comes to > mind: us Ada people have been doing that sort of programming for 25 years) > and market it for all it is worth. > I agree there is no magic bullet. But there certainly are a number of impediments that may be removed. I have watched a number of obstacles to choosing Ada disappear as the language has evolved: Ada 95 - Added OOP (tagged types) - Added protected types - Added interfaces to other languages Ada 2005 - Added interface inheritance - Added a standard container library > But my personal, cynical view is that Ada cannot really succeed, because > few > are really interested in doing things well. (IMHO, that's what's Ada is > really about, even if we don't always get that right.) Most only care > enough > to hack something out to get by. And Ada will never be about hacking > something out. > Personally I try to be more optimistic. We have all seen things change radically in relatively short periods of time. Remember how quickly Java (formerly Oak) came to the forefront? There have been echo's of SPARK in the popular computing magazines that have interested people who are tired of many of the software development mishaps that seem to be happening these days. Maybe the folks at Microsoft will get tired of trying to patch Windows using programming languages that are inherently unsafe and give Ada a shot on a pilot project. You never know. Steve (The Duck) > Of course, there are enough people who do care about doing things well to > keep Ada around. But it probably will remain a niche language. > > Randy. >