Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Hypercard Had to Die

loper-os.org

Post reply on HN
Print view View original

71–80 of 142 posts

Re: Why Hypercard Had to Die

#71

Post by arethuza »

david927 wrote: post #63
jrmg wrote: post #58

I think much more likely explanations than the nefarious anti-creative one given for HyperCard's death are that, to varying degrees: Steve found all HyperCard stacks he saw to be messy and confusing, not at all the functional simplicity he was looking for; HyperCard was taking engineering resources and/or money that could be better spent saving the Mac, and therefore Apple. Apple has not, in recent years, on the Mac,…

Simple programming environments have a fundamental flaw: they fool you. Let's say we have a type of perforated balsa wood that you can just snap into pieces and glue in place. Making a dog house just went from hours to minutes! Hurrah! So you start telling everyone that this is the new way to construct buildings, but then as you get bigger structures, it starts to fall apart. Simple programming environments fool you…

"Simple programming environments fool you into thinking you into thinking your projects can scale, and the result is a mess."

Doesn't seem to have stopped Excel in particular, and spreadsheets in general, from being wildly succesful.

Re: Why Hypercard Had to Die

#72

Post by 6ren »

praptak wrote: post #59
6ren wrote: post #55

Earlier quoted context omitted.

Spreadsheets are arguably a "trivialized programming environment".

Which (sort of) supports GP's argument. We have programming environments on one end, full products on another and spreadsheets (maybe also MS Access) in the middle. The environment looks crowded. Btw, I'd love spreadsheets-as-apps replaced with something more maintainable but they also have a huge advantage: you can start using a spreadsheet with zero programming. Unless you copy that, you can't compete for that nich…

If we have room at the ends (for new programming environments, and new products), why can't we have room in the middle?

Something else with zero programming is online form builders; some already have constraints and reporting systems. If they added simple programming constructs, it could be as powerful as you like. (e.g. google forms enables you to skip to different questions based on previous answers, though it's getting away from easy visualization, unlike spreadsheets). You can view them as being a database, derived from input forms - what's stopping them growing towards unmaintainable real databases, in the way that spreadsheets can grow into unmaintainable apps?

A way to think about this is not in terms of a complex thing, but in terms of a simple thing... a toy... to which you can add-on complexity. e.g. I'm not sure that the first spreadsheets were fully programmable, but just related different cells by formula. And I know for sure that the first RDBs didn't have stored procedures.

Maybe, this could be done for many webapps: wiki + scripts; reddit + scripts (what would that be?); youtube + scripts (we have it a little bit with links on parts of the video). The puzzle is imagining what could possibly be the use of these... it helps if you already have a manual version that you are automatic (that's what the visicalc guys did: "spreadsheets" existed, on paper, before them: http://inventors.about.com/library/weekly/aa010199.htm).

There's visual webapps for assembling webservices, but they don't seem to have taken off. Maybe the "problem" is that they scale - the thing you create is good for more than just one person, unlike most spreadsheet documents, which (excluding templates) contains your own specific data - often, proprietary business data. Because it can scale, people invest more effort in it, and are happy to use proper APIs etc. And then, consumers don't have an unsatisfied need, because it's already done. Therefore, perhaps the "toy" needs to be about a particular business or person (e.g. be about their data).

Also: Arguably, Flash authoring tools took the place of hypercard.

Re: Why Hypercard Had to Die

#73

Post by arethuza »

asciilifeform wrote: post #14
jawngee wrote: post #11

Umm, SuperCard still exists and is under active development. Even back in the day it was superior to HyperCard in every way. My guess was that HyperCard was killed because the WWW was coming. I used SuperCard pretty heavily back in '92ish at the second college in Minnesota to get the internet (MCAD - U of M was first). I remember the rows of NeXT boxes they had, the only machines connected and I remember fumbling aro…

> the WWW was coming. In 1998? > it's spirit certainly lived on in Visual Basic, Borland Delphi, Macromedia Director and a bunch of other things. I have used all of these, and beg to differ. The spirit of HyperCard was that of radical simplicity , and it does not live in these systems.

Viola was publicly available in '92, when Mosaic came along in early '93 it was pretty clear to people working in the field that although what the Web did was a lot more limited than other hypertext tools the network effect made it infinitely more powerful.

Re: Why Hypercard Had to Die

#74

Post by jodrellblank »

makecheck wrote: post #2

Actually has a really good example (a calculator) to show how HyperCard could be used. HyperCard was a big part of my junior high years. It could even be extended, e.g. there was one add-on that allowed color graphics to be displayed and I learned to make some simple games that way.

But its not a good example.

You're sitting at a device with a numeric keypad, and a 9" screen; Replicating the calculator interface in clickable buttons, with a textbox as simulated LCD is a horrible misuse of the potential of a computing environment.

A screen, a keyboard and a hardware ALU. Being used to run an OS which draws some keys and a screen, interprets mouse movements, parses and interprets Applescript and parses text arithmetic operations, so it can pretend to be some keys and a screen connected to a hardware ALU.

And this is hailed by our "anti-bloat" author as a great example of simplicity which normal people love, and its limits are fine, compared to any other system - e.g. Visual Basic 3 - which is needlessly complex.

It's almost funny, until you read his seven tenets of computing and find that any program which encounters any error should enter a debugger, so you can fix it and carry on. I think that would drive anyone insane.

Re: Why Hypercard Had to Die

#75

Post by praptak »

6ren wrote: post #72
praptak wrote: post #59

Earlier quoted context omitted.

Which (sort of) supports GP's argument. We have programming environments on one end, full products on another and spreadsheets (maybe also MS Access) in the middle. The environment looks crowded. Btw, I'd love spreadsheets-as-apps replaced with something more maintainable but they also have a huge advantage: you can start using a spreadsheet with zero programming. Unless you copy that, you can't compete for that nich…

If we have room at the ends (for new programming environments, and new products), why can't we have room in the middle? Something else with zero programming is online form builders; some already have constraints and reporting systems. If they added simple programming constructs, it could be as powerful as you like. (e.g. google forms enables you to skip to different questions based on previous answers, though it's ge…

I think we agree - my point was not that there is no room in the middle but that if you want to go there you need to give some zero-programming benefits for starters.

And yes, forms are an example of what this benefit might be.

Re: Why Hypercard Had to Die

#76

Post by tree_of_item »

david927 wrote: post #63
jrmg wrote: post #58

I think much more likely explanations than the nefarious anti-creative one given for HyperCard's death are that, to varying degrees: Steve found all HyperCard stacks he saw to be messy and confusing, not at all the functional simplicity he was looking for; HyperCard was taking engineering resources and/or money that could be better spent saving the Mac, and therefore Apple. Apple has not, in recent years, on the Mac,…

Simple programming environments have a fundamental flaw: they fool you. Let's say we have a type of perforated balsa wood that you can just snap into pieces and glue in place. Making a dog house just went from hours to minutes! Hurrah! So you start telling everyone that this is the new way to construct buildings, but then as you get bigger structures, it starts to fall apart. Simple programming environments fool you…

And why does it need to be "deep"?

It's good that it died because it doesn't "scale" to the elephantine size of software you're accustomed to?

Re: Why Hypercard Had to Die

#77

Post by loup-vaillant »

jodrellblank wrote: post #64
asciilifeform wrote: post #38

Earlier quoted context omitted.

So doing "it" right is a physical impossibility, then? Care to say why?

Because 'right' is in the eye of the beholder? It's subjective.

We agree much more on what's "right" than you suggest.

Take two systems which do the same things. One does it as expected, the other surprises you in subtle ways. One does it as specified, the other sometimes does not. One does it quickly, the other makes you wait a bit. One fits in a few pages of code, the other takes a whole book.

I agree that you can't tell what's right in advance. But it's not a matter of preference, it's a matter of ignorance. In hindsight, when you see the results, you can most of the time point out what could have produced better results, if only you knew. You can even go meta, wondering why you didn't knew, then try and change that in the future.

Re: Why Hypercard Had to Die

#78

Post by Luyt »

asciilifeform wrote: post #28
ricardobeat wrote: post #20

He's kind of pissed off. I see nothing special with it except for the "natural" language.

The "natural" language is actually the weakest part.

Because it really isn't natural at all, it only looks natural. AppleScript is a kind of COBOL. You have to know exactly what (natural-sounding) keywords and clauses you can use. Try some real natural language and the interpreter is suddenly lost.

Re: Why Hypercard Had to Die

#79

Post by nicpottier »

The thing I've always felt held back these paradigms is something that is inherent in them, they are too visual.

That sounds crazy, but just look at this article and how he described what he did. He had to take a million screenshots to show it. The same is true for say, the Android app builder, or the Lego logic thing.. the way you sure code is via a screenshot.

And that just doesn't scale very well I don't think. It makes copy/pasting, the most basic way that people learn, really difficult.

HTML5 is pretty awesome, or rather WOULD be pretty awesome if we could erase the last 15 years and all start with CSS3 compliant browsers. But it is such a mess now that I feel bad for anybody starting from scratch.

But the combination of HTML for layout and Javascript for layout is pretty darn powerful, and I think pretty accessible as well. You could certainly build something on the order of the simplicity of Hypercard on that stack.

But I do like the author's comments about the shame that there are far fewer 'programmers' than back in the old days. BASIC on the AppleII is of course the other example (among others).. where it was just so easy and almost natural for ANY user to start getting a feel for things and hacking around. Losing that really IS a shame.

Re: Why Hypercard Had to Die

#80

Post by david927 »

arethuza wrote: post #71
david927 wrote: post #63

Earlier quoted context omitted.

Simple programming environments have a fundamental flaw: they fool you. Let's say we have a type of perforated balsa wood that you can just snap into pieces and glue in place. Making a dog house just went from hours to minutes! Hurrah! So you start telling everyone that this is the new way to construct buildings, but then as you get bigger structures, it starts to fall apart. Simple programming environments fool you…

"Simple programming environments fool you into thinking you into thinking your projects can scale, and the result is a mess." Doesn't seem to have stopped Excel in particular, and spreadsheets in general, from being wildly succesful.

Very good point. I think spreadsheets are just deep enough and map well enough to the domains that use them, that it can tread water. (Not swim, mind you.) They're also quite clear about their constraints.
Post reply on HN