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