6 ms·

Honestly, people need to get over HyperCard. Yes it was cool, but there’s no conspiracy behind its demise. It died because the World Wide Web accomplished basi

Honestly, people need to get over HyperCard. Yes it was cool, but there’s no conspiracy behind its demise. It died because the World Wide Web accomplished basically the same thing, not initially as elegantly or powerfully, but open and universal (and today, very much more capable than HyperCard was). HyperCard usage declined and Apple gave up on it. It’s not complicated.

nabla9 6y ago
> World Wide Web accomplished basically the same thing, This is incorrect and I'm convinced that you agree after you think it little more. HyperCard was tool for non-programmers. Like spreadsheet. Web is not alternative to HyperCard. You have to learn web programming to do anything. We should not get over it, but create replacement or recreate it.
- parasubvert 6y ago
  The Web was a gateway tech for a whole generation of “non programmers”, and for at least its first 10-15 years (through 2005 or so) you could build reasonable sites without being a programmer. But as with all simple things in tech, there are more people whose pay depends on complexity. And so Web 2.0 rose and CSS+JavaScript became what it is today.
  - throwanem 6y ago
    You still can build reasonable sites in the circa-2005 style - I'm actually helping one of my mentees work through doing just that, as a way to learn the basic concepts of web dev without having to fight through all the added abstraction that more modern tools involve. (If anything, it's easier today to build a circa-2005 style site than it was in 2005! The native API has grown up enough that you don't need jQuery any more, and honestly good riddance.) The trouble with the circa-2005 web is that it wasn't actually all that simple. You still had similar complexity to what people do today, but not very many ways to make that complexity manageable. So it was very easy to create situations in which things went wrong a lot and you couldn't really figure out why - something I think the rosy glow of nostalgia easily obscures, these days. My early career, in hindsight, really was built on dealing with that kind of "unfixable" complexity, finding ways to reduce or replace it or at least make it more manageable - if often just in self-defense, as I typically was also largely responsible for maintaining the same stuff I built. The "capstone project" of that phase was something that we would today describe as an SPA, built in 2011 when the concept barely existed - I hadn't set out to (re)invent that wheel, nor did I even understand until a few years later that that was what I had done, but I found my way to it as the only reasonable option for coping with the essential complexity of the user interaction it expressed, and it worked really well! That work was for one of our biggest contracts, which we were at risk of losing if I didn't find a way to fix their broken and unusable registration process. It would probably have sunk the company if I'd failed. Reworking it into an SPA avant la lettre solved the problem and saved the contract, and it was some of the hardest work I've ever done precisely because, at that time, there were no tools to help manage all that complexity. It's only gotten easier since then, as successive frameworks have built on prior work in removing accidental complexity and making essential complexity easier to express and manage. Yes, today's tools are themselves more complicated than jQuery or whatever, sure. That's fair. You need to spend more time learning how to get the most out of them, that's also true. But the tools also do more, and largely do it in ways that are worth having. A Bridgeport mill takes a lot more learning than a chisel, too, and you can do a lot more damage with a Bridgeport mill used wrongly. Used rightly, though, you can achieve far more with a Bridgeport mill, far more quickly and easily, than any chisel in the history of the world could ever let you do.
    - parasubvert 6y ago
      I agree, though I think the same can be said for HyperCard. Extending it was complicated.
- TetOn 6y ago
  > You have to learn web programming to do anything. Sorry, but I don't see how that is at all different than "you have to learn the Hypercard scripting language to do anything."
  - deleted 6y ago
    [deleted]
  - throwanem 6y ago
    You could learn enough HyperTalk to do useful things inside a day - I know; I did exactly that, when I was 11 or 12 and had a chance to find out on a Mac at the museum where an uncle of mine then worked. Granted I already had experience with Apple BASIC, so wasn't a complete programming novice, but I'd never worked in a graphical environment before, and yet still managed to turn out a fairly presentable, if short, "choose your own adventure" style game with some complex world state in just a few hours. It would be utterly risible to suggest that a child of similar age and prior experience could do the same today, starting from scratch with web technologies. Yes, you can do more with the modern web. But the initial complexity barrier is very much higher.
    - parasubvert 6y ago
      Not that risable: my 11 year old has gone through the Python Crash Course book and built a basic Django pizza ordering website with a database in a day. That’s after work his way through much of the book, of course, but... as with any complex domain, the right teacher can make a big difference.
      - throwanem 6y ago
        I think that goes to both your point and mine; sure, the website does a little more in that it can be accessed from computers other than the one where it's running, but he also needed a whole book to do not much more than scratch the surface of what we call "web programming". That's not to say it isn't a significant accomplishment, and he should be proud of it!
- yoz-y 6y ago
  > We should not get over it, but create replacement or recreate it. I feel that enough people complain about it not existing and then quickly proceed to not recreating it. If there was market for this, it would exist. I've never used Hyper Card, but I guess that for prototyping of 'real software', programs like InVision work. Most of the trivial programs you could create with HyperCard (from the examples shown) can be recreated in other software (like excel or soulver) or already exist.
- burlesona 6y ago
  I learned how to build web pages by hand writing HTML and copy pasting it into Geocities when I was 9. It wasn’t real programming then and it isn’t now. Don’t mistake the explosion of JavaScript land for being the same thing as the World Wide Web. Static websites are as easy to build now as they were in 1995, and in some ways easier.
mumblemumble 6y ago
I think that TFA said it well, if brusquely: > And if you think that XCode, Python, Processing, or the shit soup of HTML/Javascript/CSS are any kind of substitute for HyperCard, then read this post again. The thing that made HyperCard great was that it wasn't very capable. Which made it approachable.
- mpweiher 6y ago
  Sure, Xcode today isn't a substitute. But Xcode is a large step back from what NeXTstep had, at least when it comes to this kind of capability. The standalone Interface Builder had palettes, which you could fill with custom objects. There were third party palettes that allowed non-programmers to click together and configure custom applications for specific domains. There were palettes that extended the whole shebang with scripting languages so that you could also add custom logic in Interface Builder.
  - debo_ 6y ago
    I hope that "extended the whole shebang with scripting languages..." was an intentional pun.
  - spacedcowboy 6y ago
    That's no different to Xcode. You just need to decorate properties for simple things, and maybe write a setup method or two if you want live-updates (eg to pull a weather map from a server)... Google @IBInspectable and @IBDesignable. Unless you're saying that the most recent versions of Xcode don't do that, which would be news to me. I agree that it's not well-used, but that's not the fault of Xcode. As far as I can tell it provides everything you'd need.
    - mpweiher 6y ago
      I am familiar with IBInspectable and IBDesignable, and have, for example, put my own Smalltalk and Postscript implementations in IB that way. Not the same thing. At all. Not even close. Palettes were final-packaged components that were at the same level as pre-built ones. IBDesignable is a way for adding some interactivity to the views you are creating for an app while you're building said app. Like SwiftUI Previews. And it works about as well, that is not really at all. With IBDesignable, Xcode was continually trying to build the entire dependency tree, meaning for example the entire Postscript interpreter. And failing >50% of the time, which then kills your view. I hear the same happens with SwiftUI previews once your project gets bigger. It certainly happened to me almost immediately when I was trying it out. Again, they're not even close.
seumars 6y ago
>not initially as elegantly or powerfully i wouldn't call the web elegent or powerful today either

nabla9 6y ago

> World Wide Web accomplished basically the same thing, This is incorrect and I'm convinced that you agree after you think it little more. HyperCard was tool for non-programmers. Like spreadsheet. Web is not alternative to HyperCard. You have to learn web programming to do anything. We should not get over it, but create replacement or recreate it.

parasubvert 6y ago
The Web was a gateway tech for a whole generation of “non programmers”, and for at least its first 10-15 years (through 2005 or so) you could build reasonable sites without being a programmer. But as with all simple things in tech, there are more people whose pay depends on complexity. And so Web 2.0 rose and CSS+JavaScript became what it is today.
- throwanem 6y ago
  You still can build reasonable sites in the circa-2005 style - I'm actually helping one of my mentees work through doing just that, as a way to learn the basic concepts of web dev without having to fight through all the added abstraction that more modern tools involve. (If anything, it's easier today to build a circa-2005 style site than it was in 2005! The native API has grown up enough that you don't need jQuery any more, and honestly good riddance.) The trouble with the circa-2005 web is that it wasn't actually all that simple. You still had similar complexity to what people do today, but not very many ways to make that complexity manageable. So it was very easy to create situations in which things went wrong a lot and you couldn't really figure out why - something I think the rosy glow of nostalgia easily obscures, these days. My early career, in hindsight, really was built on dealing with that kind of "unfixable" complexity, finding ways to reduce or replace it or at least make it more manageable - if often just in self-defense, as I typically was also largely responsible for maintaining the same stuff I built. The "capstone project" of that phase was something that we would today describe as an SPA, built in 2011 when the concept barely existed - I hadn't set out to (re)invent that wheel, nor did I even understand until a few years later that that was what I had done, but I found my way to it as the only reasonable option for coping with the essential complexity of the user interaction it expressed, and it worked really well! That work was for one of our biggest contracts, which we were at risk of losing if I didn't find a way to fix their broken and unusable registration process. It would probably have sunk the company if I'd failed. Reworking it into an SPA avant la lettre solved the problem and saved the contract, and it was some of the hardest work I've ever done precisely because, at that time, there were no tools to help manage all that complexity. It's only gotten easier since then, as successive frameworks have built on prior work in removing accidental complexity and making essential complexity easier to express and manage. Yes, today's tools are themselves more complicated than jQuery or whatever, sure. That's fair. You need to spend more time learning how to get the most out of them, that's also true. But the tools also do more, and largely do it in ways that are worth having. A Bridgeport mill takes a lot more learning than a chisel, too, and you can do a lot more damage with a Bridgeport mill used wrongly. Used rightly, though, you can achieve far more with a Bridgeport mill, far more quickly and easily, than any chisel in the history of the world could ever let you do.
  - parasubvert 6y ago
    I agree, though I think the same can be said for HyperCard. Extending it was complicated.
TetOn 6y ago
> You have to learn web programming to do anything. Sorry, but I don't see how that is at all different than "you have to learn the Hypercard scripting language to do anything."
- deleted 6y ago
  [deleted]
- throwanem 6y ago
  You could learn enough HyperTalk to do useful things inside a day - I know; I did exactly that, when I was 11 or 12 and had a chance to find out on a Mac at the museum where an uncle of mine then worked. Granted I already had experience with Apple BASIC, so wasn't a complete programming novice, but I'd never worked in a graphical environment before, and yet still managed to turn out a fairly presentable, if short, "choose your own adventure" style game with some complex world state in just a few hours. It would be utterly risible to suggest that a child of similar age and prior experience could do the same today, starting from scratch with web technologies. Yes, you can do more with the modern web. But the initial complexity barrier is very much higher.
  - parasubvert 6y ago
    Not that risable: my 11 year old has gone through the Python Crash Course book and built a basic Django pizza ordering website with a database in a day. That’s after work his way through much of the book, of course, but... as with any complex domain, the right teacher can make a big difference.
    - throwanem 6y ago
      I think that goes to both your point and mine; sure, the website does a little more in that it can be accessed from computers other than the one where it's running, but he also needed a whole book to do not much more than scratch the surface of what we call "web programming". That's not to say it isn't a significant accomplishment, and he should be proud of it!
yoz-y 6y ago
> We should not get over it, but create replacement or recreate it. I feel that enough people complain about it not existing and then quickly proceed to not recreating it. If there was market for this, it would exist. I've never used Hyper Card, but I guess that for prototyping of 'real software', programs like InVision work. Most of the trivial programs you could create with HyperCard (from the examples shown) can be recreated in other software (like excel or soulver) or already exist.
burlesona 6y ago
I learned how to build web pages by hand writing HTML and copy pasting it into Geocities when I was 9. It wasn’t real programming then and it isn’t now. Don’t mistake the explosion of JavaScript land for being the same thing as the World Wide Web. Static websites are as easy to build now as they were in 1995, and in some ways easier.

mumblemumble 6y ago

I think that TFA said it well, if brusquely: > And if you think that XCode, Python, Processing, or the shit soup of HTML/Javascript/CSS are any kind of substitute for HyperCard, then read this post again. The thing that made HyperCard great was that it wasn't very capable. Which made it approachable.

mpweiher 6y ago
Sure, Xcode today isn't a substitute. But Xcode is a large step back from what NeXTstep had, at least when it comes to this kind of capability. The standalone Interface Builder had palettes, which you could fill with custom objects. There were third party palettes that allowed non-programmers to click together and configure custom applications for specific domains. There were palettes that extended the whole shebang with scripting languages so that you could also add custom logic in Interface Builder.
- debo_ 6y ago
  I hope that "extended the whole shebang with scripting languages..." was an intentional pun.
- spacedcowboy 6y ago
  That's no different to Xcode. You just need to decorate properties for simple things, and maybe write a setup method or two if you want live-updates (eg to pull a weather map from a server)... Google @IBInspectable and @IBDesignable. Unless you're saying that the most recent versions of Xcode don't do that, which would be news to me. I agree that it's not well-used, but that's not the fault of Xcode. As far as I can tell it provides everything you'd need.
  - mpweiher 6y ago
    I am familiar with IBInspectable and IBDesignable, and have, for example, put my own Smalltalk and Postscript implementations in IB that way. Not the same thing. At all. Not even close. Palettes were final-packaged components that were at the same level as pre-built ones. IBDesignable is a way for adding some interactivity to the views you are creating for an app while you're building said app. Like SwiftUI Previews. And it works about as well, that is not really at all. With IBDesignable, Xcode was continually trying to build the entire dependency tree, meaning for example the entire Postscript interpreter. And failing >50% of the time, which then kills your view. I hear the same happens with SwiftUI previews once your project gets bigger. It certainly happened to me almost immediately when I was trying it out. Again, they're not even close.

seumars 6y ago

>not initially as elegantly or powerfully i wouldn't call the web elegent or powerful today either