Re: A question to the APL vendors on Windows GUIs ...

Once (I think it was 1997) I visited a plenary session for a presentation on J
(it said) by Chris Burke. I remember it was a bit disappointing - my neightbour
had the same feelings, he said: "I thought this was about J". It was just about
Windows GUI's.


"Stephen Taylor <editor@xxxxxxxxxxxxx>" <StephenTaylorFRSA@xxxxxxxxxxxxxx> wrote
in message
news:0d6d0d69-d79d-436f-a5c0-4b3c2d858fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I've hestitated to enter this discussion because of my limited
experience writing GUIs. On the other hand, that is arguably why many
of us took up APL: to minimise attention to implementation details.
With GUI, as with so much else, I want usable results, not to master
its ten thousand aspects.

Jan Karman referred to things I've said about 'creolised technology'.
The term is not mine but David Edgerton's "The Shock of the New:
Technology and Global History since 1900". Edgerton describes how
African mechanics simplify sophisticated western cars to run in rugged
conditions, replacing complex parts with simple, locally-made ones.

Applications for use by very large numbers of unskilled people, such
as Excel, or Amazon.com, can justify investing heavily in GUI code for
even small improvements in usability. The applications I work on
cannot. Chrome, as they say, is for customers.

Worse: code volume and complexity harden software, reducing its
authors' ability to adapt it. In the systems I work on, that
adaptability is valued. Care must be taken to conserve it, to keep the
software soft. In principle there are usability gains available that
would justify the cost of writing more GUI, but not the added 'drag'
on further development. (The 37signals software team, that produced
Rails, writes eloquently on this theme. The Somerset car makers were
featured in their blog "Signal vs Noise".)

I've had a little prior experience with a Windows GUI. The developers
migrated the application from a mainframe in early PC days, and worked
out a framework for relating GUI forms and data records; it is
unlikely to represent the best that could be done now. Still, and
leaving aside the inherent difficulties of writing GUIs, clearly a
deep art, I was dismayed by the volume and complexity of the GUI code.
In particular I was concerned by:

-- extensive mapping between GUI controls and arrays representing
'records', with much explicit translation between enumerators and
corresponding text
-- flow of control obscured through callbacks defined far apart in the
code
-- extensive use of names to refer to parts of the GUI, making it hard
to move or adapt GUI code
-- names of controls unrelated to domain semantics, eg an Edit control
called E3 rather than Postcode

I missed the simplicity and brevity of punching arrays in the session.
Could GUI code not be more like that?

My current development project in V11 has given me a chance to try, as
I found no precedents for writing GUI in Dyalog using classes. I've
been able to derive fairly simple subclasses for Forms and controls in
which

-- controls manage their own labels
-- controls bound to database tables translate enumerators
-- form layout is defined by readable program code, not gestures with a
design tool
-- the application GUI is defined (1 large callback excepted) in a
single script
-- classes corresponding to business objects (eg Company) support their
own Edit and Display methods

This last gets me close to the session interface Morten remembers so
fondly. My prior GUI experience felt like working in a house of cards;
I daresay I'm clumsy. All the GUI structure had to be set up and set
running then interrupted before anything could be tested or used.
Disturbing parts of the structure meant patching it or rebuilding it.
In contrast I can now, in the session and with an empty stack type:

([]NEW Company 87).Edit

and a form pops up on which I can edit the record for that company and
save changes to the database. Similarly

({[]NEW Company w}¨87 92 105).Display

returns 3 HTML DIVs from which to compose a display.

The readable code for layouts -- no form designer tool used -- looks
like this:

Postcode.Posn <- 20 0 + 'BL' cnr Address

The Postcode edit field appears 20px below the bottom left corner of
the Address field.

With this kind of modularity I was able recently to rewrite the entire
outer GUI for the application in a day.

This is still a work in progress. I don't have experience in C# or VB
with which to contrast it. But the forms look sharp. The application
code is short, readable and makes minimal use of conventions. My only
devt tool is the code. This feels like creolised technology for the
first time since I left the session.

I expect much of this to appear in the programming cookbook we're
working on at Dyalog this year. In the meantime I'd be glad to hear
from anyone interested in this line of development.

Stephen Taylor
sjt@xxxxxxxxxx



On Jan 15, 6:00 pm, "Jan Karman" <*a...@xxxxxxxxx> wrote:
"Marv" <sm...@xxxxxxx> wrote in message

nothing, just a slick way to present your results (fortunately the results
won't
change with a GUI, although you have to wait a bit longer to see them);
creolization is my advice (please, have a look at the carmakers from Somerset
UK).



On Jan 16, 10:36 am, Morten Kromberg <mk...@xxxxxxxxxx> wrote:
On Jan 15, 11:28 pm, Gosi <gos...@xxxxxxxxx> wrote:

I would guess he means you make GUI interface to APL functions instead
of letting the customer type in the names of the APL functions.

Yes, sorry if I was a bit too metaphoric there. I see a the GUI as a
way to feed the APL functions at the core of the system with
arguments. I frequently long for the "open systems" that we used back
in the good old days before both GUI and "Full Screen" character
applications. Paying customers would log on to the APL system and type
things like:

1 3 5 DAILY, DATED 1 70 TO 12 79
PUT CURRENCY 'CBUSB,CBGBP'
TITLE 'COPENHAGEN BUY'
PLOT ABOVE

Today, this type of design is in the process of being rediscovered,
they call it an "Embedded Domain Specific Notation" and it is one of
the hot new ideas that "agile" people talk about when they discuss
solving the software productivity crisis :-)


.

Relevant Pages

  • Re: Win32 Service App for Terminal services
    ... GUI,and, if any GUI is needed, this must be regular user launched application ... service/daemon runs under the SYSTEM account and uses Mailslots as the ... Interprocess communication mechanism to communicate with the GUI application ... I assume they both ran under the same session (correct me if my terminology ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Matlab GUI newbye
    ... It's included in MATLAB and allows ... you to put various kinds of controls on the GUI (static text, edit ...
    (comp.soft-sys.matlab)
  • Re: Win32 Application development
    ... When you write to Winsta0, you are addressing session 0, which is ... Terminal Server, they will get a different session, with numbers ... > Windows application to work seamlessly with Windows terminal ... We want to make the GUI launch to the ...
    (microsoft.public.win2000.termserv.apps)
  • Re: Win32 Application development
    ... > On a Terminal Server, this is the physical console desktop, which ... > always runs in session 0. ... but it fails to lauch the GUI to the ... >> are launching the GUI to the wrong place? ...
    (microsoft.public.win2000.termserv.apps)
  • Re: New post install tidbits?
    ... >>Yep, I have the session KDE GUI the way I want it, but I get there ... Whereas your GUI login manager probably offers a choice of windowing ... environment (KDE, Gnome, Icewm, etc), using "startx" will look to the ... for each X session, but "startx" works fine for me. ...
    (Debian-User)