Home

Back to the future

TileStack is an attempt to resurrect HyperCard and bring it to the web.

Running online there are going to be limitations about which stacks can be ported, which may reduce the usefulness and impact of this project, but maybe a standalone version will come later.

The system compiles Speak (the TileStack version of HyperTalk) to Javascript. If the result is not obfuscated, something I haven't verified, it may be possible to augment the output from TileStack with additional capabilities not supported or not yet implemented.

From the compatibility angle it is interesting to note that they renamed the language and seem to imply they are going to extend it beyond HyperTalk, without giving any specific guarantee about future compatibility. I'd suggest releasing the compiler that's as close to full HyperTalk compatibility as a separate product (or even, if they can bring themselves to do it, releasing it as open source).

By Ehud Lamm at 2008-06-08 18:27 | DSL | History | Javascript | other blogs | 19562 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

time travel trends

I was really pleased to see the story on TileStack at Hacker News and Slashdot, but the former had little or no commentary and the latter had only cursory comments. (Including for example someone asking, what's a Hypercard?)

It'd be nice to see a HyperCard related space develop a little. The TileStack website tethered model doesn't appeal much, but beggars can't be choosers — I'd rather see that than nothing at all about HyperCard.

The part I find most interesting (the same idea I've been leaning toward) is that translating from one language to another for execution doesn't change things a lot. Given one Turing complete language you can simulate most of an app written in another. So it seems productive to explore some syntax agnostic software aiming to emit different syntaxes depending on the target execution environment.

I'd expect extensions beyond HyperTalk — limiting yourself to a specific repertoire is limiting when you think of other new things to do.

I'm assuming TileSpeak doesn't support HyperCard's editing modes, where you can open any UI object to see the script inside written in HyperTalk. It'd be cool if it did though.

By Rys McCusker at Sun, 2008-06-08 23:06 | login or register to post comments

it seems productive to

it seems productive to explore some syntax agnostic software aiming to emit different syntaxes depending on the target execution environment.

I think this idea occurred to many, in various contexts. The results were not impressive (unless one counts intermediate languages and VMs). The reason would seem to be that translation of the sort discussed here is too vague a term. If translation requires more than just local transformation, the semantic mismatch may be too large to simply dismiss under the heading of Turing completeness.

By Ehud Lamm at Mon, 2008-06-09 18:47 | login or register to post comments

On my mind

If one were to set aside the issue that such things have been attempted before and have sorta been painful (random small example)... And setting aside that I don't have any real experience with this other than doing some projects for my old CS classes (prolog-in-ml kind of homework assignments)... What could be a core language that is as agnostic as possible and lets you build common constructs on top, where "common" would be: Java, C#, and ECMAScripts? If the portable language was kept kernel-like enough, and if programs written in it were simple enough, it could be fun? Currently I think really what I want to do is make a DSL that is ported to each of those languages. If there is a way to have an intermediate language between the DSL and the host languages, then that could reduce the porting effort?

By raould at Mon, 2008-06-09 19:05 | login or register to post comments

enabling translation

Your remarks are very appropriate and pertinent. I hope my long response's size doesn't read even slightly as disagreement.

Ehud Lamm: I think this idea occurred to many, in various contexts.

Yes it's a common meme. I only meant to say I actively favor it lately — slightly contrarian when common sense is translation seldom works perfectly.

The results were not impressive (unless one counts intermediate languages and VMs). The reason would seem to be that translation of the sort discussed here is too vague a term.

I agree I was too vague tossing off "translation" as explanation in a word. I did expect intermediate languages and VMs as the context. I'd normally never expect translating from one language to another to work without hitch.

The case I expect to work — given a lot of elbow grease — is defining the way an app works as a kind of virtual machine itself. Then this app machine can be rendered in more than one programming language, provided you also have a description of expected behavior you can translate without loss to a target language.

When an app is specified only by code in one language, I don't think there's any general way to automatically translate to another language, because that presumes you can tell what the original code meant to do, and that's not feasible. But if you specify the original app as well as a specific translation to one language, you can expect to translate your work to another language as well.

In other words, I'd only expect translation to work when you set it up beforehand specifically for that. In the context of TileSpeak I think it's only easy to translate HyperTalk to another language because HyperCard's behavior is somewhat underspecified, and HyperTalk isn't complex, with few features. Writing a HyperCard stack simulator doesn't sound daunting if you can disregard the original UI completely and substitute something like web page behavior, cutting any corner you please.

(Also, it doesn't hurt that machines today have orders of magnitude more processing power and resources than when HyperCard stacks were created, so it's trivial now to absorb the costs of inefficient translation of an app that had to run in very constrained runtime circumstances.)

If translation requires more than just local transformation, the semantic mismatch may be too large to simply dismiss under the heading of Turing completeness.

By Turing completeness (TCness) I meant you could expect to write a general simulator for an app machine. So if your app's machine-like behavior was specified in a way letting you translate it to one TC language, you could also translate it to another. But I'd expect the simulator to be different in each case, so the translations might not resemble each other.

I wouldn't expect support for any new TC language to be automatic either in translation or writing the base engine's simulator. You'd have to do each by hand, and have language implementer skills each time.

I think if you didn't support more than one target language from the beginning, you'd tend to drift toward feature usage tied to one language as a preferred one in execution. Translation should be baked in from the start.

By Rys McCusker at Mon, 2008-06-09 22:12 | login or register to post comments

intermediate language

Seems to me like the UI interaction provides one important layer of translation, mapping widgets from one domain to another could be automated, but the backend workings are another territory altogether.
It would be intersting to have a syntax reduction process, translating one language to a more structural translation language that could be then expanded back into other working languages. I like the idea that the developer might add hints that help this.
Is XSLT good for the last bit of expanding into platform languages?

By random at Wed, 2008-06-11 06:05 | login or register to post comments