6 ms·

I started out with HyperCard and when I outgrew it, upgraded to REALbasic, a cross-platform Visual Basic clone (now Xojo). When I started college I switched to

I started out with HyperCard and when I outgrew it, upgraded to REALbasic, a cross-platform Visual Basic clone (now Xojo). When I started college I switched to writing C++, which I perceived as a more "professional" language, but in doing so left the GUI behind and started producing almost exclusively command-line tools. When I try to write a GUI app these days, I'm stunned by how much harder it seems. As an elementary school student I could churn out HyperCard stacks without being able to search Google, ask on StackOverflow, or watch a YouTube tutorial. One of the things modern tools left behind is how the code and UI were bound together. In HyperCard or REALbasic, the code for what a button does is "inside" the button, so if you want to know how it works or modify its behavior, you just "open it up" it in the editor. Stringing together IBActions or attaching event handlers to DOM elements may be a more general solution, but most of the time the distance it introduces between the button and its effect is just extra cognitive overhead.

egypturnash 5y ago
One of the things modern tools left behind is how the code and UI were bound together. For a while, Flash had this, and it was one of the things that made it fun and easy to hack stuff together with. Then Actionscript 3 happened and that wasn't allowed any more because AS3 was a Serious Language for Serious Developers. (Actionscript 1 was a horrible thing you could only enter by selecting keywords from a dropdown menu, it was really terrible for doing anything more than basic interactivity. AS2 hit a real sweet spot of being something you could quickly type into a text box and tie closely to the objects in the editor.)
- 5- 5y ago
  > Actionscript 1 was a horrible thing you could only enter by selecting keywords from a dropdown menu my memory of those times is a bit fuzzy, but according to https://en.wikipedia.org/wiki/ActionScript#Timeline_by_ActionScript_version https://en.wikipedia.org/wiki/ActionScript#Timeline_by_Actio... what you describe was 'actions' prior to flash 5, which introduced actionscript1 which was a normal text-based scripting language. edit: i just had to check (thanks -- i now got to enjoy flash 5 on my windows 2000 install). the 'object actions' editor in flash 5 has a 'normal/expert mode' toggle, where 'normal' (the default) is the menu-based interface as you describe and 'expert' is the normal text editor.
  - kmeisthax 5y ago
    You are correct. In fact, pre-AS1, Flash Actions were a dramatically different VM. If you wanted to store a property on an object you had to use slash paths. "../hero:gun/bullet" would go up one clip, look for something called hero, look for a gun on the hero, and then a bullet in the gun. Macromedia beat Actions into something that could vaguely-resemble an ECMA-262 3ed language runtime if you squinted hard enough. However, all of the old warts still remain, probably because otherwise you couldn't upgrade from Flash 4 and compile to newer SWF versions. Thus, Actions, ActionScript, and ActionScript 2.0 all compile to the same VM. The only difference in semantics come if you compile to a newer or older Flash Player version. AS3 is an entirely different VM that actually was designed to serve as the runtime for the 4th edition of ECMAScript, which never actually came out because web developers thought it was way too complicated. However, the only features that never actually made it into modern JS are namespaces, interfaces, and prototype-free classes. Everything else did eventually make it back into ES5 or ES6, albeit in dramatically different ways[0] sometimes. [0] For example, when you declare a `class` in modern JavaScript, you are actually invoking syntactic sugar (mostly) for declaring a constructor function, setting the prototype to an instance of the parent, and then populating methods on the prototype. This is also how AS2 did it, too. In ES4, they instead decided to completely junk prototypes in favor of Java-style inheritance. When you declare a class, you're creating an actual Class with a vtable and everything. It's instances actually get copies of their methods with `this` properly bound, which you can shove directly into `addEventListener` and `removeEventListener` and expect to work.
  - egypturnash 5y ago
    My memory is a bit fuzzy too, it’s been a while. I kludged up an entire game in Flash 4 with that dropdown. It was not at all pleasant. :)
blowski 5y ago
> One of the things modern tools left behind is how the code and UI were bound together That seems wrong to me, unless I've misunderstood your comment. It's more like there's a saturated market full of such tools. Microsot Power Apps, Quickbase, Mendix, Salesforce Platform all provide "no-code solutions" that let you drag and drop and customise with code. Then there are Bootstrap generators that you let you control layout. I've seen plugins that integrate React components into a WYSIWYG editor. Even PowerPoint has easy to attach custom actions for desktop presentations.
- golem14 5y ago
  IMO, the problem is that many of those tools are really not that reliable in the sense that they may go away soon. It all takes a company to be acquired by M$, GOOG etc and then taken offline. For example, I lived through Google Appmaker (absolutely fantastic!) which was retired with 6 months notice. It's really risky to build larger app on no-code platforms that you don't fully control via self-hosting. And I don't know great open-source/open-core low/no-code stacks that are easy to use and expressive enough. It would be great to get pointers. I guess a the height of hypercard, that really wasn't really on people's radar.
  - blowski 5y ago
    Sounds like you're worried about what happens if you embed and tightly couple a lot of your business logic to something you don't have full control over? That's a totally valid concern, and probably one of the reasons we've tended to move away from these tools and towards doing everything in stable programming languages. It's a classic set of trade-offs - quality, features, stability, security, price. There are lots of solutions on the market offering one configuration of those trade-offs. If it existed today, some people would push for HyperCard to support mobile apps, multi-user access, web-based and native apps, all of which would make the solution 'worse" for others.
    - danielheath 5y ago
      There’s nothing inherent about low-code that requires it to be tied to hosting provided by a specific entity which can unilaterally terminate it.
dhosek 5y ago
The problem with this model is that it ends up being an invitation to mix "business" logic with the UI. I look at some of the PHP code I wrote (back when it was still PHP3) or some of the JSP stuff I've had to work with and this model of development always ends up an unholy mess.
- falcor84 5y ago
  I wonder if there could be some "gradual" approach here where perhaps you'd have levels of maturity that you can evolve a project thorough over time. Perhaps something such as: 0: no separation of concerns whatsoever, just quickly hacking at it. 1: no separation of concerns required, but you have to label each component as having one or more concerns. This would still allow for mixed "business+presentation", but you can add constraints such as "a pure business component is not allowed to depend on a pure presentation component". 2: No mixed-concerns components allowed. So you have to split them somehow, but they can still interact in arbitrary ways. 3: All interaction across concerns has to go through specific interfaces, such that it's easy to replace implementations (e.g. using dependency injection).
vermilingua 5y ago
For me, React and SwiftUI definitely fill this niche. React requires more googling but it’s still fairly simple to throw together a functional UI. SwiftUI is even easier, but when you want to customise away from the Apple provided appearance it gets considerably harder than with React.
phendrenad2 5y ago
For Windows at least, you can still use WinForms from C# and get a nice GUI designer where code lives "inside" each button.
badsectoracula 5y ago
With Lazarus[0] you can basically get the same experience as REALbasic/Xojo. Here is a video[1] i made a few years ago, making a simple 2D tilemap editor using it. [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ [1] https://www.youtube.com/watch?v=_3JgeIUo1X0 https://www.youtube.com/watch?v=_3JgeIUo1X0
dfabulich 5y ago
As other commenters have pointed out, there are a bunch of simple GUI builders out there that embed button code "inside" the button, including GUI builders for the web, but none of them are popular. Hypercard became popular because it hit a sweet spot of supply and demand that can't be reproduced today. When Hypercard launched, it came with every Mac, it was free, and there was nothing else like it available on the Mac. On the Mac, the alternative to Hypercard was to layout UI widgets in code, with no GUI builder at all, or eventually to pay $$$ for a professional-grade IDE like CodeWarrior. As an entry-level user with no budget, if you wanted a GUI builder for the Mac, you got Hypercard, or nothing. This created a community of Hypercard enthusiasts. Furthermore, when Hypercard launched, Macs had a standard screen resolution. Every Mac sold had a screen resolution of 512x342 pixels, so you could know for sure how your cards would look on any Mac. Supporting resizable GUIs is one of the hardest things to do in any GUI builder. (How should the buttons layout when the screen gets very small, like a phone? Or very wide, like a 16:9 monitor?) Today, Xcode uses a sophisticated constraint solver / theorem prover to allow developers to build resizable UIs in a GUI; it works pretty well, I think, but it's never going to be as easy to learn as "drag the button onto the screen and it's going to look exactly like that everywhere." The last issue is the real killer for modern Hypercard wannabes: it's a small step from a web GUI builder to raw HTML/CSS. You don't have to pay big bucks to have access to professional-grade HTML, CSS, and JavaScript. Sure, they're not that easy to learn, but you can teach a kid to write interactive web pages, no problem. As a result, the demand for a simple GUI builder is lower than it was for Hypercard, and even when you do capture a user, they tend to outgrow your product, and there are a zillion competitors, so none of them can build a community with real traction.

egypturnash 5y ago

One of the things modern tools left behind is how the code and UI were bound together. For a while, Flash had this, and it was one of the things that made it fun and easy to hack stuff together with. Then Actionscript 3 happened and that wasn't allowed any more because AS3 was a Serious Language for Serious Developers. (Actionscript 1 was a horrible thing you could only enter by selecting keywords from a dropdown menu, it was really terrible for doing anything more than basic interactivity. AS2 hit a real sweet spot of being something you could quickly type into a text box and tie closely to the objects in the editor.)

5- 5y ago
> Actionscript 1 was a horrible thing you could only enter by selecting keywords from a dropdown menu my memory of those times is a bit fuzzy, but according to https://en.wikipedia.org/wiki/ActionScript#Timeline_by_ActionScript_version https://en.wikipedia.org/wiki/ActionScript#Timeline_by_Actio... what you describe was 'actions' prior to flash 5, which introduced actionscript1 which was a normal text-based scripting language. edit: i just had to check (thanks -- i now got to enjoy flash 5 on my windows 2000 install). the 'object actions' editor in flash 5 has a 'normal/expert mode' toggle, where 'normal' (the default) is the menu-based interface as you describe and 'expert' is the normal text editor.
- kmeisthax 5y ago
  You are correct. In fact, pre-AS1, Flash Actions were a dramatically different VM. If you wanted to store a property on an object you had to use slash paths. "../hero:gun/bullet" would go up one clip, look for something called hero, look for a gun on the hero, and then a bullet in the gun. Macromedia beat Actions into something that could vaguely-resemble an ECMA-262 3ed language runtime if you squinted hard enough. However, all of the old warts still remain, probably because otherwise you couldn't upgrade from Flash 4 and compile to newer SWF versions. Thus, Actions, ActionScript, and ActionScript 2.0 all compile to the same VM. The only difference in semantics come if you compile to a newer or older Flash Player version. AS3 is an entirely different VM that actually was designed to serve as the runtime for the 4th edition of ECMAScript, which never actually came out because web developers thought it was way too complicated. However, the only features that never actually made it into modern JS are namespaces, interfaces, and prototype-free classes. Everything else did eventually make it back into ES5 or ES6, albeit in dramatically different ways[0] sometimes. [0] For example, when you declare a `class` in modern JavaScript, you are actually invoking syntactic sugar (mostly) for declaring a constructor function, setting the prototype to an instance of the parent, and then populating methods on the prototype. This is also how AS2 did it, too. In ES4, they instead decided to completely junk prototypes in favor of Java-style inheritance. When you declare a class, you're creating an actual Class with a vtable and everything. It's instances actually get copies of their methods with `this` properly bound, which you can shove directly into `addEventListener` and `removeEventListener` and expect to work.
- egypturnash 5y ago
  My memory is a bit fuzzy too, it’s been a while. I kludged up an entire game in Flash 4 with that dropdown. It was not at all pleasant. :)

blowski 5y ago

> One of the things modern tools left behind is how the code and UI were bound together That seems wrong to me, unless I've misunderstood your comment. It's more like there's a saturated market full of such tools. Microsot Power Apps, Quickbase, Mendix, Salesforce Platform all provide "no-code solutions" that let you drag and drop and customise with code. Then there are Bootstrap generators that you let you control layout. I've seen plugins that integrate React components into a WYSIWYG editor. Even PowerPoint has easy to attach custom actions for desktop presentations.

golem14 5y ago
IMO, the problem is that many of those tools are really not that reliable in the sense that they may go away soon. It all takes a company to be acquired by M$, GOOG etc and then taken offline. For example, I lived through Google Appmaker (absolutely fantastic!) which was retired with 6 months notice. It's really risky to build larger app on no-code platforms that you don't fully control via self-hosting. And I don't know great open-source/open-core low/no-code stacks that are easy to use and expressive enough. It would be great to get pointers. I guess a the height of hypercard, that really wasn't really on people's radar.
- blowski 5y ago
  Sounds like you're worried about what happens if you embed and tightly couple a lot of your business logic to something you don't have full control over? That's a totally valid concern, and probably one of the reasons we've tended to move away from these tools and towards doing everything in stable programming languages. It's a classic set of trade-offs - quality, features, stability, security, price. There are lots of solutions on the market offering one configuration of those trade-offs. If it existed today, some people would push for HyperCard to support mobile apps, multi-user access, web-based and native apps, all of which would make the solution 'worse" for others.
  - danielheath 5y ago
    There’s nothing inherent about low-code that requires it to be tied to hosting provided by a specific entity which can unilaterally terminate it.

dhosek 5y ago

The problem with this model is that it ends up being an invitation to mix "business" logic with the UI. I look at some of the PHP code I wrote (back when it was still PHP3) or some of the JSP stuff I've had to work with and this model of development always ends up an unholy mess.

falcor84 5y ago
I wonder if there could be some "gradual" approach here where perhaps you'd have levels of maturity that you can evolve a project thorough over time. Perhaps something such as: 0: no separation of concerns whatsoever, just quickly hacking at it. 1: no separation of concerns required, but you have to label each component as having one or more concerns. This would still allow for mixed "business+presentation", but you can add constraints such as "a pure business component is not allowed to depend on a pure presentation component". 2: No mixed-concerns components allowed. So you have to split them somehow, but they can still interact in arbitrary ways. 3: All interaction across concerns has to go through specific interfaces, such that it's easy to replace implementations (e.g. using dependency injection).

vermilingua 5y ago

For me, React and SwiftUI definitely fill this niche. React requires more googling but it’s still fairly simple to throw together a functional UI. SwiftUI is even easier, but when you want to customise away from the Apple provided appearance it gets considerably harder than with React.

phendrenad2 5y ago

For Windows at least, you can still use WinForms from C# and get a nice GUI designer where code lives "inside" each button.

badsectoracula 5y ago

With Lazarus[0] you can basically get the same experience as REALbasic/Xojo. Here is a video[1] i made a few years ago, making a simple 2D tilemap editor using it. [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ [1] https://www.youtube.com/watch?v=_3JgeIUo1X0 https://www.youtube.com/watch?v=_3JgeIUo1X0

dfabulich 5y ago

As other commenters have pointed out, there are a bunch of simple GUI builders out there that embed button code "inside" the button, including GUI builders for the web, but none of them are popular. Hypercard became popular because it hit a sweet spot of supply and demand that can't be reproduced today. When Hypercard launched, it came with every Mac, it was free, and there was nothing else like it available on the Mac. On the Mac, the alternative to Hypercard was to layout UI widgets in code, with no GUI builder at all, or eventually to pay $$$ for a professional-grade IDE like CodeWarrior. As an entry-level user with no budget, if you wanted a GUI builder for the Mac, you got Hypercard, or nothing. This created a community of Hypercard enthusiasts. Furthermore, when Hypercard launched, Macs had a standard screen resolution. Every Mac sold had a screen resolution of 512x342 pixels, so you could know for sure how your cards would look on any Mac. Supporting resizable GUIs is one of the hardest things to do in any GUI builder. (How should the buttons layout when the screen gets very small, like a phone? Or very wide, like a 16:9 monitor?) Today, Xcode uses a sophisticated constraint solver / theorem prover to allow developers to build resizable UIs in a GUI; it works pretty well, I think, but it's never going to be as easy to learn as "drag the button onto the screen and it's going to look exactly like that everywhere." The last issue is the real killer for modern Hypercard wannabes: it's a small step from a web GUI builder to raw HTML/CSS. You don't have to pay big bucks to have access to professional-grade HTML, CSS, and JavaScript. Sure, they're not that easy to learn, but you can teach a kid to write interactive web pages, no problem. As a result, the demand for a simple GUI builder is lower than it was for Hypercard, and even when you do capture a user, they tend to outgrow your product, and there are a zillion competitors, so none of them can build a community with real traction.