Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 04:53 am, Chris Angelico wrote:

> For example, I have a Dungeons & Dragons character sheet display, in
> which there are large numbers of entry fields (editable), labels
> (non-editable display, usually calculated from other fields), and less
> commonly, drop-down lists and multi-line text fields. Call that four
> primitives. Now, some of the fields need to be highlighted for the
> human's attention 
[...] 
> With a GUI builder, how do 
> you redefine a function that isn't just simple composition?

I'm not entirely sure what your objection here is. You're still coding. Your
widgets will have callbacks, or have handlers (to use Hypercard
terminology). Just because you're placing the widget by point-and-click or
drag-and-drop doesn't mean that you don't have to write any code at all.

If the highlighting is done at runtime, there's probably a handler or
callback that handles it. So you edit that code, wherever it happens to be.


> This additional meta-level is one that is absent from a *lot* of
> modern graphical environments. 

That's exactly why I miss Hypercard so much. The builder and the runtime are
the same thing. (In practice, you could use a simple permissions-based
model to disable access to the builder at runtime, if desired.) I really
cannot stress enough how similar it is to Python's REPL. In Python, you can
choose at an extremely fine-grained level:

- open a file in an editor, write a function or class, save, import that
module into the REPL;

- or write the function directly in the REPL;

- what's that, I need to operate on that function as data? I can write a
decorator-type function in the REPL and apply it to the function as needed,
on the fly.

I can *build code* and *run code* in the same environment. I don't *have* to
use the REPL. I can write my code in a text editor, of course, and for many
purposes that is idea. But having the interpreter available at the same
time is a HUGE benefit. Languages without a REPL are comparatively crippled
by comparison, as far as rapid development, exploration, discovery and
testing are concerned.

Think of the GUI builder as the REPL for building GUIs. You shouldn't have
to do all your work in the REPL, but neither should you be limited without
one. If the GUI builder doesn't let you write and run code on the fly, it's
a crap builder.

Hypercard had one powerful feature that the default Python REPL lacks. When
you quit Python's interactive interpreter, all the functions, classes and
variables you have created disappear. When you quit Hypercard, all the
widgets and data and code you have created is saved in the current document
(the "stack") so that they are available next time you open that document.

I think that iPython workbooks (notebooks?) are the closest equivalent in
the Python world. Certainly they are a powerful and popular feature in the
sciences (iPython copied them from Mathematica).


> Look at spreadsheets - the classic 
> Lotus 1-2-3 model has stayed with us all through, with MS Excel, OO/LO
> Calc, etc, etc generally following it. And that's fine; spreadsheets
> do a lot of very good work for a lot of people. Now, suppose in cell
> C2 you have this formula: "=A2+B2*.05". You can copy that down the
> rest of the column, and C9 will say "=A9+B9*.05", and so on; that's
> what spreadsheets do well. But once you've done that copy operation,
> those cells lose all track of the fact that they got their formula
> from C2. If you edit C2, you have to re-copy-down. That's not too hard
> for a lot of people to remember, but what happens when that's
> forgotten? 

What you are describing is effectively a form of refactoring. What happens
when you decide to use a set instead of a tuple for some data structure?
You have to go through your entire code base looking for all references to
those tuples (it might not be just one!) and change them to a set, and
change the code that operates on them. Don't say "you should have hidden
the fact that this is a tuple behind some interface layer", because this is
the implementation layer. (There's always an implementation layer.)

Some editors have refactoring tools for this sort of thing, but most don't,
and refactoring tools are never perfect nor fully automated.


>> (2) "source control" -- the world is full of document types that aren't
>> plain text source code, and people have found ways to manage
>> collaborative editing and change management for them. Why don't we ask
>> game developers how they manage changes to the non-code elements in their
>> applications? Textures, icons, player avatars, sound effects, maps, etc.
>> Surely you don't suggest that game developers edit their background
>> images in a hex editor?
> 
> Yes, and while you're at it, ask the critical question: What happens
> when two people make edits to the same object? 

You mean, something like I change the File menu to say "New; Save; Quit" and
you change it to say "Create; Save; Exit"?

Then there's a conflict, same as in text code. How would you merge those two
changes as text?


[...]
> My suspicion is that such game devs would have strict rules about
> simultaneous editing of files. While that quite probably works fairly
> well, it's a limitation that most of us would not accept in any code
> project. 

I think you mean, "in any code project apart from games".


> Imagine if the Python bug tracker required you to send, not a 
> patch file, but the entire source file that has the edit you want. How
> would you manage those sorts of edits?

Patch files are for the convenience of the code reviewer, not the person
making the change. It's *less* work for me to email or upload the
entire .py file than to create a patch and email that, but it's harder for
the guy who wants to see what changes I've made before applying them.




-- 
Steven