[HN Gopher] Douglas Adams on Hypercard and new educational models
___________________________________________________________________
Douglas Adams on Hypercard and new educational models
Author : arbesman
Score : 131 points
Date : 2023-01-10 13:01 UTC (9 hours ago)
(HTM) web link (arbesman.substack.com)
(TXT) w3m dump (arbesman.substack.com)
| airstrike wrote:
| > But Adams makes a powerful point: the general-purpose nature--
| as well as composability--of a piece of software is just as
| important as its low floors and its approachability.
|
| This is an interesting take. From this perspective, I suppose
| Unix got composability right but its approachability to the
| average person is nearly zero.
|
| In some way "pure" functional programming often feels the same
| way to me. Extremely composable but am I willing to trade
| approachability for that? And on second thought maybe that's true
| of "pure OO" languages too...
|
| Maybe people feel the same way about hardcore text editors like
| vim or emacs?
|
| The list goes on... I think I read somewhere that innovation is
| defined as the solution to a trade-off, and this particular
| battle between approachability and composability seems like a
| particularly fruitful avenue to explore if looking for "modern
| problems to solve"
| bobajeff wrote:
| I'd guess the Node.js and npm got composability w/
| approachability formula the most correct. Rust comes close but
| using rust libraries is where approachability falls apart fast.
|
| As for editors. Right now vscode get that formula the most
| correct.
|
| As for Unix what do we have to compare it too? Everything more
| or less is a Unix these days. So it couldn't have got
| approachability that wrong.
| SQueeeeeL wrote:
| I think the issue with npm is that it makes what should be a
| relatively important task (adding huge swathes of mostly
| unknown code) trivial to do, leading to all the bloat and
| abuse that ecosystem has seen. Sometimes a bit of friction
| that forces the user to slow down and truly understand what
| they're doing is a good thing...
| shadowgovt wrote:
| The vulnerable part of the npm ecosystem is trust and end-
| user high-granularity control of trust.
|
| If that problem can be solved, there's nothing inherently
| problematic with just using large swathes of mostly unknown
| code. Almost no Debian user knows the innards of every
| package they've installed, even the dev libraries they're
| building new applications on top of (to say nothing of
| every Ubuntu user).
|
| (TBF to the ecosystem, there actually is a mechanism for
| flagging security issues in old library versions and
| surfacing those to a package builder. But it is up to the
| package builder to account for them by changing their
| dependencies).
| __MatrixMan__ wrote:
| I agree. To be more specific I think the problem with npm
| is that it explicitly trusts names and implicitly trusts
| their referents, which puts too heavy a burden on the
| name resolver.
|
| Contrast this with apt, which inspects package signatures
| and compares them to keys I've trusted. If a package
| shows up with the same name as before, but different
| bits, and it's signed by somebody new, I have a reason to
| scrutinize it more heavily.
| shadowgovt wrote:
| Npm does one thing particularly clever that a lot of other
| library / dependency infrastructures fail at: it supports
| multiple versions of the same library living in the codebase.
|
| Because npm treats package dependencies recursively, a
| package depending on v1 of another package and a package
| depending on v2 of that package can actually live in the same
| codebase (with proper configuration; it comes as kind of a
| side-effect of transpilation and tree-shaking requiring the
| toolchain to rename symbols anyway, so the two different
| versions of the library just end up either properly hidden
| via module inclusion or in the same codebase but name-mangled
| to different things). This isn't foolproof (if one of those
| libraries leaks details of its dependency, and another piece
| of code tries to do `instanceof`, it's going to have a bad
| time), but it makes it easier to work with codebases one
| doesn't control.
| fathyb wrote:
| Wondering what more approachable looks like in this case? A GUI
| embracing Unix metaphors?
| mcguire wrote:
| You're giving me SMIT flashbacks here. :-)
| clem wrote:
| "It's a UNIX system! I know this! It shows you what to do!"
| mcguire wrote:
| "* From this perspective, I suppose Unix got composability
| right but its approachability to the average person is nearly
| zero.*"
|
| I strongly agree with the first part of the sentence, but I
| disagree with the second. Considering the users that the Unix
| developers had in mind at the time---the late 1970s to late
| 1980s, say---its approachability was significantly better than
| the alternatives. (DCL, anyone?)
|
| It wasn't until Unix expanded outside that niche that people
| began having bad reactions to it. :-)
| shadowgovt wrote:
| Of course, now that it has expanded, and it's currently 2023
| not 1970, the approachability to the average person is nearly
| zero.
| ChrisMarshallNY wrote:
| DA was an official, certified Apple developer. They even had him
| keynote an early WWDC (as well as Harry Anderson).
|
| I always liked his take on Windows 95:
| https://www.info.ucl.ac.be/~pvr/os_hype.html
| iNerdier wrote:
| Reading this just makes me wonder if he ever (and surely he
| must have) used an Amiga. Why so bullish on the Macintosh with
| all its specific weirdness when, even as good as Apple was at
| the start did he not see the other more interesting forks in
| the '80s as worth it?
| zoenolan wrote:
| He also presented the documentary Hyperland for the BBC
|
| https://youtu.be/1iAJPoc23-M
| kristopolous wrote:
| Looking for someone to post this. The outro after 46:30 is
| reminiscent of mondo 2000 and verbum magazine.
| michaericalribo wrote:
| Apparently his Mac was like an extension to Adams' brain, and all
| of his work was stored on it. It might make it more brittle to
| changing technology, but on the other hand it was hugely
| productive for him.
| dylan604 wrote:
| The fact that Adams was the first European Mac owner and that
| Stephen Fry was the second warms my heart. If that was the only
| thing I remember from this article (very high probability), my
| day was still better from reading it.
| GlenTheMachine wrote:
| It seems to me that something like this is really what the iPad
| is missing. Instead of each application being in its own sandbox,
| imagine if they were all scriptable, and the scripting language
| was as accessible as HyperCard was.
|
| That would really be something.
| mortenjorck wrote:
| The shortcuts app is a tantalizing glimpse of what could be.
| Directionally, it was a sea change for iOS when Apple acquired
| it and subsequently introduced its first-party iteration. But
| imagine the potential of Shortcuts if it were evolved into a
| fully-realized HyperCard successor.
| CharlesW wrote:
| BTW, for anyone into iOS and macOS automation, Jason Snell's
| use of Shortcuts is really interesting to read about:
| https://sixcolors.com/tag/automation/
|
| > _I had assumed that Apple would provide a way for Shortcuts
| to encode media into Apple Lossless format, but it doesn't.
| The Encode Media action can encode audio, but only to M4A or
| AIF formats. Instead, I retreated to the command-line, since
| Apple provides a utility called_ afconvert _that will let you
| convert audio files between an enormous number of formats,
| including not just Apple Lossless but the even more widely
| supported (and slightly more efficient) FLAC._
| https://sixcolors.com/post/2022/11/automate-this-audio-
| archi...
| fit2rule wrote:
| [dead]
| cc101 wrote:
| I believe that the iPad can run HyperCard inside the Basilisk
| II mac emulator. I just scanned this. Didn't read it.
| https://www.emaculation.com/forum/viewtopic.php?t=11149
| soapdog wrote:
| AppleScript was just like that.
| 8ytecoder wrote:
| I've been using Shortcuts pretty extensively. There are
| challenges of course. But for the most part, it's great. Most
| good apps expose their actions. The usual culprits like
| Outlook lock it down based on corporate policy. You can even
| make bespoke API calls. Siri is much more usable for me
| because of this.
|
| There are major glaring issues - like the rigidness of the
| Timer and the lack of a separate "sleep" timer. No option to
| pause the shortcut for an extended period of time. And the
| all too familiar Apple bugs these days. In spite of all this
| it's definitely one of the exciting things Apple has released
| - especially after they made it portable between the phone,
| watch, iPad, mac and HomePod - albeit limited.
| shadowgovt wrote:
| On the user side, AppleScript was great.
|
| On the side of developers writing apps to support
| AppleScript, it was a nightmare because the language was too
| flexible. I remember having to build parse trees to handle my
| DirectObjects and the various other English-language-
| sentence-diagram portions of an AppleEvent.
| jfk13 wrote:
| I don't think AppleScript achieved anything like the
| approachability, discoverability, and delight of HyperCard.
| It wanted to appear similar, but was constantly stumbling
| over the wildly varying levels (and quality) of support found
| in different parts of the ecosystem.
| analog31 wrote:
| A crippling problem was that there were only a tiny handful
| of scriptable apps.
| mcguire wrote:
| " _It was an incredibly open-ended piece of software, allowing
| those without much expertise in programming (or even any at all)
| to build a wide variety of computational tools. To borrow a
| formulation from Seymour Papert (who co-created the programming
| language Logo), HyperCard had low floors and high ceilings._ "
|
| Speaking as someone who used HyperCard to create a couple of
| applications, this is...somewhat overstated. It was quite good at
| creating things that resembled flipping through a deck of cards.
| (One app was a "smart test" that would present a more-or-less
| difficult question based on the user's previous answers---my
| first introduction to Bayesian statistics.)
|
| It was, however, not a good programming environment if you needed
| to do anything complex---think of writing a complicated Emacs
| major mode, not using Emacs lisp but a simplified textual
| language intended for those without much expertise.
|
| This is a general problem for systems built for "those without
| much expertise in programming (or even any at all)"; they may be
| able to do simple things, but you'll still need to be a "real
| programmer" to do slightly more complicated things, and a "real
| programmer" will be doing it with one hand tied behind their
| back.
| disparate_dan wrote:
| While I never used HyperCard, the 'low floors and high
| ceilings' makes me think of spreadsheets. Given that I code all
| day professionally, I have quite a high bar for using code to
| solve personal needs, but I love to use spreadsheets - there's
| just enough automation to make powerful, useful mini-
| applications, quickly, without much complexity, and the
| presentation capabilities are very strong. While there is
| brittleness - I can share a budget sheet with my wife and it
| will be broken in minutes - it's easy to fix and evolve, but
| most importantly, they are accessible and grokable for someone
| without much technical knowledge.
|
| I guess spreadsheet apps are pretty self-contained so I'm not
| sure that composability is a strength.
| rchaud wrote:
| > think of writing a complicated Emacs major mode, not using
| Emacs lisp but a simplified textual language intended for those
| without much expertise.
|
| That's good enough to build form-based apps with basic
| conditional logic, which was Hypercard's biggest use case.
|
| A person can sit through a Hypercard tutorial and learn how to
| build a small app using forms. That same person will have a
| much harder time rebuilding that app in PHP or Xamarin.
| madrox wrote:
| As someone who also used Hypercard, I tend to agree. There's a
| reason we aren't still talking about Hypercard today the way it
| was talked about then, but it was a different time. We were so
| much more enamored with software's potential. Today, we get
| upset if a button press takes five seconds instead of one.
| apricot wrote:
| As someone who tried to use HyperCard and, after much lost
| time, went back to more traditional programming tools, I agree
| with your assessment. The idea behind HyperCard was neat, but
| HyperCard itself made it easy to write simple programs with
| lots of cute window dressing, and impossible to write complex
| ones.
| RodgerTheGreat wrote:
| I'm rather biased, but I think HyperTalk was mostly a mistake.
| A well-written HyperTalk script can be clear for a novice to
| read and (hopefully) modify, but this comes at the cost of
| making it an intensely longwinded, fiddly, and ambiguous
| language to program with and to implement. The focus on text
| manipulation as the primary "data handling" paradigm is very
| convenient for some problems, but the lack of proper lists and
| associative structures is a liability for complex programs.
|
| Nevertheless, HyperCard on the whole was still enough to be
| highly empowering to a very broad userbase, which cannot be
| understated. It is difficult to quantify the amount of
| productivity and enjoyment that can be given to users simply by
| allowing them to make minor changes to personal software
| themselves, even if the bulk of the work was done by some "real
| programmer".
| detrites wrote:
| Strange article. It's an interesting and well-written piece
| relating what DNA wrote about Hypercard (and what Hypercard is),
| before suddenly switching to "educational models" without
| explanation, and then abruptly ending.
| wodow wrote:
| I believe the main article ends at the "Share" button, then
| there's a separate ad or section about the educational models.
| detrites wrote:
| Haven't seen that format before. Substack ordinarily scatters
| various buttons/images/signups etc through an article so I'm
| accustomed to skipping over them to get to the next
| paragraph.
|
| The subtitle of the article specifically mentions Educational
| Models, creating an expectation they will be covered as part
| of the subject matter. But then it's tacked on without any
| context or reason. Total non-sequitur.
| atebyagrue wrote:
| Never played with the format back in the day, but while
| researching it a while back, I found that archive.org hosts some
| of the older ones & you can play with them online:
| https://archive.org/details/BeyondCyberpunkMacintosh
| rcarmo wrote:
| I miss Douglas. I wonder what he would write about today's
| Internet.
| nix23 wrote:
| The Bird-ride of Rocketman a discworld novel
| readthenotes1 wrote:
| Great fun:
| https://en.m.wikipedia.org/wiki/Cosmic_Osmo_and_the_Worlds_B...
| alexwasserman wrote:
| And interestingly, given that's a Cyan game, their more famous
| title, Myst, was also just HyperCard stacks behind the scenes,
| with each world being it's own deck.
| rcarmo wrote:
| Oh boy. I had that on the IIfx I used in college.
| donatj wrote:
| The seeming death of software that _empowers_ users never ceases
| to make me sad. We have this machine of near limitless power and
| endless possibilities, and yet we do everything in our power to
| make doing things yourself esoteric. You have to pay someone to
| develop simple things you should absolutely be able to do
| yourself.
|
| When I was a pre-teen my computer booted up to BASIC. I taught
| largely by guessing commands. I created many simple graphical
| games drawing lines and circles. SCREEN 12
| LINE 0 0 640 480 5
|
| Imagine being a pre-teen today and just trying to draw a line to
| the screen. Several hundred lines of boilerplate. We've lost more
| than we've gained.
| yamtaddle wrote:
| <!DOCTYPE html><hr />
| zerocrates wrote:
| Lose the unnecessary self-close and you're _really_
| efficient.
| [deleted]
___________________________________________________________________
(page generated 2023-01-10 23:00 UTC)