3 ms·

The one that really worked was HyperCard. Though it is now forgotten, it had a large following back in the late 1980s and early 1990s. It was also used to teach

The one that really worked was HyperCard. Though it is now forgotten, it had a large following back in the late 1980s and early 1990s. It was also used to teach programming to children in some elite private schools (maybe it also made it into the public schools?). Danny Goodman wrote a book about it that some of us remember fondly; it was as good an introduction to basic programming as anything ever written. HyperCard had most of the features that Chris Granger talks about when he talks about LightTable. In HyperCard, you can see all the variables as they updated, as your program ran. There was no real compile step, you could hit "Run" and watch you variables change as the program ran. You can read more about it here: http://en.wikipedia.org/wiki/HyperCard http://en.wikipedia.org/wiki/HyperCard Apple eventually abandoned HyperCard, as perhaps it became obsolete in the era of the Internet. I believe we will again have something like HyperCard, in the future, but not while we still have the document model imposed on us by HTML. The Internet will need a new protocol for apps, rather than documents. When that day comes, I suspect we will see something like HyperCard return. People like Chris Granger are already doing very cool stuff with Javascript and LightTable, but they are forced to work within the document paradigm (with a hierarchical DOM) which is not a good fit for applications.

bithive123 12y ago
I have very fond memories of using HyperCard in a public elementary school in the early 90s (mostly to create cartoon violence).
seanmcdirmid 12y ago
HyperCard supported run forward but not back. It had no concept of time manipulation as shown in Bret victor's videos.
captainmuon 12y ago
> The Internet will need a new protocol for apps, rather than documents. A bit off-topic (sorry), but that's a good point. I believe it would be great for a future version of HTML to have two 'profiles', one for documents and one for apps. The document metaphor is great for, well, plain documents, but it is problematic for apps, like Gmail. For example it can be annoying if you have JS-heavy sites which break document-related features (navigation, resizing, printing, copying). Have a document profile where you have all the markup features, but the javascript features are possibly restricted. This corresponds to a lean version of HTML5. You know HTML6-doc pages will look reasonable and load quickly on all devices, including on ebooks and printed out. Then have a app profile where you don't even need a document - you can just draw on canvasses if you want, but you can also create HTML elements. I imagine that people write GUI libraries for it. You have access to all fancy modern JS features, like sockets, webcam, etc.. This would be the time to change the wierd security model of HTML - a page with the DOCTYPE HTML6-app would opt into a new model, where pages don't have access to all credentials and cookies by default, so it is reasonably safe to give them net access (they can't buy stuff if you are logged into amazon in another tab, for example). The best thing is, we can start using these new paradigms today - and maybe have nice little badges to show we are following the new "best practice" :-). Restict yourself to minimal, presentational, progressive-enhancement JS for documents, use semantic markup, check that it looks good on all devices etc.. And when you are doing a (single-page) app, it doesn't have to look like a document, but heed all the advice for non-web desktop or mobile apps - and make sure your app doesn't break navigation.

bithive123 12y ago

I have very fond memories of using HyperCard in a public elementary school in the early 90s (mostly to create cartoon violence).

seanmcdirmid 12y ago

HyperCard supported run forward but not back. It had no concept of time manipulation as shown in Bret victor's videos.

captainmuon 12y ago

> The Internet will need a new protocol for apps, rather than documents. A bit off-topic (sorry), but that's a good point. I believe it would be great for a future version of HTML to have two 'profiles', one for documents and one for apps. The document metaphor is great for, well, plain documents, but it is problematic for apps, like Gmail. For example it can be annoying if you have JS-heavy sites which break document-related features (navigation, resizing, printing, copying). Have a document profile where you have all the markup features, but the javascript features are possibly restricted. This corresponds to a lean version of HTML5. You know HTML6-doc pages will look reasonable and load quickly on all devices, including on ebooks and printed out. Then have a app profile where you don't even need a document - you can just draw on canvasses if you want, but you can also create HTML elements. I imagine that people write GUI libraries for it. You have access to all fancy modern JS features, like sockets, webcam, etc.. This would be the time to change the wierd security model of HTML - a page with the DOCTYPE HTML6-app would opt into a new model, where pages don't have access to all credentials and cookies by default, so it is reasonably safe to give them net access (they can't buy stuff if you are logged into amazon in another tab, for example). The best thing is, we can start using these new paradigms today - and maybe have nice little badges to show we are following the new "best practice" :-). Restict yourself to minimal, presentational, progressive-enhancement JS for documents, use semantic markup, check that it looks good on all devices etc.. And when you are doing a (single-page) app, it doesn't have to look like a document, but heed all the advice for non-web desktop or mobile apps - and make sure your app doesn't break navigation.