[OT}] Hypercard and an uneasy read.
Björnke von Gierke
bvg at mac.com
Fri Dec 2 09:02:37 EST 2011
People who wrote in this thread about why HC was killed are all self centric conspiracy lunatics. Apple was considered dying, bleeding money left and right, and everyone just waited for Jobs to be a megalomaniac idiot and kill the company off ungracefully by what was considered a flawed personality, an outdated idea of what computing is and a bound to fail management style.
But of course Jobs did what he does best: Concentrate on a single project (the iMac & what became Mac OS X), getting ridiculed for it ("only USB? Lickable UI? Not cheap as ad-supported Walmart PC? Jobs is an idiot!"), and then making huge profit from the non-corporate customer market.
Now this concentration on a single task was of course detrimental to a lot of projects, including fancy and forward looking Xerox-lab styled ideas like HyperCard and the Newton, as well as silly stuff like the gazillion Performa models. No one is making up stories that Jobs killed the Performa branding, because his fruity employees disliked the grey colorisation or some shit like that.
All those projects where sucking up money, the only thing Apple didn't have at that time, so they had to die. And yes, some good Products died in those years, but even more bad ones got shafted. This simple and economically sound decision had almost nothing to do with internal strifes, dislikes or philosophic/ideologic "what is the future of computing" reasons.
So a positive account balance saved Apple. After that, Jobs (and in extension Apple) never tried to do world changing research like OpenDoc again, instead focusing on polish over far out features and philosophically approaches to changing the computing landscape. This is most obvious with products like the Mac OS X Finder, who is in many ways a copy of existing concepts, and actively tries to avoid changing the way we use computers.
On 2 Dec 2011, at 05:15, dunbarx at aol.com wrote:
> I had always thought that it was the developers who successfully lobbied against HC. It was feared that sales of shrink wrapped software in general would suffer if a large population of users could roll their own solutions. No need for filemaker or excel.
> Craig Newman
> -----Original Message-----
> From: Todd Geist <todd at geistinteractive.com>
> To: How to use LiveCode <use-livecode at lists.runrev.com>
> Sent: Thu, Dec 1, 2011 3:17 pm
> Subject: Re: [OT}] Hypercard and an uneasy read.
> Hi Bob,
> The part that I most liked about the linked article was the emphasis on
> explorability. I think HyperCard had it. My other Tool FileMaker had it.
> FileMaker has less of it today. And I think that LiveCode is not as
> explorable as HyperCard was. In the case of LiveCode it nows support 7
> platforms instead of one. This adds a lot of complexity, but I am not sure
> I would trade that away.
> I will say this that LiveCode and FileMaker both remain two of the most
> traditionally sucked in this regard although recently that has changed with
> the rise of Jquery and other JS libraries. Still I defy anyone who has not
> done it before to create a simple form with HTML/CSS and JS, I don't care
> what IDE they use, they won't be able to do it. But give some body a
> LiveCode Stack or a FileMaker DB and they might be able to pull it off.
> They can explore their way there.
> Thats what I love about Explorability.
> But your other point about a solution not being simpler than the problem it
> is meant to solve. I understand what you mean. But if that were true then
> there wouldn't be much advancement in technology. I think that
> breakthroughs in technology are really about taking a complex problem and
> making it simpler. The best solutions are the simplest ones.
> "Any intelligent fool can make things bigger and more complex... It takes a
> touch of genius - and a lot of courage to move in the opposite direction."
> - Albert Einstein
> On Thu, Dec 1, 2011 at 3:37 PM, Bob Sneidar <bobs at twft.com> wrote:
>> Hi Todd. Let me propose that a solution cannot be simpler than the problem
>> it is meant to solve. People who think so are usually only imagining how
>> simple the solution can be. When they actually get in and try to solve it,
>> they find a world of complexity that was hiding behind their imaginations.
>> Every serious developer finds this to be true eventually. That was my
>> problem when I first started using Livecode. Coming from Hypercard, I
>> thought, "Oh I know how to do that!" But I had to relearn a lot, and some
>> things I had to learn from scratch, and I am still learning every day!
>> Livecode is to me like a constructor set of pieces of things you can put
>> together to make something, rather than a toolchest full of tools to make
>> something. You can see the advantages and disadvantages of each approach.
>> With a constructor set, parts are already prefabbed, and a system is worked
>> out for how the pieces all fit together. You don't have to go get raw
>> materials to work with, all that has been done for you. You just have to
>> decide what you want to make, and if the parts all exist to be successful.
>> But what you are going to end up with is no where near as elegant as you
>> might have envisioned, nor will it be as functional, especially the more
>> complex your project. But putting something together that is useful and
>> even fairly complex is MUCH FASTER!
>> The toolchest approach means you have to make each part yourself, from the
>> ground up. Perhaps you can adapt to pieces others have built already,
>> (API's, libraries etc) but essentially, everything has to be manufactured
>> all by keeping in mind a very precise plan for how it will all fit and work
>> together. LOT more planning is required, as well as a fairly refined
>> skillset and a level of expertise that much fewer people have. And it is
>> going to take a LOT more time, probably more than any one person really
>> wants to spend, so you will probably have to enlist help for more complex
>> projects, and they will have to be experienced to some degree as well.
>> In the end it comes down to this: There are a huge number of people, that
>> if convinced there is a software "constructor set" advanced enough and yet
>> simple enough that they could make a customized app they really need for a
>> minimal investment in time, learning and money, they would jump at the
>> opportunity. We need to find those people. Neither the constructor set
>> project, nor the toolchest project is going to build itself. And for my
>> part, I know for a fact that I do not have the time to become proficient
>> with the toolchests of today (Java, C++ Objective C) to ever get to the
>> place where I can even begin to build something approaching useful.
>> So I would rather work with the mystery knobs, because those I can figure
>> out and then it won't be a mystery anymore. But the huge store of black
>> magic behind the door that is Java, C++ and Objective C I will never grasp,
>> and really don't want to. My 2¢
>> On Dec 1, 2011, at 12:23 PM, Todd Geist wrote:
>>> LiveCode has an awful lot of Mystery Knobs.
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> Todd Geist
> (805) 419-9382
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
Watch live presentations every Saturday:
Use an alternative Dictionary viewer:
Chat with other RunRev developers:
More information about the Use-livecode