LtU Forum

The broad ML Family workshop

It is not generally proper to post call-for-papers on LtU. Exceptions have been made, for broad workshops likely to appeal to many LtU readers. I hope the 2014 ML Family workshop also qualifies.

The ML Family workshop intends to attract the entire family of ML languages, whether related by blood to the original ML or not. Our slogan is ``Higher-order, Typed, Inferred, Strict''. Designers and users of the languages fitting the description have many issues in common, from data representation and garbage collection to fancy type system features. As an example, some form of type classes or implicits has been tried or been looked into in several languages of the broad ML family. We hope the ML Family workshop is a good forum to discuss these issues.

Also new this year is a category of submissions -- informed opinions -- to complement research presentation, experience reports and demos. We specifically invite arguments about language features, be they types, garbage collection, implicits or something else -- but the arguments must good and justified. Significant personal experience does count as justification, as do empirical studies or formal proofs. We would be delighted if language implementors or long-time serious users could tell, with examples from their long experience, what has worked out and what has not in their language.

The deadline for submitting an abstract of the presentation, up to 2 PDF pages, is in a month. Please consider submitting and attending!

Leslie Lamport: Thinking for Programmers

Recent Turing Award winner Leslie Lamport's talk at the Build 2014 Conference, Thinking for Programmers. I do wonder if the level of specification (thinking) Leslie recommends here is realistic/necessary in this day of apps, web pages, and mostly non-systems/non-critical programming mostly done by app developers with little to no formal education in mathematics or computer science.

"If you don't start off with a spec, every piece of code you write is a patch".

What do you think, when applied to the programming environments of today (apps, web pages, non-critical systems, etc...). Does it go too far to assume this level of thinking?

Modelling Actors with Locks

It appears that too many developers do not understand actors, and that actors have not been explained very well. My thought is that a model that behaves, to a degree, like actors might go a long way to explaining actors through analogy, especially if that model can be implemented with a minimum of code. Mind, the model is only an approximation. But even so, you may find it interesting/informative.

more

HyperCard and PL as powerful but hard to use interface

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# compiler, library and tools now open for community contribution

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

Unreal Blueprints Visual Scripting

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

Future of Programming workshop

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

The theory behind the Terms language

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

Toward a better programming

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

using words and notation in domain specific language syntax

I face the following dilemma:
  • 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
I would like to hear your opinion on this, with literature pointers when possible.
XML feed