Lambda the Ultimate

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).

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."

Blueprints enable anyone to rapidly prototype and build playable content without touching a line of code. Use Blueprints to author level, object and gameplay behaviors, modify user interface, adjust input controls

WHAT CAN YOU DO WITH BLUEPRINT?

Tutorial Videos

Edit:

I've had the opportunity to use UE-4 for a few months and I can report a little more information:

The Blueprint runtime is currently implemented with an interpreter written in C++ - and so probably 1 or 2 orders of magnitude slower than C++. From what I can tell it wouldn't be too hard to generate C++ source code as an alternative, however, since the type system is essentially a subset of C++.

One-shot continuations, i.e Futures are supported (Unreal calls these "Latent actions"), which however have to be implemented in C++. The overall nomenclature is sadly C-like. They distinguish Blueprint "Functions" and "Macros". It seems Functions are callable from C++ and must return synchronously (can't contain "latent actions"), whereas Macros can only be called from their interpreter.

The Unreal Editor is almost certainly the coolest IDE every created. The blueprint editor itself is pretty cool, and is stable and usable (I haven't lost any work yet). Blueprint debugging, breakpoints, and watchpoints work. Auto-completion works well. Type-checking is decent - errors are placed on nodes in the graph as well as listed. Searching and navigation (find references) and refactoring (renaming) works reasonably well.

Although they don't have first class sum types, they do generate graphical "switch on X" nodes for C++ enumerations (which again have to be defined in C++ and with additional preprocessor boilerplate), which have outputs for each alternative. In addition, they have a "switch on String" node to which you can add cases in the editor. For product types, which are C++ structs that you must annotate with additional preprocessor boilerplate, they generate "break struct" nodes which have outputs for each factor.

Higher-order functions aren't supported. Concurrency aspects seem to be undocumented but the reality is obvious - blueprints aren't thread-safe and everything must occur on the main thread. Generics aren't supported in general in blueprints, however they are supported for arrays - which correspond to the Unreal C++ class template TArray<>.

The call for submissions is out. There will be two opportunities this first year to participate: at Strangeloop in September and at SPLASH in October. The call:

We are holding two events. First, in partnership with the Emerging Languages Camp, FPW×ELC will be at Strange Loop on September 17 in St. Louis MO. Second, at SPLASH in Portland OR around Oct. 19 (pending approval).

We want to build a community of researchers and practitioners exploring the frontiers of programming. We are looking for new ideas that could radically improve the practice of programming. Ideas too embryonic for an academic paper yet developed enough to demonstrate a prototype. Show us your stuff!

FPW×ELC will present live demonstrations before an audience. The SPLASH event will be an intense, private writer’s workshop1,2. This process will be a chance to give and take both creative support and incisive criticism.

Submissions will be 15 minute demo screencasts. You can select either or both of the events in your submission. The submission deadline is June 8 and notifications will be sent June 27. After the events participants will have until December 1 to revise their screencasts for archival publication on our website. The submission site is now open. For questions please see the FAQ or ask info@future-programming.org.

Brought to you by Richard Gabriel, Alex Payne, and Jonathan Edwards.

This is a good idea for the more edgy language designers to exhibit their work and receive useful critique to improve presentation, which ultimately helps with our goal of world domination (or at least, pushing the community to take more risks).

Hi,

I would like to present to you a programming language I have developed. Reading through your getting started page, I can see that the focus in this forum is category and type theory, etc. I am not an expert, but I understand what these are about.

What I propose, however, is not in that sort of direction; it is academically quite unrelated. Its end result, though, is an implemented, working programming language [1], that I believe can be useful for certain problems, and that's the reason I address you here with it.

What I would like you to read and comment is a brief explanation of the theoretical foundation of this programming system [2]. I would really appreciate any comment.

I am not sure if my approach is original, and I am also not sure whether my conviction that this approach is useful is just a delusion.

This is not the first time I try to show this work in this forum. The first time there was some discussion, but it didn't get to the point I am trying to make. I have tried to be more to the point this time.

Thanks in advance

1.- https://github.com/enriquepablo/terms
2.- http://terms.readthedocs.org/en/latest/theory.html

I wrote a blog post for my talk from Strange Loop 2013 about the framework I've come up with for describing what's wrong with programming and how we might go about fixing it. Here's an excerpt:

The other day, I came to the conclusion that the act of writing software is actually antagonistic all on its own. Arcane languages, cryptic errors, mostly missing (or at best, scattered) documentation - it's like someone is deliberately trying to screw with you, sitting in some Truman Show-like control room pointing and laughing behind the scenes. At some level, it's masochistic, but we do it because it gives us an incredible opportunity to shape our world. With a definition for what programming is and a concrete understanding of what's wrong with it, we have a framework for capturing that opportunity and removing the rest. But in order to do so, we can't just bolt it on to what we have now. Another layer of abstraction won't be enough. Instead, we have to address these fundamental problems at the very foundation of our solution. No more teacups and no more compromises.

Read the full post here

• it is easier to remember keywords in a language, but there can be a confusion when people take their meaning from plain English. Also, such a language might be wordy like Cobol
• Symbolic identifiers make expressions shorter but they might become cryptic and this refutes the whole purpose of a domain specific language, namely, that a domain expert with less experience with a general programming language can read it without effort

To appear in Onward! 2014; abstract:

Most languages expose to programmers the computer’s ability to update memory at any time. But just as many languages now manage memory to unburden us from properly freeing memory, they should also manage time to unburden us from properly ordering updates to memory. Change then becomes human comprehensible: writes are seen by all affected reads, easing many programming tasks related to initialization, reactivity, and concurrency, and so on. Perceptible steady feedback is also provided on how code edits affect program execution as live programming. We propose time management as a general language feature to relate prior work and guide research into this unexplored design space.

We introduce Glitch as a form of managed time that replays code for an appearance of simultaneous state updates, avoiding the need for manual order. The key to such replay reaching a consistent program state is the ability to reorder and rollback state updates as needed, restricting the imperative model but still being quite expressive. Glitch is fully live: program executions can be replayed in an IDE and are incrementally revised under arbitrary code changes.

Written with Jonathan Edwards and heavily inspired by his blog post; there might have been a few LtU posts on this subject in the past also.

Also, if reading a paper isn't your thing, check out the essay + videos companion.

[Folks, This came across the CODE4LIB email list, along with a "feel free to share" not. LTU came to mind immediately. FYI, ALA is the American Library Association - they published a book of mine maybe 15 years ago, and they were great folks to work with. It's been a while, but the guy who as my acquisitions editor is now their Sr. Editor - so I expect their still good to work with.]

This is a call for book chapters for A Librarian’s Introduction to
Programming Languages to be published by ALA/Neal-Schuman Publishing.

This book will look at a variety of programming languages with the intent
to familiarize readers with the reasons for using each language. The book
will cover practical, real world examples to illustrate how a specific
language can be used to enhance library services and resources.

The target audience includes current practitioners, administrators,
educators, and students.

Some potential topics to be included in the book are below.

● Basic
● C#
● Java
● Javascript
● Perl
● Python
● Ruby

We are also interested in other topics. For more information email the
editors:
Ron Brown ronbrown@sc.edu and Beth Thomsett-Scott
beth.thomsett-scott@unt.edu

The problem is that actors do not always process messages in the order received, but may limit processing to selected messages based on their current state. This technique is often used when waiting for a response from another actor. Clearly this can lead to something like deadlock where several actors freeze up, even though no locks are used.

JActor takes a different tack. Messages are processed in the order received, but messages are mostly 2-way and are first class objects with each message only being used once. This means that while processing a message, it can be a place to save intermediate state. So if processing involves sending messages to other actors, there is no need to update the actor's state until message processing is complete.

Another difference is that when a message is returned as a response, it is dispatched differently from other messages. When a message is first sent, it serves as a request and is assigned a callback that will be used when the message is returned with a response value. But note that actors process messages one at a time as a means of thread safety, and this applies as well to the invocation of the callback when processing a response.

This is covered in a lot more detail in the JActor project README.