[Pythoncard-users] Re: hoping for more input

[Rodney S. <ro...@io...>]

I am fairly new to this list and have just been lurking so far, but here 
are my thoughts.

I used to be an active HyperCard user. In fact, at one time I lead a 
fee-based support group at Apple which among other things, supported 
HyperCard. I would love a tool that was as easy to use but offered more 
power. PythonCard seems to have the potential for this.

In order to get there, it definitely needs a GUI development environment. 
Current state of the art in a HyperCard-like environment seems to be 
Revolution (www.runrev.com). Revolution is expensive, though. It is also 
xTalk based, rather than Python.

Cross-platform is also very important. While native look and feel is 
important, taking advantage of all the capabilities of a particular 
platform takes second place. I would gladly sacrifice some capabilities of 
any OS for good cross-platform development.

Definitely avoid MVC for users. Yes, Model-View-Controller is a powerful 
concept, but PythonCard needs to make it easier to create applications, not 
harder. Python is hard enough for a new user to become productive in 
already. Don't add difficult concepts on top of that. I know the language 
itself is relatively simple, but try teaching a new user how to create a 
standalone application from the ground up and you'll see what I mean.

I also don't really like the idea of following DOM. It works for browsers, 
but isn't necessarily intuitive for other environments. The HyperCard idea 
of stack-card-background-foreground, etc. seems to make more sense to new 
users.

Message watcher functionality is definitely useful. I think that in 
general, the command line should be hidden as much as possible from the 
user in PythonCard. Being able to bring one up only as needed is definitely 
useful, though.

I actually think that dependence on the command line is one of Python's 
weaknesses. It makes things easier when launching from Unix. But, it is 
much harder for users to follow if they are used to Windows or Mac OS. 
Given this, PythonCard should be a double-clickable application that can be 
launched easily by a user and then let them create applications easily 
using PythonCard as the scripting language. If someone has to start the 
whole Python environment to run their applications, you will lose many 
potential new users.

Similar to the above, PythonCard needs to provide a way to deliver easily 
launchable and distributable applications. If it doesn't compile to Java or 
some other language, then there needs to be really good documentation 
describing how to create a standalone application on each supported 
platform. It isn't sufficient to expect the user to figure out how to do it 
on their own.

As for the name, it seems fine to me,  but you can certainly see my bias 
from what I have written above. If you are trying to create a tool like you 
have described, the name makes sense. If it is going to be more Visual 
Basic-like, then you might want to change it.

Of course, all the above is just my opinion. It states what I would like to 
see. If PythonCard takes some other form and still makes Python development 
easier, I would likely consider using it. So far, it seems to add yet more 
to learn on top of my learning Python itself so I haven't really played 
with it.

-Rodney