In article <[EMAIL PROTECTED]>,
Mark Carter <[EMAIL PROTECTED]> wrote:
.
.
.
>Don't start me! Dammit, too late ...
>
>I've noticed that they have an overwhelming obsession with GUIs, too.
>They design wizards for everything. Damn pretty they are, too. Albeit a
>bit flakey. They seem to conflate pretty interfaces with good interfaces
>and good software.
>
>I used to joke that since our software wasn't particularly magical, it
>didn't need wizards. But I think I just ended up sounding bitter.
>
>We once had a bit of software that we thought we'd like to turn into a
>generic application. The focus on improvements was, predictably enough,
>that we should design a GUI that could do anything a client would likely
>to want to do. It was my opinion, though, having seen the very
>"special-cases" nature required in the original software, that it was
>almost impossible to predict exactly how a customer might want the
>product tailored. I suggested that what they really needed was a library
>(Python would have been good for this, Lisp might have been even better)
>that could be extended as required. GUIs second, functionality first.
>But hey, what would I know. Fortunately, the whole thing's been put on
>the back burner.
>
>And trying to get through to them why source control makes sense, that
>when more than one person works on a project, some form of coordination
>is required, that copying and pasting code is evil, and that Excel
>probably isn't the hammer for every nail.
>
>Honestly, I thought (real) engineers were supposed to be clever.
Let's provisionally assume ignorance rather than unintelligence,
if only on the grounds of parsimony. Sympathetic colleagues are
available, by the way, at <URL: http://www.engcorp.com/acf/ >.
While the Wiki remains *very* quiet, at this point, it's still
quite young.
The subject you raise is precisely at the middle of part of my
excitement about Python's prospects. I'll sketch the pertinent
propositions: GUIs are the wrong model; true flexibility involves
a domain-specific, well-designed "little language". "Scripting
languages" were originally "configuration languages"; return to
those roots is only healthy. Scientific and engineering software
particularly has been in thrall to the GUI, and deserves rejuve-
nation with "scripting". Key to the dynamic of dynamic languages
is that they make it cheaper to re-write than to re-use, in some
carefully limited sense.
I've seen the infatuation for Excel (and so on) for years, but
never found it at all tempting myself. I mostly just ignore the
issue--no, actually, I guess I give them Excel, but show at the
same time that they really want the alternative views that I
also provide.
--
http://mail.python.org/mailman/listinfo/python-list
