Hypercard and Python
08/16/200112 years ago I took my first look at Hypercard on a friend's new Macintosh II. "So what?" I asked "It's a Rolodex." "Nah," he replied. "This is a Rolodex with brains." Hypercard could contain more than database entries, it could hold mini-applications as well. Mini-applications you could string together as easily as we would later string together web pages and web apps. Hypercard was hypertext and hypermedia and hyper-application. Programming for hyper programmers.
Hypercard's inventor, Bill Atkinson, once called Hypercard a "Software Erector Set." Programming for the Macintosh GUI was much harder than programming for a DOS console. Yet Hypercard made it so simple practically anyone could create their own programs. You didn't have to know much to paint a graphic interface and do a little scripting. Hypercard could even be used to create standalone applications you could distribute. No one needed to know it was Hypercard. The champ of Hypercard applications was Myst, a hypermedia adventure.
Apple has had an on-again-off-again relationship with Hypercard. Initially included for free on Macintosh systems, it later became a commercial product of its own, then was bounced back and forth between Apple and Claris. Steve Jobs finally canned development of Hypercard in 1997. Frozen at version 2.4.1, it's still available through Apple for $99.
Hypercard still lives fondly in the hearts of many programmers. It was their first taste of the art, their first love. In June, Hypercard enthusiest Matt Johnson suggested Apple release Hypercard as Open Source, so development could continue in the hands of those who loved it best. About the same time Johnson's opinion was published, Ron Stephens opined on the comp.lang.python newsgroup for "a PythonCard for event driven gui programs, using the Python syntax and the Hypercard container model." He further lamented his lack of coding ability to make it happen. Less unsure of their coding ability, Neil Hodgson, Roman Suzi, and Kevin Altis among others jumped on the idea. Pythoncard was born.
Pythoncard is currently just a prototype. It doesn't look like Hypercard at all. It's primarily a means of describing the elements of a GUI application in a separate resource file, then describing what those elements do, and how they interact in your Python program. This keeps all the GUI definition stuff out of your Python code, making it much more readable. You give up some control for this, but the resource file used to describe the GUI is fairly rich. It's basically a nested dictionary of GUI elements and parameters that are read into your Python program. Pythoncard handles construction of the GUI based on your description and hooks the elements together with your program.
The Pythoncard prototype uses wxWindows as its GUI toolkit and
requires Python 2.1.x and wxPython 2.3.1. It comes in a zipped file.
If you install it on a Unix system, you should convert the .py and
.txt files that come with it to a Unix format. Python's eval() choked
on the extra carriage returns until I converted them using
dos2unix. If you're on an MS Windows system it should
work fine. There's no documentation, just sample code. The samples,
however, are very good. You can take the minimal sample
and experiment with modifying its resource files. The
proof sample uses many of the GUI elements currently
available.
Many open source projects begin as one person shows. Pythoncard is a group effort. Its codebase is still small, and decisions about how to put it together are still being made. If you're one of those programmers with a soft spot for Hypercard, or perhaps are just looking for an open source project to cut your teeth on, consider contributing to this project.
Stephen Figgins is an editor with the O'Reilly Network and the network's Python DevCenter bureau chief.
Read more Python News columns.
Return to the Python DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 3 of 3.
-
Python is the heart of PythonCard
2001-08-19 21:00:25 kasplat [Reply | View]
In answer to the question "why use Python?" the answer is so that we can leverage the power of Python, the Python Standard Libraries, the ability to wrap C code, work equally well across a large number of platforms, etc. PythonCard does not use a subset of Python or try and recreate HyperTalk.
I was a HyperCard developer for ten years and loved HyperTalk, but I've moved on. I wasn't aware of Revolution, it looks nice, and I hope they do well.
However, I think Python is simply a much better language than HyperTalk ever was and Python has the best user community I've ever encountered for a language. Frankly, at this point in my life, I'm through with using languages controlled by one company. Even Java suffers at the hands of Sun.
It doesn't hurt that Python and PythonCard are free. I'm not saying people shouldn't continue to use a tool that can run or import HyperCard or uses a variant of the HyperTalk language. PythonCard won't be importing HyperCard stacks anytime soon. Freedom of choice is a good thing, so use what suits you. What we hope to do with PythonCard is take the good parts of HyperCard and what we've learned in the 14 years since HyperCard came out and build something much better that we can use for the next ten years or longer.
ka
-
Why switch languages?
2001-08-19 09:31:13 fourthworld [Reply | View]
At the heart of HyperCard is more than its object model, it's the language as well. Making Python code that kinda sorta works somewhat like maybe a litle like HyperCard seems too much of a compromise while xTalk still lives.
For Mac development SuperCard continues to live well, with support for a great many Mac OS features like scriptable drag-and-drop, AppleScript, and more, along with so many things HyperCard folks have been craving for years like multiple window styles and integrated color.
And then there's Revolution <http://www.runrev.com>, which sacrifices only a few OS-specific features to deliver something we'd never imagined before: a graceful xTalk that runs on all major platforms (Mac, Win, UNIX). Moreoever, with its group objects and lightning-fast interpreter, there's almost no need for XCMDs, as you can build just about any GUI widget you can imagine right in the product, using an extended version of the language you love, HyperTalk.
A tutorial from a more HyperCardish perspective:
http://www.penguin-home.telinco.co.uk/Rolodex_Project/