Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 2:15:10 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano wrote:
> > On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
> >
> >>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
> >>> less well known GUI IDEs which I did not come across. Thanks.
> >>
> >> Sounds like the advantage lies with Python here...
> >>
> >> Don't make a UI by dragging and dropping that many widgets.
> >
> >
> > And later, in another post:
> >
> >> the best way to build a cross-platform GUI is code, not drag-and-drop.
> >
> >
> > I think that's out-and-out wrong, and harmful to the developer community. I
> > think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> > processing: you can format documents as nicely as you like, but you have to
> > use a separate mode to see it.
> >
> > Drag-and-drop GUI builders have the same advantages over code as Python has
> > over languages with distinct compile/execute steps: rapid development,
> > prototyping, exploration and discovery. Of course, any decent modern
> > builder won't limit you to literally drag-and-drop, but will offer
> > functionality like duplicating elements, aligning them, magnetic guides,
> > etc.
> 
> Alright, but how do you go about doing, with a drag-and-drop builder,
> all those things we're used to with code - composing new named actions
> out of primitives, observing the changes to a program through source
> control, unit testing (maybe), and code review? The only way I know of
> to build a "function" in a DnD builder is to create a composite widget
> (eg "horizontal box containing label and entry field"), which is
> extremely useful, but limited - it's like saying that the only way to
> reuse code is single-inheritance. How would you create a higher-order
> operation in a DnD builder? How would you write something that does
> some sort of sweep over a set of widgets and does the same thing to
> them?


Alright...
I can handcraft better assembly than gcc generates. Shall I ditch gcc for assembly?
And I can work out more sophisticated memory mgmt and other algos with C than 
with python (vide Steven's recent thread on delimiter-reading),
Shall we prefer C over python?

Moore's law dictates that "penny-wise, pound-foolish" gets multiplied by an
exponential curve and the 'really-wise' puts up with a low(er) level mess for
a higher level good.

Sure the well handcrafted gui code will be smaller, neater, faster, what-have-u
than builder=generated code. So what?
The only reasonable answer is the corollary to Moore's law:
The (differential) cost of programmer-time increases exponentially

> 
> All these sorts of things are possible... but we're getting right back
> to code again. People have tried to create graphical code builders for
> decades; they've never been sufficient. Code - textual commands to
> manipulate a system - is still the most powerful and flexible way to
> do things.
> 
> By the way, you'll notice that I said "dragging and dropping **that
> many** widgets" (emphasis added). GUI builders can be great for simple
> jobs, and a really awesome one can work well for more complex jobs
> too, but the asymptotic complexity of using drag and drop is worse
> than that of code.

Code is always the last resort for arbitrary complexity
Lets keep it the last resort.

If the bottom-line is that python's GUI-builders are so deep into suxland
that they are best avoided in place of hand-written code, thats fine (by me).

Lets please not make a virtue of a lack