Hacker News Reader

Comment by ridiculous_fish | Hacker News Reader

Hypercard remains extraordinary. It anticipated the web, but have a taste of its scripting language:

    if the number of chars in field "Customer Code" is not 7 then
      ask "Please type in the 7-letter customer code"
      put it into field "Customer Code"
    end if

This is a real language! 'ask' pops up a modal dialog. 'it' is a special identifier meaning "the last result", like Perl's context variables.

But what is most lovely about this language is that it focused on users. As a user you could drag out a button, then double click and write some Hypertalk scripting. It was part of a vision where computing would empower amateurs to become desktop publishers or artists or programmers or...

The web captured that magic for a time, when it was about HTML with light JS. But the modern web has advanced beyond the amateur.

View on HN

What people who weren't there don't understand is this was the 80's, long before any alternatives were even a vague thought, before the web existed, when programmers had only a few choices and none of them were something ordinary people could use (other than Basic which had no real UI). I used Hypercard to design UI (back before UI was a specialist thing) and it was magical. It's easy to criticize it today but that's like complaining about how terrible computers were in the 1940's. It's not just the language, it's the whole package that was amazing for its time. Ever use a website builder today? Most of them suck terribly for anything complex, yet follow almost the same paradigm as Hypercard did 3 decades ago when there was Hypercard and basically nothing else to base its concepts on.

I wouldn't criticize it at all, but I would rather appreciate the power of being able to get so much functionality with such little input from the person writing the stack. It is amazing and the web is in many ways several giant steps back from that.

Or the early web was more like that. People throwing up "hobbyist" web pages. "Here is shit I am into ... and here's a rocket made from a 5 gallon water bottle and liquid nitrogen."

The modern web hasn't really advanced beyond the amateur, but the quality of the underlying tools and languages (css, javascript) is absolutely horrible.

If this crap had had to compete with anything else in the marketplace it would have never flown. It is so bug prone and user unfriendly that it is hard to describe. We will also likely never get rid of it.

Just a few samples:

https://javascriptwtf.com/

As for CSS, if the goal was to create a pixel perfect way to lay out webpages it may have succeeded, but the whole idea of an information web where rendering was supposed to be the problem of the consumer went out the window.

I understand that type can get weird in a loosely typed language but, personally, I find modern ECMA/Typescript to be lovely languages to work with.

CSS also got a huge bump for me when everyone started consistently supporting flexbox.

But hey - it's super easy to hate on web languages/markup/stylesheets while linking to JS quirks so here we are.

> If this crap had had to compete with anything else in the marketplace it would have never flown.

It competes every day.

The morass of terrible tooling is explained by the reason that so many other nice-to-have resolutions to common problems don't materialize: even though things suck, improving them is a problem for someone else to solve. Anyone who complains about the state of things (or doesn't) and then proceeds to do things the broken way is contributing to the problem.

The JS example is overstated. People who are slinging code around with a nary a care for what types the objects have deserve everything they get; if you end up in a situation where x can be either a string or a number or a list and you're somehow freely making comparisons between them, then the problem is on your end, and it's way further up the pipeline than where the equality comparison token appears.

FWIW, HyperTalk wouldn't have fared any better[1]:

> Data types usually did not need to be specified by the programmer; conversion happened transparently in the background between strings and numbers.

Note that this is not a defense of mainstream professional web development. I probably abhor it more than you do. But the problems need to be connected to their source and not misattributed to a popular punching bag just because it's easy to score points that way.

1. https://en.wikipedia.org/wiki/HyperTalk

What sucks about these languages is complex sentences that look like loose English but are actually formal syntax. “.length” is so much easier to understand and remember as a formal sentence than “the number of chars in”.

It would be a good language for a very active IDE which constantly showed you how the sentence-so-far had been parsed, so you wouldn't need to guess as much about the grammar. SQL could definitely use something like that, too.

> It would be a good language for a very active IDE which constantly showed you how the sentence-so-far had been parsed.

I love this idea. Combined with a language like Hypertalk, a new user could foreseeable just figure out the syntax without looking it up.

Maybe for you. The goal of Hypercard was to empower people that don't really think '.length' is easier.

And it has been demonstrably shown that languages that have a pseudo English syntax do nothing to open programming to the masses; case in point being Cobol, there is a proverbial tonne of it being maintained only by software engineers.

"pseudo English syntax do nothing to open programming to the masses"

But they did with hypercard, right? I remember my sister showing me a hypercard presentation she did while she was in primary school.

Wait—that's really cool! Did she just go ahead and learn it on her own?

> case in point being Cobol, there is a proverbial tonne of it being maintained only by software engineers

I don't think COBOL is a good comparator. Although COBOL uses 'English' words, it has massively idiosyncratic programme structure (data division! [0]) and weird data structures (PICTURE clause! [1]), and it was these that made it hard to understand and maintain without a very steep learning curve.

Source: I had a language trajectory that went Pascal -> COBOL -> C -> Hypercard. I was stunned by how rapidly I could create impressive Hypercard applications, with quite sophisticated (for the time) UI and graphics. This was invaluable in the group I worked in, a research group in a large UK engineering company in the early '90s.

[0] https://en.wikipedia.org/wiki/COBOL#Data_division

[1] https://en.wikipedia.org/wiki/COBOL#PICTURE_clause

"I don't think COBOL is a good comparator."

Another similar language is Inform 7, the text adventure authoring language, which came out in 2006, about 20 years after Hypercard.[1]

Below is a simple example program in the language. A more involved example can be found here: [2]

  "Hello Deductible" by "I.F. Author"
  
  The story headline is "An Interactive Example".
  
  The Living Room is a room. "A comfortably furnished living room."
  The Kitchen is north of the Living Room.
  The Front Door is south of the Living Room.
  The Front Door is a door. The Front Door is closed and locked.
  
  The insurance salesman is a man in the Living Room. The description is "An insurance salesman in a tacky polyester suit. He seems eager to speak to you." Understand "man" as the insurance salesman.
  
  A briefcase is carried by the insurance salesman. The description is "A slightly worn, black briefcase."  Understand "case" as the briefcase.
  
  The insurance paperwork is in the briefcase. The description is "Page after page of small legalese." Understand "papers" or "documents" or "forms" as the paperwork.
  
  Instead of listening to the insurance salesman:
      say "The salesman bores you with a discussion of life insurance policies. From his briefcase he pulls some paperwork which he hands to you.";
      move the insurance paperwork to the player.

[1] - https://en.wikipedia.org/wiki/Inform_7

[2] - http://inform7.com/book/RB_1_3.html#e74

This is a common misunderstanding coming from people whose first language is English.

There is a wider world where they prefer ".length" over some english sentence. Even the ".length" is difficult for them but it's still less grammar to learn.

pre-OS X versions of Applescript (which was largely based on Hypertalk) actually allowed you to use Spanish/French etc in addition to English. Was taken out in OS X apparently.

HyperTalk existed before unicode, however it's conceivable that a modern implementation would return... the number of actual characters in a string.

For contrast, JaveScript's .length definitely does not count the number of characters, it returns the count of UTF-16 units, which for Emojis yields an incorrect result.

My point being that the conveniences we all enjoy with `.length` come with subtle gotchas that we overcome as devs but are perhaps not necessarily as user-friendly as a more long-winded approach.

For what it's worth, Rust's string length tells you the number of conventional characters, whilst following typical programming notation rules.

Rust's .len() on string does not give you the length in characters, it gives you the length in bytes. If you want the length in unicode codepoints, you need to do .chars().count(), but given things like combining characters, that might not be quite what you want either.

No, it’s not much easier. You simply got used to it and forgot the time it took you to learn it.

No, it’s just a question of what you’re used to.

HyperTalk was the second programming language I learned (after BASIC) and I had no trouble remembering the grammar. It probably helped that I didn’t have too many preconceptions to unlearn.

One big thing in HyperTalk’s favor that rarely gets mentioned is that it pretty-printed your code automatically. That was a massive help, and well ahead of its time.

> What sucks about these languages is complex sentences that look like loose English but are actually formal syntax.

I really like this though!

It's true, you can't just write English sentences and expect the computer to understand you—you have to learn the "formal syntax". But, once you've written that code, it comes out as English sentences, so you can read what your code is doing in English!

I love this. I've never used Hypercard (too young), but I do use Applescript, which was based on Hypertalk's syntax and which—sometimes, when Applescript isn't being crappy—has the same property.

If there are other modern languages that do this effectively and can be used for more than just macOS automation, I'd love to know about them...

Apple's SK8 was intended to be the original successor to HyperCard and led to AppleScript. It's available under some quasi-open source license.

https://en.wikipedia.org/wiki/SK8

https://github.com/waywardmonkeys/apple_sk8

Having run non-trivial programs in Applescript I want to say that its an absolutely nightmare to debug - reading english sentences describing program operations is not understanding intent at all, its just sooooo verbose.

Applescript is annoying for reasons that I don't think have to do with being English-like. The type system is obtuse and exceedingly difficult to follow, and a lot of the more advanced syntax doesn't actually read much like English.

(Personally, I do still happen to like Applescript, but it has a lot of problems.)

'Wowfunhappy, I strongly suggest you take a look at the Inform 7 programming language:

http://inform7.com/

It is powerful, stable, and addresses many of the issues of using an English-like syntax. It comes with an IDE and two hyperlinked manuals, which contain hundreds of working code samples implementing everything from basic conversations to systems of weights and measures. Finally, as one of the pillars of the modern interactive fiction<1> development community, it is under active development by its creator, in the saddle for twenty-plus years now.

Here's a sample (syntax may be slightly wrong):

A person can be nervous or relaxed. A person is usually relaxed.

The Train Station is a room. Joe is a man in the Train Station. Joe is nervous. "Joe shifts from foot to foot, looking uncomfortable." The description of Joe is "[if Joe is nervous]He's shifting uncomfortably[else]He's standing tall and proud[end if]."

Understand "cheer" as something new. Cheering is an action related to one person.

Carry out cheering (x - a person): if x is nervous: now x is relaxed; otherwise, say "[X] doesn't need to be cheered up." instead.

Report cheering (x - a person): say "You clap [X] on the back. It works: [regarding X: his] mood lightens."<2>

That's all you need for rudimentary gameplay:

TRAIN STATION

Your buddy, Joe, shifts from foot to foot, looking uncomfortable.

> look at joe

He's shifting uncomfortably.

> cheer joe

You clap Joe on the back. It works: his mood lightens.

> examine joe

He's standing tall and proud.

<1>: the medium started by, but not limited to, text adventure games like ADVENT and Zork

<2>: [regarding X: his] is roughly the syntax used to change "his", "her", etc. into the appropriate gender for the variable X. Because games and experiences built with Inform have all-text contents and interfaces, Inform provides a large number of constructs to tame printed strings.

Inform6 is much better and easier.

Thanks for responding.

In syntax, the two languages are quite unalike, so I think the relative "easiness" will come down to whether or not the learner was already a programmer.

As for "better:" better at what? better for whom? and why?

better _than_ if7. By design. If7 may be better for the non-programmer, but the syntax can be hideous. If6 allows you to be pretty modular writting very few of logic code.

Think of if7 as low-hanging fruit: if people who enjoy text adventures can't be bothered to play guess-the-verb, who can?

.length is easier.

.length, .size, .len, .count, then all those again but as functions taking an array argument, then again but as method calls, are not. And that’s not all the possibilities!

Seriously I bounce between languages enough that I have to look this shit up every time if autocomplete doesn’t help me out, and even that might take a couple tries.

No need to bounce between languages, you can get everything from C# : you call .Length on arrays but .Count on Lists but .Count() on IEnumerables ...

It's a good thing that Intellisense is top notch !

I guess there's no reason for a difference between .Length and .Count that I can think of.

I guess you could make IEnumerable's Count() into a property and enjoy the same syntax but I am not sure it's a good idea, because Count() needs to enumerate and is therefore O(n), and property syntax may coax you into writing with the expectation that it is O(1).

Then suddenly (it's been years since I did c#) I recall that Count() is added to the interface as an extension method with the "this" keyword. Is it possible to have an extension property? I do not think so but again it's been a while.

And on top of all that, it doesn't tell you the units of the result. Is it size in characters? Size in bytes? Size in code points? (Obviously in 1989, it was both characters and bytes, but these days, who knows?)

An amusing anecdote: Someone told me that HyperScript simply ignores the word "the" when interpreting scripts. I wonder if that's true for the other little words like "of" and "in." Too bad I no longer have a Mac, to try it out.

I wrote some industrial control apps using HyperCard. Unfortunately, it was at a time when the Mac OS was going through a dark period, and just wasn't stable enough to use in a factory. We ended up with Visual Basic instead, but I continued to use HyperCard at home.

I've just checked "of" on my Mac with HyperCard, and the answer is no - it's not optional. (I tried with "answer the number of cards" and "answer number of cards", which both worked fine, but "answer the number cards" and "answer number cards" both didn't).

If you still have copies of those industrial control HyperCard stacks, I'd love if you were to upload them[1] for the online collection[2] (provided, of course, that doing so doesn't violate any NDAs / etc...).

[1] http://hypercardonline.tk/

[2] https://archive.org/details/hypercardstacks

I've been searching in vain, but will keep my eye out. I'm glad you're keeping this archive.

What catches my eye is the it in

  put it into field "Customer Code"

What is it bound to? This reminds me of anaphoric macros in Lisp.

(If you don't know what that means, it's just a fancy name for automatically binding the variable "it" to some expression, which makes for lighter code in simple situations. Usually these are combined with some other operation like a boolean test, so they save you two lines of code instead of one. Some people hate them, but let's not go there.)

Dan Gackli, are you really a blithering unstrung archead or, more likely, a paid shill of the nefarious Anaphoric League? I KNOW I'LL BE DOWNVOTED FOR THIS but discussion of pronomial syntactic sugar is unNILable proof HN has turned into /r/lisp.

(as penance for the above: I was once told the Reed College student handbook contained a sentence saying the trouble with psychedelics is that one will be tempted to contemplate grand questions such as "what is love?" or "are there a finite or infinite number of gods?" when one is in a mental state completely unable to adequately address petty questions such as "what is toothpaste?" or "where is my left foot?")

Yeah, Hypercard represented peak Apple in my opinion. Using a computers was still "fun" in a way I can't articulate. Perhaps it reflects more myself at the time — not yet jaded....

See, what I don't really understand is how people wrote Hypercard when AppleScript is so universally reviled. Was there anything different about how they worked?

I was a user of both HyperTalk and AppleScript as a kid and I vividly remember how HyperTalk was easy and AppleScript was hell.

I think the hardest thing about AppleScript was the strict typing system. Dealing with files and paths was nigh-impossible. AppleScript also had the unenviable task of wrangling this typed data between different applications each with their own dictionary.

AppleScript really suffered if the dictionary provided by the app was ill thought out.

> Hypercard remains extraordinary. It anticipated the web...

In some ways it directly inspired it. I believe that the pointing hand cursor made its first appearance in HyperCard.

Flash, for all its flaws, had the same magic for a while. It, too, advanced beyond it - later versions were much more verbose to program in, and pushed code further away from the things it manipulated, in the name of making it easier for Serious Programmers to write Big Serious Tools.

I really miss the thoughtfulness of human-computer interfaces of the 1980s and 1990s. Serious amounts of thought and in many cases actual research was put into designing computer interfaces to maximize productivity and (get this) minimize distraction.

The idea back then was that a computer existed to augment human intelligence, not to trap you in a dopamine loop Skinner box to maximize "engagement." In fact, the phrase "augmented human intelligence" was present in the actual name of the SRI research program that originally developed early GUIs, hypertext, and the mouse among other things.

GUIs are an area where I think computing has gone very significantly downhill.

Modern interfaces are superficially prettier than those old GUIs, but the majority of this superficial aesthetic improvement can be attributed not to UI improvement but to technological advancement. It's much easier to make things pretty when you have high-DPI 24-bit or 32-bit true color displays and absolutely massive (by old time standards) amounts of computer power and RAM to draw on them. The flat panel revolution also contributed a lot. Has anyone around here actually tried to use a CRT monitor recently? It's astounding that we ever used those things. Even a bad LCD is much better than the very best CRTs ever made.

If you ignore the superficial eye candy, many if not most modern GUIs are objectively worse on almost every metric.

They're inconsistent, disorganized, unintuitive, and often distracting. Sometimes distraction is the actual objective, such as with mobile apps trying to dominate your attention to "go viral" or anything touching social media. Every app invents its own UI metaphors and design, increasing cognitive load, and apps frequently change their UIs needlessly and force their users to re-learn everything. These last two things were explicit no-nos in old school guides to UI best practices. The goal was to decrease cognitive load and maximize productivity, not create an employment program for designers and coders.

The developer experience behind modern UIs is even worse than the user experience. Many of those old systems offered WYSIWYG GUI development environments that were a breeze to use and delivered fast maintainable low-bloat (you couldn't get away with bloat back then!) applications. Design your UI and then double-click on its elements and it would jump right to the code. Amazing!

We've ditched this in favor of the modern bloated web clusterfuck, XML-based eyesores like XAML, or manually coding UIs in programming languages element by element. The amount of work required to build a UI has multiplied, but the value delivered has stayed the same or actually decreased. Some of this would be forgivable if we got something for it, but we're still stuck in the paradigm of "code everything for every platform" vs "bloated ugly cross-platform GUI toolkits" (the latter includes Electron).

Other areas of programming have advanced, but GUIs are a neglected ghetto in spite of the fact that UIs are absolutely fundamental to the use of computers. It's hideous. If we'd kept the principles of thoughtful UI design while advancing the underlying technology we would have computers that are all a dream to both program and to use.

Well, you still have TCL/TK, Lazarus, and such.

You describe it so well. It's worth emphasising how much frustration this causes. Especially to those who don't use computers very often. They desperately try to make sense of it or find some pattern. All I can say to them is: "No it's not you, it's just bad design, don't worry about it"

Using verbose English grammar to describe software, might be easy to learn and look nice, but it's a severely restricted by it's intended use-cases.

It's a similar problem to visual programming and AI based programming (GPT-3), where you're fundamentally describing a very implicit program. In some use-cases this is fine, but in many situations it can be difficult, unpredictable or even impossible to describe the program using implicit language.

The HyperTalk language is well-documented. It has a clearly-defined syntax like any other programming language. It just happens to look more natural than most, but it's not an unpredictable guessing game like Wolfram Alpha.

But isn’t that the point. It’s a well documented programming language.

You just have to remember longer commands, which while cute at first gets tiring quickly, even for novices

It’s arguably easier to remember, the way a speaker of a Romance language can more easily pick up other Romance languages.

And it’s also easier to read if you’re not an expert on the language.

I think something like this has its place. I found it very empowering as an 8 year old kid.

It's an accessible scripting language designed for non-technical users.

Which is obvious. What's less obvious is that a good accessible scripting language for non-technical users renders plenty of inaccessible programming redundant. So in the bigger picture it's much less tiring than the alternative we have today, which locks users out of all but the most trivial and useless DIY web publishing.

Hypercard could easily have become the foundation for a different vision of the web. If it had, the current shitpile of competing frameworks, languages, levels of concern, and so on would have been hugely lessened.

Reply on news.ycombinator.com