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: Sun, 30 Sep 2007 09:49:47 -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: Sun, 30 Sep 2007 07:50:41 -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: X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 24.20.111.206 X-Trace: sv3-MXKLqfA28ViacyqbGrT6mXT8ikPWnRgYRP3RB/tlenmCCLojp12qv4OmC55IPFbtlhLzVsRHR0JYQ3H!FoKt6JuVV6riFefDGxue4YtaEISVG2shD0Aj1k2XT127Dj4tNHdxPKT8C6WBnKgHNsjUDCSmgCDH!lqflJFrcvcyBdVixHU+d6WV8eCXY8w== 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:2237 Date: 2007-09-30T07:50:41-07:00 List-Id: "Markus E L" wrote in message news:4xsl4zw3bp.fsf@hod.lan.m-e-leypold.de... > > "Steve" wrote: >> >> To me that's too much like asking the question: >> Have you seriously considered not using a programming language and >> compiler and just programming in machine code? > > I thought so. Hence (a) my comment that you're caught in this > Microsoft mind set and (b) my attempt to make you reconsider: The > relationship between a Toolkit and a GUI builder, IMHO, is not > analogous to that between assembler and a ("high level") programming > language. > BTW: I mentioned to my co-workers that I had been described as being pro-Microsoft. They laughed out loud. You certainly have the wrong idea. IMNSHO the tools and techniques for software design and development continue to change over time. It is important be aware of and keep an open mind about new methods as they appear. Not doing so will render you obsolete. Every time the next great tool comes out, I take note. First I don't spend much time learning the details, since many of these great revelations fade after a short period of time. But after the tool has been out for a while I investigate it on my own, ignoring they hype, and make my own judgement as to whether or not the tools is really a good thing. This is how I came to appreciate Ada, and this is how I came to appreciate visual GUI development tools. > The thing that comes into my mind is, that (a) the requirements should > have been fixed much earlier and (b) restructuring is handled by > moving constructor calls. That works well for software requirements that are static, and don't evolve over time. > Furthermore the very situation that is difficult to handle, that you > have integrated widgets into an abstraction (like "customer data > browser") cannot be handled with GUI builders at all and in this > situation it is improbable that you will move widgets over the > abstraction boundary. > > So then w/o a GUI builder I'm only moving a call > > New_Cusomer_Browser(...) > > to another place, with a GUI builder I haven't built an abstraction > from the very beginning. > > 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. > If editing code is a pain for you, then you have a point. Only that I > personally, don't trust programmers that have a difficult relationship > to editing code -- it's their business. > My business isn't editing code. My business is producing and maintaining applications in the most cost effective way possible. Sure programmers can create code for maintaining GUI's with code. They can also write their own databases and code in machine code. But usually the most cost effective way to develop things is to take advantage of high level tools that do much of the job for you. With a decent GUI development tool I can generate most of the code required to maintain the GUI automatically. Doing so by hand is ceratainly possible, but it is much less productive. If the tool doesn't sigificantly reduce the amount of effort do generate the UI... don't use it! It's not a good tool. If the tool does significantly reduce the amount of effort to generate the UI, you don't use it, and you're in a competetive environment, you won't continue to compete for long. > W/o knowing the details it's hard to say what went wrong. Of course > structuring GUIs so that they stay maintainable is an art on itself, > very much like structuring programs so that they stay maintainable > (the key is modularization). > 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. In my experience there have been may occasions where conventional wisdom has been to present information a particular manner. Then for some unforseen reason a different view of the same information that is much more intuitive comes to light. If the GUI is independent of the business part of the application it isn't a big deal and it is tivial to adapt. If the GUI is closely tied to the business part of the application your hands may be tied. > That _only_ works, if you're having something that resembles paper > forms, which in turn IMHO hardly deserve the name GUI. But if you > e.g. have a browser for status records for network nodes, you'll > hardly ever move GUI elements from there into some other context, > since you need access to the network nodes status to show the widget > element. > In my experience the GUI builders do most, but not all of the work for you. You still have to write code for the pieces that tie things together. With a good GUI builder, more than 90% of the GUI code will be generated automatically. > Which gives me the idea that GUI builders tend to promote spaghetti > code in the underlying application. Spaghetti code can be generated equally well by either technique. >>> GUI builders are fine if you're programming for paper-shufflers: >>> Everything is a "form" than, as it was in the time of paper forms. >>> >>> But interactive software needs to be smarter -- and that is what GUI >>> builders can't provide in my (admittedly limited and perhaps dated >>> experience). So if I end up anyway not being able to use the GUI >>> builder, I could as well learn how to use the tool kit in the language >>> proper. >> >> If the components that are placed on forms are dynamic, and there is >> automatic interaction between the components on a form (like there is >> with >> .NET) then things can be very dynamic. > > If you define this as "dynamic", yes. I doubt really complicated stuff > can be specified by interacting with the mouse. > You may still have to do a little coding to handle the dynamic parts. But just because you have to write 50 lines of code by hand, doesn't mean you can't have the other 500 generated automatically. >> Most of the applications I work on have to do with sawmill automation. >> Scanning logs at various stages of processing and optimizing the >> breakdown >> decisions and process. The application requires a lot of configuration >> to >> describe the machinery, the products being produced, and rules on how to >> cut >> things. There are dozens of dialogs in the system. > > Dialogs. Complicated, sequential forms. No direct inteaction > interface. There you are. > A pretty quick judgment for never having seen our application. >> Trying to maintain these using hand coded windows is just plain >> silly. Parts of the system are very dynamic... displaying 3d images >> of material being processed, diagnostic information, etc. > > This is not what I call dynamic. Describe just what you conder to be dynamic. > BTW: Nobody asked you to maintain your system "using hand coded > windows". If you don't want and have a GUI builder, please don't. But > you asked for a GUI builder that isn't there, implicating live is to > complicated w/o one. I still doubt it is. The viewpoint you are presenting reminds me of a paper that circulated on the Internet many many moons ago. It was entitled something like "Real Programmers Don't use Pascal". IIRC it said something like: Real programmers don't use Pascal, they use FORTRAN. If it can't be programmed in FORTRAN they use machine code. If it can't be programmed in machine code, it isn't worth doing. In my programmers Utopia, a GUI Ada tool would magically appear. 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. Regards, Steve (The Duck) > > > Regards -- Markus