I completely agree that the core functionality
should
not be dependant on the GUI. But since the GUI is
likely to be larger, more difficult, and much more
influenced by OS/toolkit/user considerations than
the
‘core’, it’s something to develop over the whole
life
of the project rather than add as an enhancement.
Do customers (of software) pay for core
functionality, or
the GUI?
Well, in the case of ‘Gui-focused’ software, which is
what I was discussing, and which is also the case in
which the GUI is likely to be more interesting, more
complex, and less easily developed with existing tools
available to Ruby, then the answer is, as far as I
know, ‘yes’.
This ‘yes’ may frequently be delivered at high volume,
although in some cases the message still doesn’t seem
to propagate as well as one would hope.
I think that applications that get driven by their UI
rather than the functionality the software is
supposed
to deliver are doomed to fail (at least, relative to
any competing application which isn’t UI-bound).
Hmm… I can think of many real-life examples of
successful UI-focused applications, but I don’t think
the distinction you are making between ‘driven by UI’
and ‘driven by functionality’ is valid for
applications whose UI is the majority of their
functionality.
I feel that the distinction you are making between
‘real’ functionality and the GUI is very much a
product of one particular software environment.
Within that environment, perhaps it makes sense to
‘extend’ an existing application with a GUI, and
perhaps you can expect the GUI to always take up much
less effort than the ‘real’ functionality. This is
not, however, a general truth.
If the GUI is “larger, more difficult, and much more
influenced by OS/toolkit/user considerations”, is
this
necessary or is it coincidental?
It is necessary, as far as I know. In an application
such as a real-time trading system, for instance, if I
found back-end code was bigger or more complex GUI
code I would know something was BADLY WRONG with the
back-end. Or that some silly person had placed what
is really business logic belonging on the server in
the back-end of the client. But enough about my
troubles…
do think it’s an easy trap to fall into to say that
“the UI is the closest layer to the user andtherefore
the layer the user will be most critical of, so it’s
the most important layer to do well”
How very true. I myself often find myself saying,
“The UI takes up 95% of the specification and 80% of
the code, is the only part that’s difficult, and is
the only part anyone outside this office cares about,
so it’s the most important layer to do well.” I must
remember to slap myself on the wrist when I catch
myself thinking that way :>
The next thing I think is usually “I wish I could do
it in Ruby!” – but I can’t, because everyone who
makes Ruby GUI tools is busy making stuff for bolting
on X dialogs to existing programs 
x