Rép : [OT}] Hypercard and an uneasy read.

Pierre Sahores sc at sahores-conseil.com
Fri Dec 2 08:32:19 EST 2011


Among the comments of this interesting "http://www.loper-os.org/?p=568" paper..., 


Phillip says: November 30, 2011 at 4:49 pm

It was killed because Hypercard on an iPod is all you would ever need to buy.
How do you spell APP Store killer? HYPERCARD.


BC says: December 1, 2011 at 12:06 pm

"Yes, I know why HyperCard was allowed to “die”. With all respect to Mr. Jobs, HyperCard was considered a cancer and was put through executive nuclear-chemo therapy."


PS : ... and Larry Ellison killed Oracle Media Objects in the mean time to "faire place nette" to Java...


David Stevens says: December 1, 2011 at 3:10 pm

A likely reason for it’s death is simple that most people do not want to program, and have no desire for programming. While I enjoy programming, and have been at it for quite some time, most people are looking for something they can use, not something they can use to make something they can use."


Peter M. Brigham says: December 1, 2011 at 11:44 pm

"It’s the do-it-yourself aspect of HC that made it uniquely useful as a tool for real people doing myriads of (non-IT) jobs. Its descendants, LiveCode, Supercard, Metacard, etc., carry on the tradition."


1.- Where anyone can't freely read and write by it self, the social power is driven by professional public and private "scribes" willings and soldiers arms. Traditional programming occurs mainly as the scribing paradigm of the first age of the computer's enabled world. XTalk owns a good place to represent the semantically empowered IDE RAD what can make people free to understand, read and write the second age of our computer's enabled little finished planet. Can we get part of the work done to empower this around-the-corner century knowledge freedom objective ?

2.- Hypertalk gave us the opportunity to understand that programming is, before any else, the art to convert abstract minding in automated workflows and in this way, i just follow the mind witch let some of us think that the computer expand our ability to "reduce complexity to its elegant working solution". Alike Bob, i think that the computer don't do the work for us and alike Todd, i think that the computer is the accessory and the mirror witch help us to clear the complexity in a collection of elementary components we need to take hand on and manage to build the final response (soft) to the workflow we need to build to solve the initial defined customer's need.

3.- When we write a GUI application in using LiveCode, most of the code behind the GUI is mainly automatically build for us by the framework while the application's logic depends entirely from our design skills and methodology. When we write a frontless app (say a LiveCode server or cgi app), we have to write 100% of the app logic. If we compare the wight of the source and binary codes, we can see that in the GUI driven app, as an example, the source is about 250 ko and the final standalone binary code (without the 3.5 Mb of runtime engine) will represent a wight about 1 Mb. So while we had to code 250 ko of source, LC provided us 750 ko in automated mode. On the other hand, LiveCode let us entirely free about the ways and responsibility to code the app logic without no far from any restriction nor automated assistance. If we go back to compare LC to HC, we can, today, do lots more in about technical market enabled solutions than we ever could do with HC + Rinaldi XFCN/XCMD in a lot's more usable way and HC was only more easy to learn than LC as long as we did't have to deal with X-command / functions at all. 

2cts ;-)
--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com







More information about the Use-livecode mailing list