The Hypercard Legacy(medium.com)
medium.com
The Hypercard Legacy
https://medium.com/@blprnt/the-hypercard-legacy-e5b9eb273b6a
93 comments
We're building on this spirit at Universe
http://un1verse.co
And we're looking for talented souls to help make it real
Computing as a tool for individual empowerment... who'd have thought?
http://un1verse.co
And we're looking for talented souls to help make it real
Computing as a tool for individual empowerment... who'd have thought?
In 1989, Arthur van Hoff was quite the celebrity in the NeWS community (Sun's PostScript based window system written by James Gosling, who later went on to make Java with Arthur).
At the Turing Institute in Glasgow, Arthur and his colleagues created a groundbreaking HyperCard-like PostScript-based networked user interface creation tool called GoodNeWS, later renamed HyperNeWS and then HyperLook, which was the most amazing thing anyone ever did with NeWS.
I moved to Glasgow in 1992 to work at the Turing Institute with Arthur, making HyperLook into a product and porting SimCity to the Sun, and we released HyperLook and SimCity for HyperLook simultaneously!
HyperLook was so far ahead of its time in 1989, that there still isn't anything quite like it for modern technology. Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;)
https://en.wikipedia.org/wiki/Arthur_van_Hoff https://en.wikipedia.org/wiki/Turing_Institute https://en.wikipedia.org/wiki/NeWS
http://www.art.net/~hopkins/Don/hyperlook http://www.art.net/~hopkins/Don/hyperlook/HyperLook.README
http://donhopkins.com/home/movies/HyperLookDemo.mov http://www.art.net/~hopkins/Don/simcity/hyperlook-demo.html
http://www.art.net/~hopkins/Don/hyperlook/SimCity.README http://art.net/~hopkins/Don/hyperlook/HyperLook-SimCity.gif https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual
https://www.scribd.com/doc/77192848/HyperNeWS-Brochure https://www.scribd.com/doc/77192884/HyperLook-Product-Info https://www.scribd.com/doc/77199792/HyperLook-Manual-Part-1-... https://www.scribd.com/doc/77194415/HyperLook-Manual-Part-2-... https://www.scribd.com/doc/77199691/HyperLook-Manual-Part-3-... https://www.scribd.com/doc/77194936/HyperLook-Manual-Part-4-... https://www.scribd.com/doc/77195777/HyperLook-Manual-Part-5-... https://www.scribd.com/doc/77193909/HyperLook-Manual-Part-6-...
At the Turing Institute in Glasgow, Arthur and his colleagues created a groundbreaking HyperCard-like PostScript-based networked user interface creation tool called GoodNeWS, later renamed HyperNeWS and then HyperLook, which was the most amazing thing anyone ever did with NeWS.
I moved to Glasgow in 1992 to work at the Turing Institute with Arthur, making HyperLook into a product and porting SimCity to the Sun, and we released HyperLook and SimCity for HyperLook simultaneously!
HyperLook was so far ahead of its time in 1989, that there still isn't anything quite like it for modern technology. Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;)
https://en.wikipedia.org/wiki/Arthur_van_Hoff https://en.wikipedia.org/wiki/Turing_Institute https://en.wikipedia.org/wiki/NeWS
http://www.art.net/~hopkins/Don/hyperlook http://www.art.net/~hopkins/Don/hyperlook/HyperLook.README
http://donhopkins.com/home/movies/HyperLookDemo.mov http://www.art.net/~hopkins/Don/simcity/hyperlook-demo.html
http://www.art.net/~hopkins/Don/hyperlook/SimCity.README http://art.net/~hopkins/Don/hyperlook/HyperLook-SimCity.gif https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual
https://www.scribd.com/doc/77192848/HyperNeWS-Brochure https://www.scribd.com/doc/77192884/HyperLook-Product-Info https://www.scribd.com/doc/77199792/HyperLook-Manual-Part-1-... https://www.scribd.com/doc/77194415/HyperLook-Manual-Part-2-... https://www.scribd.com/doc/77199691/HyperLook-Manual-Part-3-... https://www.scribd.com/doc/77194936/HyperLook-Manual-Part-4-... https://www.scribd.com/doc/77195777/HyperLook-Manual-Part-5-... https://www.scribd.com/doc/77193909/HyperLook-Manual-Part-6-...
Yup. I have many happy memories of working in HyperCard as a child—it's what got me into programming. I don't know what a kid nowadays would start on; JavaScript really is too much for a beginner IMHO.
The only language I know of that takes newbie-friendliness and accessibility seriously without compromising on technical vision is Racket.
Seriously, read the prologue of How to Design Programs: http://www.ccs.neu.edu/home/matthias/HtDP2e/part_prologue.ht... It's clear and accessible, but introduces programming in terms of values and the idea of animation as a reduce/foldl of a function that returns image values over a list of frame numbers. Incredible stuff. And as a bonus DrRacket is simple enough for kids without compromising much on capability.
Seriously, read the prologue of How to Design Programs: http://www.ccs.neu.edu/home/matthias/HtDP2e/part_prologue.ht... It's clear and accessible, but introduces programming in terms of values and the idea of animation as a reduce/foldl of a function that returns image values over a list of frame numbers. Incredible stuff. And as a bonus DrRacket is simple enough for kids without compromising much on capability.
I think Elm might well be a good introductory environment for a motivated beginner. It's Javascript/HTML/CSS in the background but you only work with the Elm language. Best of all, you can work with it within a browser (see [1]). So no arduous set-up.
It's a functional language, but I'm not convinced that an object-oriented language is good for an introductory language, anyway.
I plan to start my 7-year-old daughter on Elm in the next few months. She's already playing around with various introductory programming activities on Sugar OS (Turtle, etc.).
I'll report back on how it goes.
But I agree that a revived HyperCard would also be a great environment. My family was all PC growing up in the 80s, so I had no exposure to HyperCard at that time. But reading about it retrospectively, I'm impressed.
1. http://elm-lang.org/Examples.elm
It's a functional language, but I'm not convinced that an object-oriented language is good for an introductory language, anyway.
I plan to start my 7-year-old daughter on Elm in the next few months. She's already playing around with various introductory programming activities on Sugar OS (Turtle, etc.).
I'll report back on how it goes.
But I agree that a revived HyperCard would also be a great environment. My family was all PC growing up in the 80s, so I had no exposure to HyperCard at that time. But reading about it retrospectively, I'm impressed.
1. http://elm-lang.org/Examples.elm
Excel, the most successful programming environment for non-programmers, is functional in nature, so I don't doubt that functional is the way to go. Elm's syntax leaves me a bit more skeptical, though.
The Haskell-like syntax? Yeah, it's possible that this could be confusing for a beginner. What in particular are you skeptical about?
Positional arguments are a big nono for me. When I read the code, there's too much overhead to knowing what things do. One of the nice things about HyperTalk is that it's a bit self describing.
One of these three is entirely non-obvious
One of these three is entirely non-obvious
image 472 315 "/stack.jpg"
Insert Image "/stack.jpg" with width 472 and height 415
image {width: 472, height: 315, filename: "/stack.jpg"}How about
image Image { width = 472, height = 315, filename = "/stack.jpg" }You really need to be a motivated beginner, as elm web site does not document how to install everything at home.
It requires programming knowledge just to set it up.
It requires programming knowledge just to set it up.
Kids should start on HTML. This teaches simple coding (UI elements only) so it is great to for them to see quick results of their efforts.
Most beginner Hypercard apps were just multimedia pages hyperlinked together. You can do that now GitHub right now and publish it immediately to a web site. It was fast and easy to get my 10-year-old daughter a GitHub account and show her how to use the online editor. Then I showed her HTML and CSS and let her loose. I set up github pages and gave her instructions to pull to that branch (which took me a while to figure out but she took right to it.) She took my netbook into school the next day and blew away the kids in her project group with it. Then she got bored and hasn't wanted to mess around with it anymore. Oh well...
Most beginner Hypercard apps were just multimedia pages hyperlinked together. You can do that now GitHub right now and publish it immediately to a web site. It was fast and easy to get my 10-year-old daughter a GitHub account and show her how to use the online editor. Then I showed her HTML and CSS and let her loose. I set up github pages and gave her instructions to pull to that branch (which took me a while to figure out but she took right to it.) She took my netbook into school the next day and blew away the kids in her project group with it. Then she got bored and hasn't wanted to mess around with it anymore. Oh well...
As an interested parent (although of a 4 yr old), did she get bored because she hit a wall in what she wanted to do? With HTML its fairly easy to generate a nonlinear text and image based story, but I imagine trying to add any sort of interactivity through the mess of CSS and JavaScript might quickly lead to frustration. Unlike HyperCard, today's technologies don't seem to have a smooth learning curve as you try and build more complex things.
No she just got bored because that's her. HTML can have a smooth learning curve but its not baked-in so you need someone to manually guide them and since most adults don't know how to do this that's a problem. My point is it is solvable, not inherent.
The combination of HTML+Javascript+CSS+SQL+Python/Ruby/etc as required for a basic web app these days is getting to be too much for the beginner. I remember writing my first game in Hypercard in Grade 6 with no experience on the computer at all. Load up some art, make some buttons and build a 'choose your own adventure'. Easy stuff and lots of fun.
I had the exact same experience (e.g. creating simple point-and-click 'games' that were really just stories with multiple branches).
What's cool is that as I made these games I kept wanting to add more to them (interactivity, sounds, etc) so I ended up doing some scripting as well.
As a 12-year-old, this was amazing - my first introduction to "programming" but I didn't know that at the time.
What's cool is that as I made these games I kept wanting to add more to them (interactivity, sounds, etc) so I ended up doing some scripting as well.
As a 12-year-old, this was amazing - my first introduction to "programming" but I didn't know that at the time.
When I was 12 I made a stop motion animated dizzy egg style adventure game in HyperCard. When I was 25 I remembered and thought, hmm maybe I should try and learn how to code. I'm now a professional developer.
As an aside, I sold it to my school mates for 50p a copy. When they asked why they couldn't just copy it themselves I told them I'd installed DRM on the floppy disks.
They believed me.
As an aside, I sold it to my school mates for 50p a copy. When they asked why they couldn't just copy it themselves I told them I'd installed DRM on the floppy disks.
They believed me.
Yes it is, but you can learn it piecemeal. Using HTML only, you can add text, images, and hyperlinks to do your "choose your own adventure" example. Now that it works, want to make it look cooler? OK, here is how to use CSS. Want to add some animations and other advanced dynamic interaction? Here are some simple JavaScript functions.
A basic web app like other posters are describing is just some html+css (admittedly are awful) then javascript and local storage.
What that kind of a stack enables is potential. So you're happy with your app. Take what you already know, learn about a server and a client and make a scoreboard. Now you understand client/server you can make it collaborative. etc.
What that kind of a stack enables is potential. So you're happy with your app. Take what you already know, learn about a server and a client and make a scoreboard. Now you understand client/server you can make it collaborative. etc.
Yeah. I was making simple choose-your-own adventure stuff in grade 6 or 7 with just HTML+Javascript. There was no stack involved, just me experimenting with copy-pasting stuff I'd seen on the web.
jQuery makes even that learning curve a lot easier (e.g. $('.text-box').text() instead of whatever even hackier stuff I was using back then).
jQuery makes even that learning curve a lot easier (e.g. $('.text-box').text() instead of whatever even hackier stuff I was using back then).
Same here - HyperCard was my first experience with programming as a kid...on my old Mac Plus. I feel like it made a big impact on me, learning that I could create my own applications (I had the later version as well that let you make standalone applications - THAT was awesome!).
HyperCard was absolutely amazing. It was my introduction to computer programming as well. Hell, I even made a chat server / client based in HyperCard with a simple AppleTalk XCMD/XFCN. It still shocks me how easy everything was to put together.
I'm working with middle schoolers for the First Lego League competition. The ones with some programming experience either had a Mindstorms kit at home or were playing with mods for games. But a number of the students seem inclined towards programming, but overwhelmed by how to get started.
There's some advantage to a stupid simple DOS computer with a copy of some BASIC implementation and every math textbook from grade 3 on having BASIC programs at the end of every chapter or section.
There's some advantage to a stupid simple DOS computer with a copy of some BASIC implementation and every math textbook from grade 3 on having BASIC programs at the end of every chapter or section.
Check out scratch, in particular code.org has a nice 1 hour intro with Angry Birds and scratch that's good for kids.
I was actually working on a longer comment that would've included a mention of scratch. Right now the focus is on the robotics competition, but in the spring that may be something I try to introduce them to. The problem will be access to computers. There just aren't enough available for the entire group (though attendance has dropped recently, so unfortunately there may be enough computers to handle all of them soon).
If it helps, chromebooks are nice little laptops that can be had for a couple hundred bucks. If you have monitors and keyboards a Raspberry Pi might work well as a computer and is about $50 with SD card, power supply, etc.
Absolutely, I started on a Commodore 64 and then more basic on Apple IIgs. HyperCard opened the window on Mac programming.
I could not have gotten through my teenage years without HyperCard and ResEdit.
I could not have gotten through my teenage years without HyperCard and ResEdit.
I still have a floppy disk with my first "Choose Your Own Adventure" Hypercard game I made when I was in elementary school. I wonder if I could still get it to run...
isn't ruby touted for 'reading like english' ? I could imagine some beginner-friendly DSL or API to do very similar things.
LiveCode is a vast superset of the former HyperCard, and I work with it everyday. It's extremely utilitarian, and it's not half bad when prototyping mobile apps.
http://en.wikipedia.org/wiki/LiveCode http://LiveCode.com
http://en.wikipedia.org/wiki/LiveCode http://LiveCode.com
I loved HC, and tried out LiveCode. The problem for me is the "vast" part.
I also loved Visual Basic when it was young, but it just kept getting more complex and bloated. I think Microsoft was trying to counter the stereotype of VB being for amateurs, by making it as comprehensive as their other development tools. (cf. recent HN thread about "professional tools"). LiveCode seems to suffer from that tendency.
When it got to the point where I could no longer make sense of VB, I went language shopping. For me, the new HyperCard is Python plus Tkinter plus Matplotlib. Heaven. Granted almost every program that I write is "some buttons, parameters, computation, and a graph." The only downside is that it doesn't port to Android.
I also loved Visual Basic when it was young, but it just kept getting more complex and bloated. I think Microsoft was trying to counter the stereotype of VB being for amateurs, by making it as comprehensive as their other development tools. (cf. recent HN thread about "professional tools"). LiveCode seems to suffer from that tendency.
When it got to the point where I could no longer make sense of VB, I went language shopping. For me, the new HyperCard is Python plus Tkinter plus Matplotlib. Heaven. Granted almost every program that I write is "some buttons, parameters, computation, and a graph." The only downside is that it doesn't port to Android.
The LiveCode open-source effort was funded on Kickstarter, and was successful. I'm glad to say I was one of the sponsors.
LiveCode is fantastic.
HyperCard was ground breaking in its day for sure. I'm the CEO of LiveCode. We're an open source, modernized platform that lets you build apps for all popular platforms and devices. We still retain the best ideas from the original HyperCard. We have a vibrant active community with many successful apps developed. We also created one of the top100 Kickstarter campaigns of all time last year, to build a next generation version of the platform! Check us out at livecode.com.
LiveCode looks very attractive, but I have trouble comprehending your interpretation of the GPL.
At http://livecode.com/support/ask-a-question/at-what-point-do-... you say: "The FAQ on the FSF website states that the GPL does not apply to code simply “executed with an interpreter”. LiveCode is far more than a simple language interpreter and each language call utilizes internal libraries within the platform. These libraries provide the platform’s entire functionality and rich feature set."
However, every interpreter works by making calls to "internal libraries within the platform" which "provide the platform's entire functionality and rich feature set." If an interpreter did not contain the code to do the things that the interpreted language can do, then it wouldn't do anything at all and it wouldn't be an interpreter.
While I find LiveCode attractive, this license weirdness makes me uncomfortable enough that I haven't explored it even for my Open Source projects. It's not often that I find license interpretations that make Richard Stallman look moderate.
At http://livecode.com/support/ask-a-question/at-what-point-do-... you say: "The FAQ on the FSF website states that the GPL does not apply to code simply “executed with an interpreter”. LiveCode is far more than a simple language interpreter and each language call utilizes internal libraries within the platform. These libraries provide the platform’s entire functionality and rich feature set."
However, every interpreter works by making calls to "internal libraries within the platform" which "provide the platform's entire functionality and rich feature set." If an interpreter did not contain the code to do the things that the interpreted language can do, then it wouldn't do anything at all and it wouldn't be an interpreter.
While I find LiveCode attractive, this license weirdness makes me uncomfortable enough that I haven't explored it even for my Open Source projects. It's not often that I find license interpretations that make Richard Stallman look moderate.
We're working on it for iPad. http:///www.hyperpad.com
Still fairly early, and not where we want it. But it's coming along...
This piece originally appeared on Medium, and has been reprinted with permission.
The original article is much nicer to read:
https://medium.com/@blprnt/the-hypercard-legacy-e5b9eb273b6a
The original article is much nicer to read:
https://medium.com/@blprnt/the-hypercard-legacy-e5b9eb273b6a
Yes. Url changed from http://www.buzzcarl.com/its-time-to-revive-hypercard.
"This type of plain-language programming makes sense, particularly in an application that was designed specifically for non-programmers."
Sweet merciful crap, no. I loved Hypercard as a kid but I could never get my head around the English-but-not-quite programming style of the script. Any time I've tried to do anything with Applescript over the years, I just end up giving up and doing it some other way.
A DSL would be better than this approach, or a language that has a decently smooth learning curve.
Sweet merciful crap, no. I loved Hypercard as a kid but I could never get my head around the English-but-not-quite programming style of the script. Any time I've tried to do anything with Applescript over the years, I just end up giving up and doing it some other way.
A DSL would be better than this approach, or a language that has a decently smooth learning curve.
This. I still remember the one and only time I tried doing a scripted app in HyperCard. I spent an entire day constantly fighting with the contextual definitions of keywords, literally playing a Clintonesque game of quibbling over the definition of 'is' and 'it'.
I completely agree. Natural Language style programming with AppleScript is incredibly difficult. I don't think hypertalk was that much better.
As a web developer and someone who programs in a superset of HyperCard (LiveCode) - I must say it was moderately difficult to grasp in the beginning. Strangely enough things that are required for your day job tend to have a way of getting learned. The hardest part for me was not the syntax, but the fact the IDE and the language are so inter-connected.
It's actually a fairly quick way of prototyping mobile apps for iOS/Android - which is one of the main things I use it for at work. Though, I am probably incredibly biased.
They recently(2012) open sourced the IDE, http://LiveCode.com
It's actually a fairly quick way of prototyping mobile apps for iOS/Android - which is one of the main things I use it for at work. Though, I am probably incredibly biased.
They recently(2012) open sourced the IDE, http://LiveCode.com
Actually I still found it easier than Lingo, I wrote a bunch of things while in art school in the 90s but when java applets took off I wound up abandoning hypercard for java.
Some people used to call HyperTalk “Visual COBOL”
Yes. You can write statements which are both valid HyperTalk and COBOL. This is not a good thing.
It went downhill from there:
Put field 2 of card 54 into field 5 of card 71
You could name fields, but it went visibly slower if you did.
There's visual programing, where you drag boxes around and connect them. This comes back every few years. Simple examples look great. Larger program are awful. Blender, the animation system, has a game development system like that. Programs are single huge, messy wiring diagrams. Programming requires lots of zooming and scrolling.
There's a reason that IC designers gave up schematics for VHDL.
It went downhill from there:
Put field 2 of card 54 into field 5 of card 71
You could name fields, but it went visibly slower if you did.
There's visual programing, where you drag boxes around and connect them. This comes back every few years. Simple examples look great. Larger program are awful. Blender, the animation system, has a game development system like that. Programs are single huge, messy wiring diagrams. Programming requires lots of zooming and scrolling.
There's a reason that IC designers gave up schematics for VHDL.
If you want to see programming-as-carefully-formatted-English taken to the extreme, check out Inform 7, a system for writing interactive fiction. For example, here is the complete source of a game:
http://inform7.com/learn/eg/glass/source.txt
http://inform7.com/learn/eg/glass/source.txt
Anyone remember the cryptic document that _why posted in the form of a printer spool [1], years after his disappearance from programming? It was a sort of fictional, surrealist autobiography.
[1] http://www.scribd.com/doc/136875051/why-s-complete-printer-s...
I was grinning madly when I noticed -- in the part where he's exploring an island -- the page written in syntactically valid Inform 7.
[1] http://www.scribd.com/doc/136875051/why-s-complete-printer-s...
I was grinning madly when I noticed -- in the part where he's exploring an island -- the page written in syntactically valid Inform 7.
Assuming:
> Put field 2 of card 54 into field 5 of card 71
> Card71[5] := card54[2]
> cards[71][5] = cards[54][2]
Borland's ObjectVision had me jump into a rabbit hole for awhile, until I retreated back into (pre-Visual) FoxPro, as I kept running into limitations of the ObjectVision language.
[deleted]
I think something that would:
* Take the original idea of Hypercard and take it into the 21st century.
* Be completely open source.
* Export to HTML/CSS/JS and perhaps native for performance sensitive things.
* Would run as well on desktop as on mobile browsers.
* Maybe have a (subset) of Javascript, Lua or Python as a scripting language.
* Be as fun, easy and playful as the original.
Would definitely be something i'd support on a platform like Kickstarter.
* Take the original idea of Hypercard and take it into the 21st century.
* Be completely open source.
* Export to HTML/CSS/JS and perhaps native for performance sensitive things.
* Would run as well on desktop as on mobile browsers.
* Maybe have a (subset) of Javascript, Lua or Python as a scripting language.
* Be as fun, easy and playful as the original.
Would definitely be something i'd support on a platform like Kickstarter.
It's not exactly a Hypercard-alike, but have you take a look at Twine? http://twinery.org
The 2.0 version is a choose-your-own adventure generator that can go from simple (create 'pages', make one-way links between them) to complex (use CSS + Javascript to create multiple panes, keep track of variables, write graphics, etc), and it exports as a Tiddlywiki-based self-contained HTML file.
The 2.0 version is a choose-your-own adventure generator that can go from simple (create 'pages', make one-way links between them) to complex (use CSS + Javascript to create multiple panes, keep track of variables, write graphics, etc), and it exports as a Tiddlywiki-based self-contained HTML file.
Export to HTML/CSS/JS and perhaps native for performance sensitive things.
A minor nitpick but "native" is almost always unnecessary for this kind of programming. We have WebGL and soon, SIMD.js. Things are looking good on the performance front.
I think it'd be more important to focus on making WebGL support better on lower-end mobile devices or have a downgrade path to canvas or some other maguffin.
Maybe have a (subset) of Javascript, Lua or Python as a scripting language.
All of these languages are fine in their own right but they fall on the floor for being user-friendly when your user is someone whose vocabulary is not a part of the programming lexicon.
But they could be useful to people who do understand their models of execution.
I'd be more apt to suggest giving the users a kernel upon which any appropriate language can be integrated into the system for the user to select.
A minor nitpick but "native" is almost always unnecessary for this kind of programming. We have WebGL and soon, SIMD.js. Things are looking good on the performance front.
I think it'd be more important to focus on making WebGL support better on lower-end mobile devices or have a downgrade path to canvas or some other maguffin.
Maybe have a (subset) of Javascript, Lua or Python as a scripting language.
All of these languages are fine in their own right but they fall on the floor for being user-friendly when your user is someone whose vocabulary is not a part of the programming lexicon.
But they could be useful to people who do understand their models of execution.
I'd be more apt to suggest giving the users a kernel upon which any appropriate language can be integrated into the system for the user to select.
LiveCode
* Yes
* Community Version is open source
* On the LiveCode roadmap
* Compiles as a native app for iOS,Android,Mac,Win and soon HTML 5
* No, but ... the ability to wrap other languages and libraries and map them to HyperTalk is in development: http://livecode.com/blog/2014/07/08/the-next-generation-widg...
* Definitely as fun as the original
Sorry if I am coming off as a fan boy, but I read HN everyday, and this is the first time I've seen HyperCard/HyperTalk come up.
* Yes
* Community Version is open source
* On the LiveCode roadmap
* Compiles as a native app for iOS,Android,Mac,Win and soon HTML 5
* No, but ... the ability to wrap other languages and libraries and map them to HyperTalk is in development: http://livecode.com/blog/2014/07/08/the-next-generation-widg...
* Definitely as fun as the original
Sorry if I am coming off as a fan boy, but I read HN everyday, and this is the first time I've seen HyperCard/HyperTalk come up.
Of course, I'm in.
[deleted]
I had no idea before reading this article that HyperCard dated back to 1987. It was still being used in my fifth grade classroom in 1996 (I remember it vividly because that was the year I won my county fair's "multimedia" competition with a HyperCard stack!).
As a kid, everyone I knew who liked computers loved HyperCard. It was an amazing learning tool and I still find myself reminiscing about it like the author of the article.
As a kid, everyone I knew who liked computers loved HyperCard. It was an amazing learning tool and I still find myself reminiscing about it like the author of the article.
How many computer users need automation but haven't the time or aptitude to program? The answer is far more than will ever buy the Apple Watch. But universal access to programming/automation doesn't appear to be on Apple's radar as OSX Automator languishes while Zapier, IFTT, MIT Android Development Kit, and Google Apps Script sort of and inadequately fill the gap. Apple has everything in place for a cloud reimplementation and refresh of Hypercard, apart from apparent interest.
Once a programmer, I appreciate the efficiency of automation. But today I'm old-ish, run a business, have kids and although my need to automate is greater than ever, there is simply no time to do so using, say, Python.
Hypercard... I miss you.
Once a programmer, I appreciate the efficiency of automation. But today I'm old-ish, run a business, have kids and although my need to automate is greater than ever, there is simply no time to do so using, say, Python.
Hypercard... I miss you.
>my need to automate is greater than ever, there is simply no time to do so using, say, Python
What kind of tasks do you need to automate? Zapier and IFTTT are both pretty powerful tools (and I say that as a programmer who uses Python to automate most quick, mundane tasks).
What kind of tasks do you need to automate? Zapier and IFTTT are both pretty powerful tools (and I say that as a programmer who uses Python to automate most quick, mundane tasks).
> I have been teaching programming to designers and artists for nearly a decade, and I find the largest concern for learners to be not with the conceptual hurdles involved in writing a program, but with obscure and confusing syntax requirements.
Confusing syntax is certainly a problem, don't get me wrong, but I have found that the above is not entirely true (in my limited experience). A lot of times once you want to commit an idea you have to a program, you discover that the idea in your head is actually quite ambiguous and difficult to describe, regardless the language.
When I think about the difficulties of programming, I separate the problems into "real" and "fake". Understanding truthy values in Javascript falls decidedly in the "fake" category. On the other hand, "find all the birds in this picture" is legitimately hard. I believe that a lot of the things "normal people" would want to do would require some genuine patience, thinking, and time to figure out (which I think is the real hurdle of programming). This is why we see a lot more success in programming systems that tackle incredibly specific problems, and why these systems are often even more appealing to programmers:
1. Arithmetic and equation solvers (Calculator.app).
2. Drawing programs that just describe and manage a non destructive image-processing pipeline (Photoshop.app/Illustrator).
3. Sound mixing applications (Garage Band)
In each of these examples, the system has given up a lot of flexibility in order to make that specific task so much easier. As a trivial example, most calculators are nicer to use, and look nicer, than typing math in a language console.
Perhaps all of these tasks could theoretically be possible in some "perfect" language, but I find it very suspect that they'd be better at it. It's just hard to make a tool thats good for everything also be better at everything. Its certainly the case that I'd rather use PaintCode or PhotoShop to take an existing image and mutate it today, and I'm a programmer: we haven't even solved making our core audience prefer programming in a lot of cases.
Separately, I'm not entirely convinced that the world is perfectly split into "typing programmers" and "connect the noodles" quartz-composer programmers. I think many of the visual systems we've developed end up having just as many quirks as the language ones. Certainly different quirks, but if in a parallel universe HyperCard and QuartzComposer-style programming had won, we'd maybe have just as many programmers as today and those guys would be wondering "how do we get people who think in terms of text to program?".
Confusing syntax is certainly a problem, don't get me wrong, but I have found that the above is not entirely true (in my limited experience). A lot of times once you want to commit an idea you have to a program, you discover that the idea in your head is actually quite ambiguous and difficult to describe, regardless the language.
When I think about the difficulties of programming, I separate the problems into "real" and "fake". Understanding truthy values in Javascript falls decidedly in the "fake" category. On the other hand, "find all the birds in this picture" is legitimately hard. I believe that a lot of the things "normal people" would want to do would require some genuine patience, thinking, and time to figure out (which I think is the real hurdle of programming). This is why we see a lot more success in programming systems that tackle incredibly specific problems, and why these systems are often even more appealing to programmers:
1. Arithmetic and equation solvers (Calculator.app).
2. Drawing programs that just describe and manage a non destructive image-processing pipeline (Photoshop.app/Illustrator).
3. Sound mixing applications (Garage Band)
In each of these examples, the system has given up a lot of flexibility in order to make that specific task so much easier. As a trivial example, most calculators are nicer to use, and look nicer, than typing math in a language console.
Perhaps all of these tasks could theoretically be possible in some "perfect" language, but I find it very suspect that they'd be better at it. It's just hard to make a tool thats good for everything also be better at everything. Its certainly the case that I'd rather use PaintCode or PhotoShop to take an existing image and mutate it today, and I'm a programmer: we haven't even solved making our core audience prefer programming in a lot of cases.
Separately, I'm not entirely convinced that the world is perfectly split into "typing programmers" and "connect the noodles" quartz-composer programmers. I think many of the visual systems we've developed end up having just as many quirks as the language ones. Certainly different quirks, but if in a parallel universe HyperCard and QuartzComposer-style programming had won, we'd maybe have just as many programmers as today and those guys would be wondering "how do we get people who think in terms of text to program?".
Tangentially, what you're referring to as "real" and "fake" problems also go by the names "essential complexity" and "accidental complexity". Essential complexity is the inherent difficulty of the problem you're trying to solve. Accidental complexity is anything else that gets in the way: difficult tooling, annoying processes, useless bureacracy, etc.
There's a bit more discussion here: https://en.wikipedia.org/wiki/No_Silver_Bullet#The_argument
There's a bit more discussion here: https://en.wikipedia.org/wiki/No_Silver_Bullet#The_argument
Ok, but there is no reason per se why Photoshop.app or Garage Band could not be easily connectable to other stuff through programming. We could have the best of both worlds if it were not for social/business issues.
The disgusting thing is that we seem to be moving in the opposite direction -- more walled gardens, more dumbing down of the interfaces for its own sake, more incidental complexity on the development tools side for its own sake.
The disgusting thing is that we seem to be moving in the opposite direction -- more walled gardens, more dumbing down of the interfaces for its own sake, more incidental complexity on the development tools side for its own sake.
I absolutely agree with this point. I think there might be incredible potential in just getting the different existing tools playing nicer together. When I was working in gaming I was blown away that the native formats the game engines used were the same as the 3d graphics tools. It was great, a modeler would make nodes and animations in his world, and I'd have access to them in mine -- we were speaking the same language but each of us interoperating with our specific piece the way we wanted to. Compare this to "2D" programming where there is often incredible friction going from PhotoShop to what we use. Exporting to the right format, slicing, (dealing with different resolutions). Everyone wants to somehow magically take the PSD file and just use it as their UI (and many companies have been trying to do this admittedly), its the dream.
I'm no android fanboy (I find their development environment heavy and full of boilerplate) but I would like to see their intent/activity model replicated elsewhere. Using an android phone or tablet, you really see app symbiosis (a task may be fulfilled by many applications, dispatch happens at runtime and is user-driven)
There is a reason why Photoshop and Garage Band are not easily connectable to other stuff through programming. Writing useful flexible APIs is incredibly hard work.
And, as it turns out, Photoshop is scriptable and has a plug-in API.
And, as it turns out, Photoshop is scriptable and has a plug-in API.
Totally disagree. We're moving in the direction of publicly-available APIs, standards-driven development, open-source development tools, and a wider variety of interfaces.
The old Amiga from 1985 actually worked like this. Everything was scriptable in Rexx, you could wire apps together anyway you liked.
To me the antithesis to this line of thought is a scene from Star Trek Next Gen where Geordi is on the holodeck and instructs the computer to create a table, then goes thru a few iterations (4?) before he gets something similar to what he wanted. Did he say actually say "that'll do"? I don't recall. Makes me think there are unintended consequences here.
That quote bring back a thought i had the other day that computing "went to hell" when designers became "programmers". This via Flash, JS and PHP.
There are so many things to admire about the vision of HyperCard and computing for the people. But HyperTalk is not one of those things. HyperTalk deserves to be forgotten, though the greater vision needs to live on.
Well, you're entitled to your opinion. I learned to program in HyperTalk as a kid and loved it. I still miss it. AppleScript, on the other hand, I can't stand. I think the difference is that HyperTalk can be considered a DSL for the HyperCard environment and I think it succeeded there.
How does HyperCard compare to Scratch?
http://scratch.mit.edu/
It's on iPad: http://www.scratchjr.org/
It also integrates with hardware: http://education.lego.com/en-us/preschool-and-school/lower-p...
Do we still need to revive HyperCard?
http://scratch.mit.edu/
It's on iPad: http://www.scratchjr.org/
It also integrates with hardware: http://education.lego.com/en-us/preschool-and-school/lower-p...
Do we still need to revive HyperCard?
I love the idea behind scratch, but I've found the implementation to be a bit lacking at times. It's buggy in ways, the support for variables is quite basic and difficult to use, and there's just a lot of rough edges around stuff that should work like copy/paste and shared functions.
Perhaps we just need to focus some open-source energy on it.
Perhaps we just need to focus some open-source energy on it.
Yeah it could use help. Scratch is really just a heavily modified version of Disney's flavor of Smalltalk. I think it was called Squeek.
To continue the conversation it's important to remember the environment that Hypercard was born in: there was no Python, Ruby, or Javascript. The major alternatives were just C or C++ (right?). That is no longer the case. Consequently I'm not really sure it needs to be reborn.
Speaking of Javascript:
http://codecombat.com/
http://www.kuatostudios.com/games/hakitzu-elite/
To continue the conversation it's important to remember the environment that Hypercard was born in: there was no Python, Ruby, or Javascript. The major alternatives were just C or C++ (right?). That is no longer the case. Consequently I'm not really sure it needs to be reborn.
Speaking of Javascript:
http://codecombat.com/
http://www.kuatostudios.com/games/hakitzu-elite/
Wait, what??
Squeak is a modern, full-featured Smalltalk. It is closely related to Pharo, a cleaner, leaner fork. (Both of these put mainstream languages like Java to shame.)
Scratch is simply a kid-friendly DSL built in Squeak. Big difference!
Squeak is a modern, full-featured Smalltalk. It is closely related to Pharo, a cleaner, leaner fork. (Both of these put mainstream languages like Java to shame.)
Scratch is simply a kid-friendly DSL built in Squeak. Big difference!
Apparently up until the release last year it actually was based on a Squeak virtual machine: http://wiki.scratch.mit.edu/wiki/Squeak_Tutorial
Preferably with a better language, but yes.
It's time to revive Hyperwocky
I have fond memories of HyperCard from school growing up. Our school computers had a locked down shell to restrict us to certain applications. However, it was trivial to write a script in HyperCard to close the shell application, exposing the Finder underneath.
Does anyone else remember HyperStudio? It was like HyperCard, but more multimedia features. Despite the name and function similarities, I'm not sure if there is any formal connection between the two.
Does anyone else remember HyperStudio? It was like HyperCard, but more multimedia features. Despite the name and function similarities, I'm not sure if there is any formal connection between the two.
was the shell At Ease? http://en.wikipedia.org/wiki/At_Ease
Haha memories, that may be the first time I ever tried to exploit a system
Haha memories, that may be the first time I ever tried to exploit a system
Haha - it was, indeed. I received at least one temporary ban from the computer lab for my endeavors.
I've seen a lot of big-hearted attempts to bring Hypercard back. I haven't seen a convincing (to me) analysis of why it sputtered out in the first place. Without that knowledge, I don't think any resuscitations can succeed.
I've had the chance to talk a bit with Bill Atkinson about this. I think there are a few things at play here.
First, HC was built before the popularization of the internet, and as such a distribution model for stacks didn't really exist. I can literally remember mailing stacks on floppy disks. So, people could make things, but not easily share them.
Second, there was a fundamental shift in which software became a commodity. I really think in the beginning it was about selling computers; it took a while for people to realize that software was not a 'value add' for the machine but a place to make much, much more money.
So when HC was conceived, it seemed natural to provide a tool to let people author their own software. As the business model changed, this idea lost out. Software should be something that people bought, not something people made
First, HC was built before the popularization of the internet, and as such a distribution model for stacks didn't really exist. I can literally remember mailing stacks on floppy disks. So, people could make things, but not easily share them.
Second, there was a fundamental shift in which software became a commodity. I really think in the beginning it was about selling computers; it took a while for people to realize that software was not a 'value add' for the machine but a place to make much, much more money.
So when HC was conceived, it seemed natural to provide a tool to let people author their own software. As the business model changed, this idea lost out. Software should be something that people bought, not something people made
As I understand the history, a couple of things happened. First, HC got kicked around from one business entity to another, and was never wholeheartedly supported by Apple. It was kind of an orphan. There are legends that Bill Atkinson had to go ballistic in order to get it included with the Mac at all.
Second, HC reached its zenith (the final version was a real improvement over its predecessors) just as Apple went into somewhat of a dark age in between System 7 and OS X.
I loved my Mac but never felt that Apple was interested in encouraging indie or small-scale software development. I can't say that Windows was any better, but Windows had a built in lightweight API called MS-DOS.
Continuing my revisionist history, I think what happened next is simply that desirable computer system features proliferated more rapidly than any development tool could keep up with. And the diversity of interests in programming is what would stymie such a revival today.
Second, HC reached its zenith (the final version was a real improvement over its predecessors) just as Apple went into somewhat of a dark age in between System 7 and OS X.
I loved my Mac but never felt that Apple was interested in encouraging indie or small-scale software development. I can't say that Windows was any better, but Windows had a built in lightweight API called MS-DOS.
Continuing my revisionist history, I think what happened next is simply that desirable computer system features proliferated more rapidly than any development tool could keep up with. And the diversity of interests in programming is what would stymie such a revival today.
In my opinion, it's not that we need a new HyperCard, we need a HyperCard for handhelds, like tablets and smartphones. On-device programming, accessible by the layman. Microsoft Research's TouchDevelop is definitely doing some cool work there: http://www.touchdevelop.com
ScriptKit for iPad is another really cool effort in this arena: http://scriptk.it
"Which, of course, begs the question: What happened to HyperCard?" That's not begging the question. You are bringing up the question.
But statements like the following suggest to me that there are some misunderstandings here.
> With the developer restrictions and extreme proprietism of the iPhone App Store, it’s hard to remember the Apple of the 80s. Steve Jobs, Bill Atkinson and their team had a vision to not only bring computers to the people, but also to bring computer programming to the public – to make makers out of the masses. At Apple, this philosophy, along with HyperCard seems to have mostly been lost.
Making makers out of the masses is an idea that is still there. Think about software like GarageBand and iMovie. These have the added advantage that you can make things without doing programming.
Also, I was very much involved with the Apple of the 80s. And I can assure you all that the "proprietism" was just as strong as it is today.
While it's exciting to see Hypercard and similar ideas coming alive again, I'm certainly glad that Hypercard died when it did. A Hypercard-based web would have been Apple formats distributed from Apple servers via Apple protocols to Apple clients. And lawsuits for everyone! We're fortunate to have dodged that particular scenario.