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 -- https://mail.python.org/mailman/listinfo/python-list
