Wgy isn't there a good RAD Gui tool fo python
rustompmody at gmail.com
Mon Jul 11 18:33:35 CEST 2011
On Jul 11, 7:39 pm, Chris Angelico <ros... at gmail.com> wrote:
> On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden <sturlamol... at yahoo.no> wrote:
> > You are probably aware that Unix and Unix customers have been around
> > since the 1970s. I would expect the paradigm to be changed by now.
> The paradigm of small tools that do exactly what they're supposed to,
> and can be combined? Nope. There's still a philosophy of services that
> fit together like a jigsaw puzzle, rather than expecting each
> application to do everything you want it to. A standard Unix command
> line might consist of three or more tools, piping from one into
> another - grep the Apache log for lines containing the name of a PHP
> script, pipe that into awk to pick up just the user name, IP address,
> and date (without time), then pipe into uniq (deliberately without
> first going through sort) to show who's been using the script lately.
> And then piped it through sed to clean up the format a bit. Yep,
> that's something I did recently.
> Point to note: This is the Unix *philosophy* versus the Windows
> *philosophy*, not Unix *programs* versus Windows *programs*. There are
> Windows programs that follow the Unix philosophy.
The intention of programming is to close the semantic gap.
It is a fundamental task of software engineering to close the gap
between application specific knowledge and technically doable
formalization. For this purpose domain specific (high-level) knowledge
must be transferred into an algorithm and its parameters (low-level).
A gui-builder reduces the semantic gap by showing a widget when the
programmer things 'widget.'
Banging out hundreds of lines in vi/emacs for the same purpose does a
measurably poorer job.
Note it can reduce but not close. By choosing fidelity to the gui we
have corresponding less fidelity to the algos and data-structures [And
one may assume that someone even using a gui toolkit wants to do
something with the gui and not just paint the screen]
Still it seems a bit naive to suggest that building a gui by a few
point&clicks is 'windows-model' and banging out hundreds of lines in
vi/emacs is 'unix-model.' It does disservice to python and to unix.
If a student of mine came and said: Is Python better or Unix? he would
receive a dressing down.
And yet more than one person here seems to think such type-wrong
comparisons are ok.
I find this disturbing...
More information about the Python-list