Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   anygui,anydb, any opinions? (http://www.velocityreviews.com/forums/t345529-anygui-anydb-any-opinions.html)

rzed 05-31-2005 05:22 PM

anygui,anydb, any opinions?
 
Periodically, we see questions about which gui package is best, or
which database package to use. These questions typically trigger
some exchanges of opinion, though of course this no one best
answer, and eventually things quiet down until the next round.

But it seems to me that what seldom gets asked is: why is it
Python's concern which package to use for those purposes? It seems
to me that a proper approach from the viewpoint of the language
itself is to provide an interface, and for the package developers
to provide an implementation of that interface. A Python program
would thus address its api only, leaving it up to the package to
interpret that properly. In the ideal world, this would mean that
any Python program could swap the gui package (or the db package)
without changing the logic of the program. Python-the-language
(rather than Python-the-package) would theoretically be a more
compact download, and the hooked-in parts could be installed
separately.

Anygui and anydb have been attempts to reach the ideal interface
(and there are others, I think), but each has its problems and
neither is supported or developed as fully as the idealized
interface would require. I don't see much evidence that the various
packages are designed to conform to those designs (and I don't
contend that they should be required to until and unless the
generic interfaces are in a well-developed state). But the result
of all this is that there continues to be confusion to newbies and
even veterans who are new to a given area or platform. Shouldn't it
be a priority to eliminate the source of that confusion?

Now, on the grounds that practicality beats purity, it's certainly
reasonable to argue that the current system works better. If we
could just jump into a state where there was a perfectly-
functioning anydb and anygui, then we'd already have been there,
but we can't and so we won't try to go in that direction at all.
Python-the-package marches on; it can't wait for some ideal to
coalesce before it advances. It's hard to argue too strongly
against that view.

Then, too, it's hard to see how an anygui or (more especially, I
think) an anydb could possibly work in the real world. The various
approaches to windowing and databases are too different for a
single interface to encompass them all. Some capabilities would be
unforeseen or ignored in any such interface. That argument carries
a lot of force. Certainly it is true that adding parameters to a
function call to accommodate some new feature gets real old real
soon. But while it is a strong practical argument, it is not one
that truly wins in the long run, I think. It is an argument in
favor of changing the way arguments are passed, so that it becomes
possible to handle the various pieces of information the lower-
level package needs. The interface should be agnostic as much as
possible. The package should be able to get the information it
needs from what is passed by the api. Both of these things must be
true.

Back when I was programming in DEC C, I saw how their
implementation of functions like printf departed from the C
standard by adding optional keyword parameters. Using those
parameters, DEC's more-sophisticated filesystem could be used
productively without going deeply into the filesystem's api.

Of course, a program written that way wouldn't work if transferred
unchanged to another system, but it *could* have worked if the
other system could also either handle the keywords (or some of
them) or ignore them. The results may not have been exactly as
desired, but there would have been results. Similarly, an elaborate
call that allows access to a sophisticated gui should also produce
results if the gui is simpler. Supposing that a given parameter
required by the second system has not been included in the first
place, it should be possible to add that parameter without
affecting the first system one bit. The first one would still not
be looking for the parameter, while the second would now find it.

That's all I'm talking about here. To be able to write a Python
application that can ultimately be displayed using wxWidgets or Qt
or Tkinter or Curses. Then, without having to do more than to
change which interface package is imported, to expect to see the
result displayed. To have it just happen, and to have expectations
when using Python that it *will* just happen that way.

So what do you think? What's wrong with the picture? Why isn't
there a greater priority to work in this direction?

--
rzed

max 05-31-2005 06:09 PM

Re: anygui,anydb, any opinions?
 
rzed <jello@comics.com> wrote in news:Xns9667883C1D343jreeder@
63.223.7.253:

> So what do you think? What's wrong with the picture? Why isn't
> there a greater priority to work in this direction?
>


Without giving any reasons beyond intuition, I would have to say that
it boils down to 2 things: The size and scope of gui and database
frameworks, and the fact that opinions differ about what is 'ideal'.

max

Shane Hathaway 05-31-2005 09:55 PM

Re: anygui,anydb, any opinions?
 
rzed wrote:
> That's all I'm talking about here. To be able to write a Python
> application that can ultimately be displayed using wxWidgets or Qt
> or Tkinter or Curses. Then, without having to do more than to
> change which interface package is imported, to expect to see the
> result displayed. To have it just happen, and to have expectations
> when using Python that it *will* just happen that way.
>
> So what do you think? What's wrong with the picture? Why isn't
> there a greater priority to work in this direction?


See "The Law of Leaky Abstractions" by Joel Spolsky.

http://www.joelonsoftware.com/articl...tractions.html

As he says, "All non-trivial abstractions, to some degree, are leaky."
GUI abstractions tend to leak badly. As I write this email in
Thunderbird, my initial impression is that most of the controls on the
screen are pretty standard and could be done with virtually any
toolkit... or are they? Looking again, the "from" field has both a
place for me to type and some grayed out text that reminds me I'm
posting from a different account; the "to", "cc", and "newsgroup" fields
are not quite combo boxes; the toolbar has pulldown buttons.

So it turns out that Thunderbird is actually tied to a particular
toolkit, and for good reason: GUI development has not stagnated; toolkit
developers continue to invent new, interesting widgets and variations,
leading to better UIs. Application developers want to take advantage of
those innovations.

Even anydbm is a pretty leaky abstraction. I recently tested the
behavior of 5 Python dbm implementations when they run out of disk
space. Most left the database in an inconsistent state, some swallowed
the exception, some segfaulted, and one deadlocked. If I'm going to
rely on a dbm module, I really need to know what it's going to do when
it hits an exceptional condition. Thus anydbm seemed like a bad choice.

Shane


Thomas Bartkus 06-01-2005 03:52 PM

Re: anygui,anydb, any opinions?
 
"rzed" <jello@comics.com> wrote in message
news:Xns9667883C1D343jreeder@63.223.7.253...
<snip>
> So what do you think? What's wrong with the picture? Why isn't
> there a greater priority to work in this direction?


> What's wrong with the picture?


Just one teeny little item.

The Python world lacks the phenomenally successful development models
enjoyed by the now ancient Turbo Pascal, Delphi and <gasp> Visual Basic.
AND
If the likes of Visual Basic can have it, then it becomes really, *really*
hard to convince the world that Python is a serious, professional system.

At some point, one has to break out of theory and produce!
Or challenge the theory with some hard questions.

Thomas Bartkus



Thomas Bartkus 06-01-2005 07:17 PM

Re: anygui,anydb, any opinions?
 
"rzed" <jello@comics.com> wrote in message
news:Xns9667883C1D343jreeder@63.223.7.253...
<snip>
> So what do you think? What's wrong with the picture? Why isn't
> there a greater priority to work in this direction?


> What's wrong with the picture?


Just one teeny little item.

The Python world lacks the phenomenally successful development models
enjoyed by the now ancient Turbo Pascal, Delphi and <gasp> Visual Basic.
AND
If the likes of Visual Basic can have it, then it becomes really, *really*
hard to convince the world that Python is a serious, professional system.

At some point, one has to break out of theory and produce!
Or challenge the theory with some hard questions.

Thomas Bartkus



Skip Montanaro 06-01-2005 08:15 PM

Re: anygui,anydb, any opinions?
 

Thomas> The Python world lacks the phenomenally successful development
Thomas> models enjoyed by the now ancient Turbo Pascal, Delphi and
Thomas> <gasp> Visual Basic.
Thomas> AND
Thomas> If the likes of Visual Basic can have it, then it becomes
Thomas> really, *really* hard to convince the world that Python is a
Thomas> serious, professional system.

Remember, in the open source community we all pretty much just scratch our
itches. Given that for the most part nobody in the Python community has a
handle on any other Python person's paycheck, it's unlikely that enough of
the community can be convinced that a VB-like development environment would
be a "killer app" for Python and thus motivated to go produce one.
Apparently, most Python people feel productive enough without such a tool.

Skip

Thomas Bartkus 06-01-2005 09:00 PM

Re: anygui,anydb, any opinions?
 
"Skip Montanaro" <skip@pobox.com> wrote in message
news:mailman.347.1117656834.18027.python-list@python.org...
>
> Thomas> The Python world lacks the phenomenally successful development
> Thomas> models enjoyed by the now ancient Turbo Pascal, Delphi and
> Thomas> <gasp> Visual Basic.
> Thomas> AND
> Thomas> If the likes of Visual Basic can have it, then it becomes
> Thomas> really, *really* hard to convince the world that Python is a
> Thomas> serious, professional system.
>
> Remember, in the open source community we all pretty much just scratch our
> itches.


I haven't forgotten!

> Given that for the most part nobody in the Python community has a
> handle on any other Python person's paycheck, it's unlikely that enough of
> the community can be convinced that a VB-like development environment

would
> be a "killer app" for Python and thus motivated to go produce one.


Judging by the message traffic alluded to by the original poster, I'm hardly
the only one with this particular itch. AND there is clearly a substantial
development effort in this direction. Apparently, a few in the community are
convinced of the worth.

I think we need to get over this "killer app" jazz. How about plain old
productivity? How do we enjoy the rapid and effective algorithm production
that Python affords us if one must pay back that productivity on an
effective and tediously acquired user interface. I rather think reducing the
code needed to produce a useful user interface frees up considerable effort
better spent on the programming problems we use Python for.

> Apparently, most Python people feel productive enough without such a tool.

As did many with Fortran. Or Cobol. Are we now so productive that there is
no longer an unmet need for new/better software? Do we stop here? Is
Python a comfortable place for the Luddites hang out.

I think not.
Thomas Bartkus





Paul Rubin 06-01-2005 09:01 PM

Re: anygui,anydb, any opinions?
 
"Thomas Bartkus" <tom@dtsam.com> writes:
> > Given that for the most part nobody in the Python community has a
> > handle on any other Python person's paycheck, it's unlikely that
> > enough of the community can be convinced that a VB-like
> > development environment would be a "killer app" for Python and
> > thus motivated to go produce one.

>
> Judging by the message traffic alluded to by the original poster, I'm hardly
> the only one with this particular itch. AND there is clearly a substantial
> development effort in this direction. Apparently, a few in the community are
> convinced of the worth.


Are we talking about a drag-and-drop GUI builder? What about Glade?

Or do you mean a fancy IDE? There's a Python plug-in for Eclipse, but
I haven't tried it yet.

Thomas Bartkus 06-01-2005 09:25 PM

Re: anygui,anydb, any opinions?
 
"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
news:7xzmu94wrf.fsf@ruckus.brouhaha.com...
> "Thomas Bartkus" <tom@dtsam.com> writes:
> > > Given that for the most part nobody in the Python community has a
> > > handle on any other Python person's paycheck, it's unlikely that
> > > enough of the community can be convinced that a VB-like
> > > development environment would be a "killer app" for Python and
> > > thus motivated to go produce one.

> >
> > Judging by the message traffic alluded to by the original poster, I'm

hardly
> > the only one with this particular itch. AND there is clearly a

substantial
> > development effort in this direction. Apparently, a few in the community

are
> > convinced of the worth.

>
> Are we talking about a drag-and-drop GUI builder?

I am!

> What about Glade?

Dying to try that. Ask me again in a week.

> Or do you mean a fancy IDE?

That too!

> There's a Python plug-in for Eclipse, but I haven't tried it yet.

Fact is, there are all kinds of interesting things in the air.

I happen to be one - and I *know* I'm not alone - who thinks that building
user interfaces is way too difficult and way too important. It is
particularly frustrating in that we do seem to be moving backwards in this
department.

Am I the only one who notices that we are in the dark ages when it comes to
producing (new) software that people can use. Was MS Office 2000 the be all
and end all of software development. Why has it all come to a halt? My
explanation is a:
Microsoft entering senility
a programming community unable to recognize a developing vacuum
The great html plague
And -

Lack of interest in GUI/IDE programming environments.
Thomas Bartkus



rzed 06-01-2005 09:52 PM

Re: anygui,anydb, any opinions?
 
"Thomas Bartkus" <tom@dtsam.com> wrote in
news:5uGdnfiX3aSnRADfRVn-1Q@telcove.net:

> "rzed" <jello@comics.com> wrote in message
> news:Xns9667883C1D343jreeder@63.223.7.253...
> <snip>
>> So what do you think? What's wrong with the picture? Why isn't
>> there a greater priority to work in this direction?

>
> > What's wrong with the picture?

>
> Just one teeny little item.
>
> The Python world lacks the phenomenally successful development
> models enjoyed by the now ancient Turbo Pascal, Delphi and
> <gasp> Visual Basic.
> AND
> If the likes of Visual Basic can have it, then it becomes
> really, *really* hard to convince the world that Python is a
> serious, professional system.
>
> At some point, one has to break out of theory and produce!
> Or challenge the theory with some hard questions.
>


I'm not thinking only of a Drag & Drop graphical development
interface (and in fact there are several available now, all of
which work with some degree of similarity to VB). It might be nice
to have, but I've used a lot of systems that could crank out
tolerable windows with a relatively small amount of text entry.
Those who have used Cognos' Powerhouse, for instance, or Magic, or
even dBase (maybe that's a stretch) can testify to that, I think.

But there is a common need for production of systems where data-
entry and data views are required. Typically, the back end is a
database, though it need not be. It's not that hard to build such a
system using any one of the packages, particularly once you acquire
expertise with that package.

But should you want to switch to another package, you find that a
*lot* has to change in your applications, no matter how hard you've
tried to separate the presentation from the logic, just because the
requirements of the various systems differ so much. It might be
that you have to reorder parameter lists, or subtract parameters,
or insert some. Almost never can you simply use a different import
statement alone to change the underlying windows handler. If you
need to add new parameters, almost never can you simply append them
to an existing parameter list and expect the thing to work.

And if you do change to the new system, your code can no longer
work using the old system. A lot of this is just because of the way
interfaces are specified; for some call on system A you need, let's
say: (a)a label, (b)a size (which must be a tuple, not a list), (c)
a boolean value. Now you switch to system B, which does not name
the equivalent call the same, nor does it pass in the same
parameters, or not in the same sequence. Multiply this by all the
api calls you have, and you may as well start over with each
package as try to make it all work.

It seems to me that Python (the language, not the package) is
intended in part to make tasks like that easier. It would be better
if the call for a given function were named the same (in your
application code), and if you could simply append some new
parameters to make the new system function (knowing that its
interface would simply ignore the old parameters it did not
understand), well, that's not too hard, and it doesn't break the
old system. So you add what you need to (if you need to add
anything), and now you have a system that runs on two packages. All
you have to do is to import the one you have, or want to use.

It means the package writer has to create an API bridge, one that
maps the underlying package's api to the Python standard api. The
application writer doesn't or shouldn't have to worry about that
mapping. And it probably means that dictionaries (or something
similar) are used to pass most parameters.

This sounds chaotic, as though interfaces would suddenly be
impossible to document, but it need not be so. If a package has a
feature that cannot be mapped reasonably to the Python api, then
add to the Python api, or (as part of the Python api) allow a
system pass-through the package's api can interpret. If the package
doesn't get the information it needs, it will complain, just as it
does now. Its requirements will be documented just as they are now.

It's not that all applications would run on all systems without
change, but that essentially all *basic* applications would run on
any system that supported the same basic operations without change.
There are many widgets, and as windowing packages become slicker,
there are more options; eventually, as the options become universal
(or at least common) they would be added to the Python api.

Whether or not a D&D GDI would make this better would still be up
to the individual programmer, I'd think. It would be a heck of a
lot easier to *write* a GUI if you weren't overly concerned with
the underlying graphics package.

--
rzed


All times are GMT. The time now is 08:08 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.