Re: GNAT for MS Visual Studio

["Steve" <nospam_steved94@comcast.net>]

"Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
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