anygui,anydb, any opinions?

[rzed]

"Thomas Bartkus" <tom at dtsam.com> wrote in
news:5uGdnfiX3aSnRADfRVn-1Q at telcove.net: 

> "rzed" <jello at comics.com> wrote in message
> news:Xns9667883C1D343jreeder at 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