4 ms·

Not trolling, but just asking a serious question. If HyperCard was the bee knees, why doesn't some make an open source version of it?

bayareaguy 19y ago
There is PythonCard: http://pythoncard.sourceforge.net/ http://pythoncard.sourceforge.net/ Unfortunately it doesn't appear to be updated recently.
michaelneale 19y ago
Good point. I was a fan of it (as a young-un). Enabled me to catalogue all sorts of stuff in a nice database (with multimedia before the term was common). I think 2 reasons: 1) There are generally fewer open source projects with truly user friendly interfaces (cause its a lot of grinding work). 2) Hypercard made pseudo-programming easier for non programmers. Something that the type of people who tend to work on open source don't always agree with. Heck, if you don't workin in language XYZ, you are vile scum worthy of death, for XYZ <= blub.
nostrademons 19y ago
People write open-source software for recognition from their peers. Our peers (other professional programmers) have no use for end-user programming software, because they aren't end-users and can use more powerful tools. Basically, the folks who could write HyperCard aren't the folks who use HyperCard, and when there's no money involved, people will write software that they themselves want to use.
procrastitron 19y ago
That's not a troll, that's a challenge. One that someone should take up. Not me, though... I'm too busy :-(
rcoder 19y ago
Disclaimer: it's been >10 years since I did any HyperCard/HyperTalk programming, so I will admit that I may mis-state some of the points below. That being said, HyperCard served as a major training ground for me when I was getting started programming, and I even went so far as to step through a fair bit of the obfuscated stack that made up Myst in order to understand how it had been implemented... HyperCard suffered from a few obvious problems for larger-scale programming. First, it lacked any support for meaningful code structure and re-use. You didn't so much have functions or procedures so much as you had GOTO statements pointing between cards. For simple logic, that may be fine, but for more complicated workflow, the 1:1 mapping between cards and code blocks, and lack of shared state between them, means that non-trivial apps quickly became a mess of HyperTalk and hackish extensions written in C. Also, it was tightly tied to a number of MacOS platform technologies; at a minimum, building a full clone of HyperCard would have required re-implementing some analogue to QuickDraw, including (IIRC) some undocumented hooks that the engineers at Apple used into the underlying system. In the end, though, what probably killed HyperCard more than anything else was the rise of the web browser. Many of the basic operations of a HyperCard stack -- linking between discrete pages of data, providing simple interactive widgets and multimedia, and supporting complex layout of text and images -- are extremely well-supported by graphical web browsers, and the fact that resources are stored on the network mean that you don't have to pass around stacks on disk like you did in the HyperCard days. That being said, there have been periodic efforts to fill the same niche, without continuing to enforce the more baroque limitations that HyperCard had. PythonCard was a very interesting project, but seems to be pretty much dead at this point. The [Shoes](http://code.whytheluckystiff.net/shoes/ http://code.whytheluckystiff.net/shoes/) project seems to be a good bit more active at this point. It's still at a pretty early stage in terms of API stability, but _why is one of the more tenacious programmers out there, and the community that has already sprung up around it is impressive.

bayareaguy 19y ago

There is PythonCard: http://pythoncard.sourceforge.net/ http://pythoncard.sourceforge.net/ Unfortunately it doesn't appear to be updated recently.

michaelneale 19y ago

Good point. I was a fan of it (as a young-un). Enabled me to catalogue all sorts of stuff in a nice database (with multimedia before the term was common). I think 2 reasons: 1) There are generally fewer open source projects with truly user friendly interfaces (cause its a lot of grinding work). 2) Hypercard made pseudo-programming easier for non programmers. Something that the type of people who tend to work on open source don't always agree with. Heck, if you don't workin in language XYZ, you are vile scum worthy of death, for XYZ <= blub.

nostrademons 19y ago

People write open-source software for recognition from their peers. Our peers (other professional programmers) have no use for end-user programming software, because they aren't end-users and can use more powerful tools. Basically, the folks who could write HyperCard aren't the folks who use HyperCard, and when there's no money involved, people will write software that they themselves want to use.

procrastitron 19y ago

That's not a troll, that's a challenge. One that someone should take up. Not me, though... I'm too busy :-(

rcoder 19y ago

Disclaimer: it's been >10 years since I did any HyperCard/HyperTalk programming, so I will admit that I may mis-state some of the points below. That being said, HyperCard served as a major training ground for me when I was getting started programming, and I even went so far as to step through a fair bit of the obfuscated stack that made up Myst in order to understand how it had been implemented... HyperCard suffered from a few obvious problems for larger-scale programming. First, it lacked any support for meaningful code structure and re-use. You didn't so much have functions or procedures so much as you had GOTO statements pointing between cards. For simple logic, that may be fine, but for more complicated workflow, the 1:1 mapping between cards and code blocks, and lack of shared state between them, means that non-trivial apps quickly became a mess of HyperTalk and hackish extensions written in C. Also, it was tightly tied to a number of MacOS platform technologies; at a minimum, building a full clone of HyperCard would have required re-implementing some analogue to QuickDraw, including (IIRC) some undocumented hooks that the engineers at Apple used into the underlying system. In the end, though, what probably killed HyperCard more than anything else was the rise of the web browser. Many of the basic operations of a HyperCard stack -- linking between discrete pages of data, providing simple interactive widgets and multimedia, and supporting complex layout of text and images -- are extremely well-supported by graphical web browsers, and the fact that resources are stored on the network mean that you don't have to pass around stacks on disk like you did in the HyperCard days. That being said, there have been periodic efforts to fill the same niche, without continuing to enforce the more baroque limitations that HyperCard had. PythonCard was a very interesting project, but seems to be pretty much dead at this point. The [Shoes](http://code.whytheluckystiff.net/shoes/ http://code.whytheluckystiff.net/shoes/) project seems to be a good bit more active at this point. It's still at a pretty early stage in terms of API stability, but _why is one of the more tenacious programmers out there, and the community that has already sprung up around it is impressive.