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@[EMAIL PROTECTED]
>" <StephenTaylorFRSA@[EMAIL PROTECTED]
>
wrote
in message
news:0d6d0d69-d79d-436f-a5c0-4b3c2d858fe2@[EMAIL PROTECTED]
'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@[EMAIL PROTECTED]
Jan 15, 6:00 pm, "Jan Karman" <*a...@[EMAIL PROTECTED]
> wrote:
> "Marv" <sm...@[EMAIL PROTECTED]
> 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...@[EMAIL PROTECTED]
> wrote:
> On Jan 15, 11:28 pm, Gosi <gos...@[EMAIL PROTECTED]
> 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 :-)
|
