4 ms·

Sigh. Maybe instead of ranting at your "typical software engineer", the author should spend a moment to consider that maybe it "could be built again" - but it n

by groby_b 15y ago

Sigh. Maybe instead of ranting at your "typical software engineer", the author should spend a moment to consider that maybe it "could be built again" - but it never has. So the question then turns to, why has it never been built? Is it maybe because Hypercard (and other visual systems) become entirely unmaintainable once we get to large-scale systems? And maybe it is because most people don't want a trivialized programming environment? They either want a full system, or just a product?

dahjelle 15y ago
> They either want a full system, or just a product. While I think this is true at the moment, it seems that there is an interesting question behind that, as well. Why don't more people want to create their own software? I do think the author has an implicit point: because, frankly, creating software stinks. Jon Skeet's talk [1] demonstrates this admirably. I spend a shockingly large part of my time working around bugs and leaky abstractions in other software rather than implementing my own ideas. I don't know if it is possible to design a system with a solid enough abstraction that these problems don't exist. I do know that HyperCard came unusually close, as I know several folks who made HyperCard stacks who wouldn't imagine creating software in any typical fashion. I hold out hope that such a useful system could be created again, one that gives people enough flexibility to create software solutions of their own (perhaps within a genre of software) and that is able to combat the currently-accurate stigma of programming being "hard". [1] http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-pon...
- WiseWeasel 15y ago
  Lego Mindstorms (http://mindstorms.lego.com/ http://mindstorms.lego.com/) is kind of like Hypercard for the modern age. It's got interesting applications (robotics and automation), and an easy-to-learn programming environment. I'd say it's the perfect product for a budding geek to cut her teeth on.
- groby_b 15y ago
  Hm. I've never seen a HyperCard project that was both maintainable and of a large-ish size. I think _that_ is where the HyperCard idea broke down - navigating through a bunch of cards is significantly more difficult than through a bunch of text files. Granted, that _may_ be a question of the tools. But I do find it telling that in the long time since the "death" of HyperCard nobody could come up with compelling tools. And creating software is hard because ultimately, it requires analytical thinking. Which, by itself, is hard. Yes, the choice of tool modulates the hardness of the problem - but the underlying issues are still hard. (Note: I do not claim non-programmers _can't_ reason analytically. I claim the effort/result ratio is not right for them) It's the same reason most people buy furniture instead of building it. Acquiring the necessary skill set is simply too much effort for the result.
  - dahjelle 15y ago
    I definitely agree that software desire requires analytical thinking. (It certainly put a halt in my thoughts about a mass-appeal software builder: if they don't "get" [or want to get, or whatever] Excel, they don't have a chance for much else.) I do think, though, that not being able to make projects of large-ish size isn't necessarily important for a wide variety of use cases. Most of the best apps I know of do only a very small thing—but do it very well. I think HyperCard allow people to do small things exactly the way they wanted. Which maybe wasn't very well, but was good enough for their needs and better than the alternatives. As I mentioned in my other comment [1], I wonder if the parallel is somewhat like the UNIX command line. You probably aren't going to write a MySQL competitor in bash. But there are a whole class of small custom tools that you will write. To perhaps restate my original point (and this is where perhaps we agree), the abstractions of HyperCard eventually didn't (couldn't?) adapt. Perhaps, as you said, because of cards. As someone else commented, also partially because of the codebase, but also, I think, because things like color and networking and a greater number of standard UI widgets all had to be added. [1] http://news.ycombinator.com/item?id=3294915 http://news.ycombinator.com/item?id=3294915
6ren 15y ago
Spreadsheets are arguably a "trivialized programming environment".
- praptak 15y ago
  Which (sort of) supports GP's argument. We have programming environments on one end, full products on another and spreadsheets (maybe also MS Access) in the middle. The environment looks crowded. Btw, I'd love spreadsheets-as-apps replaced with something more maintainable but they also have a huge advantage: you can start using a spreadsheet with zero programming. Unless you copy that, you can't compete for that niche.
  - 6ren 15y ago
    If we have room at the ends (for new programming environments, and new products), why can't we have room in the middle? Something else with zero programming is online form builders; some already have constraints and reporting systems. If they added simple programming constructs, it could be as powerful as you like. (e.g. google forms enables you to skip to different questions based on previous answers, though it's getting away from easy visualization, unlike spreadsheets). You can view them as being a database, derived from input forms - what's stopping them growing towards unmaintainable real databases, in the way that spreadsheets can grow into unmaintainable apps? A way to think about this is not in terms of a complex thing, but in terms of a simple thing... a toy... to which you can add-on complexity. e.g. I'm not sure that the first spreadsheets were fully programmable, but just related different cells by formula. And I know for sure that the first RDBs didn't have stored procedures. Maybe, this could be done for many webapps: wiki + scripts; reddit + scripts (what would that be?); youtube + scripts (we have it a little bit with links on parts of the video). The puzzle is imagining what could possibly be the use of these... it helps if you already have a manual version that you are automatic (that's what the visicalc guys did: "spreadsheets" existed, on paper, before them: http://inventors.about.com/library/weekly/aa010199.htm http://inventors.about.com/library/weekly/aa010199.htm). There's visual webapps for assembling webservices, but they don't seem to have taken off. Maybe the "problem" is that they scale - the thing you create is good for more than just one person, unlike most spreadsheet documents, which (excluding templates) contains your own specific data - often, proprietary business data. Because it can scale, people invest more effort in it, and are happy to use proper APIs etc. And then, consumers don't have an unsatisfied need, because it's already done. Therefore, perhaps the "toy" needs to be about a particular business or person (e.g. be about their data). Also: Arguably, Flash authoring tools took the place of hypercard.

by groby_b 15y ago

dahjelle 15y ago

> They either want a full system, or just a product. While I think this is true at the moment, it seems that there is an interesting question behind that, as well. Why don't more people want to create their own software? I do think the author has an implicit point: because, frankly, creating software stinks. Jon Skeet's talk [1] demonstrates this admirably. I spend a shockingly large part of my time working around bugs and leaky abstractions in other software rather than implementing my own ideas. I don't know if it is possible to design a system with a solid enough abstraction that these problems don't exist. I do know that HyperCard came unusually close, as I know several folks who made HyperCard stacks who wouldn't imagine creating software in any typical fashion. I hold out hope that such a useful system could be created again, one that gives people enough flexibility to create software solutions of their own (perhaps within a genre of software) and that is able to combat the currently-accurate stigma of programming being "hard". [1] http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-pon...

WiseWeasel 15y ago
Lego Mindstorms (http://mindstorms.lego.com/ http://mindstorms.lego.com/) is kind of like Hypercard for the modern age. It's got interesting applications (robotics and automation), and an easy-to-learn programming environment. I'd say it's the perfect product for a budding geek to cut her teeth on.
groby_b 15y ago
Hm. I've never seen a HyperCard project that was both maintainable and of a large-ish size. I think _that_ is where the HyperCard idea broke down - navigating through a bunch of cards is significantly more difficult than through a bunch of text files. Granted, that _may_ be a question of the tools. But I do find it telling that in the long time since the "death" of HyperCard nobody could come up with compelling tools. And creating software is hard because ultimately, it requires analytical thinking. Which, by itself, is hard. Yes, the choice of tool modulates the hardness of the problem - but the underlying issues are still hard. (Note: I do not claim non-programmers _can't_ reason analytically. I claim the effort/result ratio is not right for them) It's the same reason most people buy furniture instead of building it. Acquiring the necessary skill set is simply too much effort for the result.
- dahjelle 15y ago
  I definitely agree that software desire requires analytical thinking. (It certainly put a halt in my thoughts about a mass-appeal software builder: if they don't "get" [or want to get, or whatever] Excel, they don't have a chance for much else.) I do think, though, that not being able to make projects of large-ish size isn't necessarily important for a wide variety of use cases. Most of the best apps I know of do only a very small thing—but do it very well. I think HyperCard allow people to do small things exactly the way they wanted. Which maybe wasn't very well, but was good enough for their needs and better than the alternatives. As I mentioned in my other comment [1], I wonder if the parallel is somewhat like the UNIX command line. You probably aren't going to write a MySQL competitor in bash. But there are a whole class of small custom tools that you will write. To perhaps restate my original point (and this is where perhaps we agree), the abstractions of HyperCard eventually didn't (couldn't?) adapt. Perhaps, as you said, because of cards. As someone else commented, also partially because of the codebase, but also, I think, because things like color and networking and a greater number of standard UI widgets all had to be added. [1] http://news.ycombinator.com/item?id=3294915 http://news.ycombinator.com/item?id=3294915

6ren 15y ago

Spreadsheets are arguably a "trivialized programming environment".

praptak 15y ago
Which (sort of) supports GP's argument. We have programming environments on one end, full products on another and spreadsheets (maybe also MS Access) in the middle. The environment looks crowded. Btw, I'd love spreadsheets-as-apps replaced with something more maintainable but they also have a huge advantage: you can start using a spreadsheet with zero programming. Unless you copy that, you can't compete for that niche.
- 6ren 15y ago
  If we have room at the ends (for new programming environments, and new products), why can't we have room in the middle? Something else with zero programming is online form builders; some already have constraints and reporting systems. If they added simple programming constructs, it could be as powerful as you like. (e.g. google forms enables you to skip to different questions based on previous answers, though it's getting away from easy visualization, unlike spreadsheets). You can view them as being a database, derived from input forms - what's stopping them growing towards unmaintainable real databases, in the way that spreadsheets can grow into unmaintainable apps? A way to think about this is not in terms of a complex thing, but in terms of a simple thing... a toy... to which you can add-on complexity. e.g. I'm not sure that the first spreadsheets were fully programmable, but just related different cells by formula. And I know for sure that the first RDBs didn't have stored procedures. Maybe, this could be done for many webapps: wiki + scripts; reddit + scripts (what would that be?); youtube + scripts (we have it a little bit with links on parts of the video). The puzzle is imagining what could possibly be the use of these... it helps if you already have a manual version that you are automatic (that's what the visicalc guys did: "spreadsheets" existed, on paper, before them: http://inventors.about.com/library/weekly/aa010199.htm http://inventors.about.com/library/weekly/aa010199.htm). There's visual webapps for assembling webservices, but they don't seem to have taken off. Maybe the "problem" is that they scale - the thing you create is good for more than just one person, unlike most spreadsheet documents, which (excluding templates) contains your own specific data - often, proprietary business data. Because it can scale, people invest more effort in it, and are happy to use proper APIs etc. And then, consumers don't have an unsatisfied need, because it's already done. Therefore, perhaps the "toy" needs to be about a particular business or person (e.g. be about their data). Also: Arguably, Flash authoring tools took the place of hypercard.