Everything good about Python except GUI IDE?

[Sven R. Kunze]

On 28.02.2016 07:34, Steven D'Aprano wrote:
> 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.

Good point.

> 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.

Another good point. I will get to this later.

> GUI elements are by definition graphical in nature, and like other graphical
> elements, manipulation by hand is superior to command-based manipulation.
> Graphical interfaces for manipulating graphics have won the UI war so
> effectively that some people have forgotten there ever was a war. Can you
> imagine using Photoshop without drag and drop?
> (you can measure this by counting the numbers of replies to a thread)

That's whole different topic. What is Photoshop manipulating? Layers of 
pixels. That's an extremely simplified model. There is no dynamic 
behavior as there is with GUIs.

> And yet programming those graphical interfaces is an exception. There, with
> very few exceptions, we still *require* a command interface. Not just a
> command interface, but an *off-line* command interface, where you batch up
> all your commands then run them at once, as if we were Neanderthals living
> in a cave.

Not sure if I agree with you here.

Let's ask ourselves, what is so different about, say, a complex 
mathematical function and a complex GUI? In other words: why do you can 
live with a text representation of that function whereas you cannot live 
with a text representation of a GUI?

One difference is the number of interactions you can do with a function 
and a GUI. A function takes some numbers whereas a GUI takes some 
complex text/mouse/finger/voice interactions.
So, I've never heard of any complains when it comes to mathematical 
functions represented in some source code. But, I've heard a lot of 
complains regarding GUI design and interaction tests (even when they are 
done graphically) -- also in WPF.

Both text representations are abstract descriptions of the real thing 
(function and GUI). You need some imagination to get them right, to 
debug them, to maintain them, to change them. We could blame Python here 
but it's due to the problem realm and to the people working there:

Functions -> mathematicians/computer scientists, work regularly with 
highly abstract objects
GUI -> designers, never really got the same education for 
programming/abstraction as the former group has

So, (and I know that from where I am involved with) GUI research 
(development, evaluation etc.) is not a topic considered closed. No 
serious computer scientist really knows the "right" way. But, hey, 
people are working on it at least.

Usually, you start out simple. As the time flies, you put in more and 
more features and things become more and more complex (we all know that 
all non-toy projects will). And so does a GUI. At a certain point, there 
is no other way than going into the code and do something nasty by 
utilizing the Turing-completeness of the underlying language. Generated 
code always looks creepy, bloaty with a lot of boilerplate. If you 
really really need to dig deeper, you will have a hard time finding out 
what of the boilerplate is really needed and what was added by the 
code-generator. In the end, you might even break the 
"drag-n-drop"ability. :-(

That is the reason, why traditional CASE tools never really got started, 
why we still need programmers, why we still have text. From my point of 
view (highly subjective), start by using general building blocks (text, 
functions, classes, ...) is better long-term; not by starting with a 
cage (the GUI) and subsequently adding more and more holes not fitting 
the original concept. History so far as agreed with this; professional 
software development always uses text tools for which LATER somebody 
built a GUI. I cannot remember it being the other way round.

Furthermore, I agree with Chris about the version control problem.

Last but not least, GUIs are a place for bike shedding because almost 
everybody is able to see them and can start having an opinion about them:
Who loves the new Windows modern UI? Either you like it or you hate it.
What about the Riemann zeta function? Anybody?


Best,
Sven

PS: another thought.

I recently introduced LaTeX to my girlfriend. LaTeX is quite ugly and it 
has this "distinct compile/execute step", so initially I hesitated to 
show it to her. But her MS Word experience got worse and worse the more 
complex (and especially larger) her workload became. Word became less 
responsive and results became even less reproducible (footnote 
numbering, styling, literature, etc.).

She needed to invest some time to learn LaTeX and to tweak the initial 
template to fit her needs. Though, in the end, she's much happier and 
get reproducible results. She still uses a GUI for writing LaTeX. It 
helps her avoiding mistakes.

So, I don't think it's GUI vs text but rather how can they complement 
each other.