3 ms·

that's an understandable reaction to the language but, I think you have to admit that the result is very readable, even if it might be hard to write at first.

that's an understandable reaction to the language but, I think you have to admit that the result is very readable, even if it might be hard to write at first. I programmed in HyperTalk as a kid and always missed how easy it was to read and, for small embedded things like toggling a class toggle .foo on #bar i really like how it looks AppleTalk was always kind of a mess because they didn't give you much syntactic support for working with apps, so you ended up guessing strings to pass around when what you really wanted was syntax. hyperscript has DOM-specific syntax (as well as an open, pluggable grammar) so it is more tightly focused on those operations and, I hope, less ugly than what AppleTalk ended up looking like It definitely favors code read time over write time, though. We'll see if it goes anywhere.

ryanianian 4y ago
It certainly is subjective. This is where AppleScript really fell down--English is inverted, but typical programming starts with a noun then does a verb to it. Given it's written <verb> <noun> (toggle a on x) rather than <noun> <verb> (x.toggle(a)), I don't see how you can know the space of verbs the noun will accept without perhaps starting with a guess and then seeing what the tool provides or something? I get it's more constrained than AppleTalk, but does that actually solve the issue in practice?
- recursivedoubts 4y ago
  I think the fact that the language is designed to be embedded on elements makes it clear that the implicit subject and object is the current element (the "me" or "I" symbol in hyperscript <div _="on mousenter toggle .expand" ...> ... </div> So the language comes across as imperative statements, with the current element being the default subject and object, as with english instructions. Most commands (statements) accept a noun target: <div _="on mousenter toggle .expand on the closest <section/>" ...> ... </div> But, due to the embedded nature of the language it still comes across as you telling the diff to toggle the class on the other section. There is also a tell command that allows you to switch the default object (which you can access explicitly in the "you" and "yourself" symbols: <div _="on mousenter tell the closest <section/> toggle .expand" ...> ... </div> Insanity, I know. There are also three, count'em three different ways to access properties: set x to arr.length set y to the arr's length set z to the length of the array Fun! Also insane. But also fun!
mikelevins 4y ago
HyperTalk and AppleTalk are both easy to read, but a little hard to write--AppleScript moreso than HyperTalk. I think it's a reasonable tradeoff to make. It may be too much of a pain form some, but I did some substantial work in HyperTalk and AppleScript (and its immediate ancestor, SK8Script), and found that I got used to it. I wouldn't say that I ever loved it, but I didn't mind it so much after I got used to it. At the risk of veering into inside baseball (I worked on SK8Script, HyperCard, and AppleScript over the course of a few years), a problem with AppleScript was that it was really only the outline of a language with a pluggable grammar and pluggable semantics. One of my colleagues working on it characterized it as more like a network protocol than a programming language. It specified some fairly broad abstractions (containers, elements, documents, and so on), but left most of the details and the vocabulary up to applications, so the same nouns and verbs could mean wildly different things in different contexts. That made it even harder to write. On the other hand, it was usually really easy to read and understand, which is handy. By the way, I'm finding htmx and hyperscript quite useful.

ryanianian 4y ago

It certainly is subjective. This is where AppleScript really fell down--English is inverted, but typical programming starts with a noun then does a verb to it. Given it's written <verb> <noun> (toggle a on x) rather than <noun> <verb> (x.toggle(a)), I don't see how you can know the space of verbs the noun will accept without perhaps starting with a guess and then seeing what the tool provides or something? I get it's more constrained than AppleTalk, but does that actually solve the issue in practice?

recursivedoubts 4y ago
I think the fact that the language is designed to be embedded on elements makes it clear that the implicit subject and object is the current element (the "me" or "I" symbol in hyperscript <div _="on mousenter toggle .expand" ...> ... </div> So the language comes across as imperative statements, with the current element being the default subject and object, as with english instructions. Most commands (statements) accept a noun target: <div _="on mousenter toggle .expand on the closest <section/>" ...> ... </div> But, due to the embedded nature of the language it still comes across as you telling the diff to toggle the class on the other section. There is also a tell command that allows you to switch the default object (which you can access explicitly in the "you" and "yourself" symbols: <div _="on mousenter tell the closest <section/> toggle .expand" ...> ... </div> Insanity, I know. There are also three, count'em three different ways to access properties: set x to arr.length set y to the arr's length set z to the length of the array Fun! Also insane. But also fun!

mikelevins 4y ago

HyperTalk and AppleTalk are both easy to read, but a little hard to write--AppleScript moreso than HyperTalk. I think it's a reasonable tradeoff to make. It may be too much of a pain form some, but I did some substantial work in HyperTalk and AppleScript (and its immediate ancestor, SK8Script), and found that I got used to it. I wouldn't say that I ever loved it, but I didn't mind it so much after I got used to it. At the risk of veering into inside baseball (I worked on SK8Script, HyperCard, and AppleScript over the course of a few years), a problem with AppleScript was that it was really only the outline of a language with a pluggable grammar and pluggable semantics. One of my colleagues working on it characterized it as more like a network protocol than a programming language. It specified some fairly broad abstractions (containers, elements, documents, and so on), but left most of the details and the vocabulary up to applications, so the same nouns and verbs could mean wildly different things in different contexts. That made it even harder to write. On the other hand, it was usually really easy to read and understand, which is handy. By the way, I'm finding htmx and hyperscript quite useful.