Lambda the Ultimate

F# is the first MS language to go open source. The F# team is now going further into the Open World to allow community contributions to the core language, library and tool set. This means the F# team will now take pull requests :)

From a recent blog post on the topic:

"Prior to today (April 3, 2014), contributions were not accepted to the core implementation of the F# language. From today, we are enabling the community to contribute to the F# language, library and tools, and to the Visual F# Tools themselves, while maintaining the integrity and unity of the F# language itself.

In more detail:
•Contributions can now be made to the core F# compiler, library and tools implementation.
•Proposed changes will be rigorously moderated by ourselves and other community contributors from Microsoft Research and the F# community.
•The full tests for the F# compiler and library are now available.
•In time, the full source code and test suite for the Visual F# Tools will be made available."

In the past few months I've thought about HyperCard some, in the context of an app that would use a high granularity fiber-VM implemented with coroutines as continuations. Imagining fiction-based docs about such a VM, I supposed one character might decide "I want to clone HyperCard" and then look at issues from that perspective. One reason this is interesting is because HyperCard downplayed exactly what happened in terms of time-order when events were processed: objects executed HyperTalk scripts in response to event stimulus like mouseUp, and other events. In principle these might run in parallel with each other — except Mac apps at the time rarely exposed concurrent semantics, and no way to coordinate via locks to avoid interference was provided in the language.

(I see a daemon-based implementation, with the UI in another process that is just viewer, frontend, and editor, so you can expose both a browser interface and native widget app UI at the same time for the same daemon runtime. This would include remote shell connections to run scripts in the daemon the same way you could run commands in HyperCard from a little message dialog box. The main disadvantage with this model is that you can write really unpleasant things with it, like distributed fork bombs, that you can't stop end users from deploying. In other words, it would be easy to be evil, which gives me moral qualms. The last time I said this to a coworker months ago, he said what people do with tools I write is not my problem.)

As an excuse to talk about HyperCard, I'm using a Hacker News discussion to source an interesting remark from Programming Languages are the Least Usable, but Most Powerful User Interfaces (uw.edu) (Andrew Ko).

In the top comment as of this moment, HN user jasonwatkinspdx supposes:

If the hypercard model had the value I think it does, someone else should have surfaced and gained momentum.

I especially like suppositional reasoning, so this sort of remark is one I enjoy. A reply I have in mind writing here (if anyone likes this topic) has at least two parts: 1) what would happen if someone deployed an updated HyperCard style tool, and 2) how folks pursue options in tech that yield max personal advantage rather than intrinsically useful basic infrastructure.

Unless someone does so first, later I'll quote a paragraph from Andrew Ko's original piece: the part about value of text programming languages in contrast with graphical user interfaces. I want to keep this first post short, as a seed for discussion, if any. I'm more interested in the programming language angle — how does a runtime behave and how does this model appear in the language — than I am in the business model of an app, which is off topic here. Also completely on topic is Andrew Ko's original blog post (same as the HN link above).