Re: Focus Drive //e woes

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> Since 99% of the voluminous code is just managing the quirky
> GUI interface, and the only end result is writing out a block
> containing the partition table, it shouldn't be too hard to do
> on a //e.  But at the time, I recall having a hard time even
> *finding* the structure and content of the partition table!
> (I should try to find those files and see if I can figure it
> out now...)

Reminds me of back around 1990 I ported a mathematics application I
wrote in UCSD Pascal on the II to the Macintosh. The guts of the
Application had only about 3k lines of code, but the user interface
that I bolted to it (The simplest one I could devise I might add) added
ludicrous amounts of code.

A friend wanted to port it the IIgs, but my attitude was why bother,
the UCSD version runs fine ;-)

> Since in the interim I had picked up a IIgs, I dropped the effort.
>
> For me, it came to embody the fundamental problem of GUI-oriented
> code:  huge effort and complexity in managing the GUI compared to
> tiny effort on functionality.  The functionality of partitioning
> could be captured nicely--with a very usable text interface--in
> about 200 lines of Applesoft!

I won't go as far as some and say the GUI's are bad, but I decided a
long time ago that using an imperative language to describe a visual
interface was a terrible design idea. User interface definitions are
only just barely succinct when done declaratively, and it takes a
combination of a readable declarative language and excellent visual
design tools to do it well.

The only system I've seen that did it reasonably well was NeXTStep, and
that was 15 years ago. I don't know enough about MacOS X to know if
that legacy has been kept alive.

Once thing is for sure - a lot of R&D needs to be done on UI
development to get the process efficient and maintainable.
Unfortunately most of the qualified engineers are busy writing code
that actually *does* something ;-)

Matt