Live data from Hacker News

Why Hypercard Had to Die

loper-os.org

141–142 of 142 posts

Re: Why Hypercard Had to Die

#141
post #134

Earlier quoted context omitted.

I had the same reaction of "no market" from the article, but on reflection I suggest turn it around: instead of thinking of it as "a programming environment", think of it as a specific application first, which has customization added to it, and eventually becomes programmable. Seeing it this way, such environments are very common - they are just not presented as "programming environments". And that may be what is dif…

If you look at it as purely customization, yes, there's a thriving market. But the author is specifically looking for something that creates a world 'where the distinction between the “use” and “programming” of a computer has been weakened'. And the point is that those are fundamentally different activities. There's only a very small intersection that needs the simplicity of "use" and the complexity of "programming".…

aka "operation" vs "design". I agree, for targeting that explicitly as a pedagogical or philosophical end in itself. A cool ideal, btw (though I think it works better with less powerful programming - more concrete, perhaps only regular or context free not turing complete).

In real (non-coding) life, there's usually overlap, of "adjustments". e.g. you're cutting tomatoes with a knife, and adjust the knife's angle, or your grip, or move the tomato, spin it on a vertical axis, rotate it, try sawing vs slicing, maybe change knives, etc. Perhaps you exclaim "This is the best knife for tomatoes!" and resolve to use only it henceforth. But many of these adjustments are unconscious, and part of everything we do. Is it "operation" or "design"? I think it's fuzzy in practice; we often chip away at things as we learn and adapt.

True, in software, there's usually a sharp line between user (operating) and programmer (designing). Customization crosses that line: macros, templates - even, hiding menus you don't use. Is hiding a menu "programming"? While not turing complete, it's a step closer to it.

I agree there's not much market for the combination, in itself. Programming is so accessible these days, if you want to do it, you just do it. Probably starting with HTML "programming", then Javascript or PHP. It even looks like a real website! It's like hypercard, but global.

Re: Why Hypercard Had to Die

#142

Earlier quoted context omitted.

> They either want a full system, or just a product. While I think this is true at the moment, it seems that there is an interesting question behind that, as well. Why don't more people want to create their own software? I do think the author has an implicit point: because, frankly, creating software stinks. Jon Skeet's talk [1] demonstrates this admirably. I spend a shockingly large part of my time working around bu…

Hm. I've never seen a HyperCard project that was both maintainable and of a large-ish size. I think _that_ is where the HyperCard idea broke down - navigating through a bunch of cards is significantly more difficult than through a bunch of text files. Granted, that _may_ be a question of the tools. But I do find it telling that in the long time since the "death" of HyperCard nobody could come up with compelling tools…

I definitely agree that software desire requires analytical thinking. (It certainly put a halt in my thoughts about a mass-appeal software builder: if they don't "get" [or want to get, or whatever] Excel, they don't have a chance for much else.)

I do think, though, that not being able to make projects of large-ish size isn't necessarily important for a wide variety of use cases. Most of the best apps I know of do only a very small thing—but do it very well. I think HyperCard allow people to do small things exactly the way they wanted. Which maybe wasn't very well, but was good enough for their needs and better than the alternatives.

As I mentioned in my other comment [1], I wonder if the parallel is somewhat like the UNIX command line. You probably aren't going to write a MySQL competitor in bash. But there are a whole class of small custom tools that you will write.

To perhaps restate my original point (and this is where perhaps we agree), the abstractions of HyperCard eventually didn't (couldn't?) adapt. Perhaps, as you said, because of cards. As someone else commented, also partially because of the codebase, but also, I think, because things like color and networking and a greater number of standard UI widgets all had to be added.

[1] http://news.ycombinator.com/item?id=3294915

Post reply on HN