Slashdot Mirror
Why Was Hypercard Killed?
theodp writes "Steve Jobs took the secret to his grave, but Stanislav Datskovskiy offers some interesting and illustrated speculation on why HyperCard had to die. 'Jobs was almost certainly familiar with HyperCard and its capabilities,' writes Datskovskiy. 'And he killed it anyway. Wouldn't you love to know why? Here's a clue: Apple never again brought to market anything resembling HyperCard. Despite frequent calls to do so. Despite a more-or-less guaranteed and lively market. And I will cautiously predict that it never will again. The reason for this is that HyperCard is an echo of a different world. One where the distinction between the "use" and "programming" of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple's walled garden aesthetic has no place.' Slashdotters have bemoaned the loss of HyperCard over the past decade, but Datskovskiy ends his post on a keep-hope-alive note, saying: 'Contemplate the fact that what has been built once could probably be built again.' Where have you gone, Bill Atkinson, a nation of potential programmers turns its lonely eyes to you."
Supercard didn't flourish. The market was just too tiny. In many ways, Filemaker and similar apps filled the niche.
If people REALLY wanted a Hypercard-like program, there were alternatives.
So, you believe Apple is a bunch of fascists, and for that reason they killed one of their programming languages? Baloney. Steve Jobs was the one on stage at NeXT showing how even a child could write GUI apps. He made XCode free and bundled it with every boxed copy of OS X back in 2001 when Microsoft required a paid dev account.
Or, it could be that all those fond memories of Hypercard are exaggerated. I can't recall even one such application that was useful apart from simple educational games. The challenge in creating a GUI-based development system has been tackled many times. The most recent one that I have used is the default Mindstorms programming environment LabView, which I quickly discarded for a gcc-based environment.
The one killing blow that keeps me from really using these environments is that they are fundamentally incompatible with version control. This means that they cannot be large projects, or have much collaboration -- relegating them to trivial systems, which are all I remember Hypercard being.
The wheel is turning, but the hamster is dead.
Agree.
Also, if people didn't want to program, Excel wouldn't be so damned popular. Excel and other spreadsheet systems are used 90% of the time as an IDE with a really good integration of data and logic.
Always thought Microsoft missed a trick by not integrating Excel into Windows, actually making it the shell. They make have pissed off a lot of computer snobs, but there'd have been a dramatic improvement in usability - as in advanced features being intuitively used by regular users, and it'd probably have put the final nail in Apple's coffin.
Alas, they thought web browsers would make a better shell, and, well, now it looks like we'll all be working on iPads. Great.
You are not alone. This is not normal. None of this is normal.
When I design a GUI I want limits around how the end-user can customize it...unless it really easy to reset it to the default values.
Actually, I think this is the biggest problem with GUIs: that the developer can lock down the end-user from customising it. You're not me, you don't know how I like my desktop to look, it's really not your business telling me what my GUI should look like unless you're paying for my computer.
See, as a user, what I really want isn't a whole pile of non-interacting "applications", each of which thinks it's the best thing since sliced Marmite, loosely joined by a filesystem and OS in which they savagely compete for my attention. What I want is to build a personalised workflow of "data I really care about" and "stuff I want to do to that data", and your application-developer mindset about what you want your application to look and feel like doesn't really appear on my radar at all. I want something a bit like a giant spreadsheet where I can plug in every possible data source and transformation as just sort of functions out of a toolbox. I don't want applications, and I especially don't want "apps", as in super-dumbed-down applications which don't even believe in using a shared filesystem.
But the way we've built things at the moment, we've priviledged this rather out of date concept of "application", and left the idea of "data" in the dust. And the GUI model has somehow lent itself to that. I think mostly because the GUIs we've built have been excessively cranky and explosive contraptions which melt down at the slightest touch of a pixel out of place. I'd like to think that that doesn't have to be the way of the future. Shouldn't a GUI just be something like a skin over the data which is already there? But we've never made a way to expose the raw data without doing so in shiny chunks of non-user-accessible pixels. Would be nice to change that.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC