Lambda the Ultimate

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?

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.