Watch Your Language

Domain Specific Languages book

Martin Fowler’s DSL book

Interesting to see a theme emerge in my Pinboard account this week — lots of stuff about the idea of ‘programming language’. I’ve spent the last few weeks preparing to dive back into a personal interactive music project that I’ve been working on sporadically since I was in graduate school. I had recently realized that the conceptual roadblock I hit before my last hiatus was something that I’d need to address by adding some sort of little programming language into the system. After following Martin Fowler’s many blog posts over the years discussing domain specific languages, I finally broke down and bought his book on the topic. It’s too early yet for me to have much concrete to say about the book, but I remember getting enough out of those blog posts to be confident that it will be worth the money and time to read.

At the same time, these pertinent posts came through my feeds:

False Cognates and Syntax

So what is a false cognate? Well consider your reaction if I held something out to you and said, “Gift?” Would you thank me or politely demur? Would your reaction change if you knew I was speaking German? (For those not in on the joke, “gift” in English is a synonym for “present” while in German “Gift” is “poison”.) The confusion of poison for present is an example of a false cognate. In natural language, especially in related languages, false cognates abound.

Interesting and important thoughts on languages borrowing from each other in deeply confusing ways. The note on Erlang’s use of

if

is especially notable, considering how little concern there seems to have been given to making Erlang’s syntax look inviting and comfortable.

Socio-PLT: Principles for Programming Language Adoption

This paper presents a survey for programming language adoption principles drawn from various sociological fields. For example, many programming language features provide benefits that programmers cannot directly and immediately observe and therefore may not find compelling. From clean water to safe sex, the health community has long examined how to surmount similar observability barriers. We discuss how principles and techniques drawn from social sciences such as economics, public health, and historical linguistics relate to programming languages. Finally, we examine implications of our approach, such as for the design space of language features and even the expectations of scientific research into programming languages.

In related news, our grandchildren will still be listening to LISP advocates predicting that the whole world is about to finally understand the beauty and necessity of programming in LISP. They’ll also still be arguing about whether or not Scheme should be considered a dialect of LISP.

Less is exponentially more

Rob Pike from Google talking about patterns of adoption of the Go language, and some thoughts behind the primary design philosophy of the language.

Python and Ruby programmers come to Go because they don’t have to surrender much expressiveness, but gain performance and get to play with concurrency.

C++ programmers don’t come to Go because they have fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it. To them, software isn’t just about getting the job done, it’s about doing it a certain way.

The issue, then, is that Go’s success would contradict their world view.

And we should have realized that from the beginning. People who are excited about C++11’s new features are not going to care about a language that has so much less.  Even if, in the end, it offers so much more.

Friday Linked List (06/01/12)

Three cheers and a tiger for me — today is my 15th anniversary with Art & Logic, and in lieu of a party I’ve decided to dump some links that have collected in my pinboard account:

First, two different blog posts discussing ideas about user interface design. For me, these two posts have been shifting back and forth between agreeing with each other and disagreeing with each other, like an optical illusion.

Joshua Porter (no relation) gives 20 Principles of User Interface Design. Very clean, very sensible.

…but on the other hand, the always-worth-reading Rands looks to the techniques of progressive disclosure and hypothesis-driven learning that are used in games as a guide to user interface design.

Game designers have a different set of incentives to make their tools easier to learn via sandbox and atomically chunked learning. They may obsessively play test their games looking for user frustration earlier, but whether you’re leaping through a portal or creating masks of transparent elements in Photoshop, both use cases strive for a moment where you can cleverly and unexpected solve a seemingly impossible problem on your own.

Game designers and application designers might exist in different universes, but there is no reason one universe can’t teach the other.

Another list-based link from The Twelve-Factor App:

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

I’ve certainly seen a lot of projects going through various degrees of pain that could have been reduced or eliminated had they implemented these ideas.

Lastly — Blockly:

What is Blockly?

A new programming language made up of “blocks” that look like jigsaw puzzle pieces.

What do I use Blockly for?

First, a programmer needs to integrate Blockly with a web application, like Gmail or Google Docs, that you already use. Then you can use Blockly to write simple programs like macros and scripts that work with the web application.

For example, in Gmail, you can use Blockly to create email filters that do things like, “If Bob emails me three times in less than an hour, and each email contains the word ‘deadline’, delete all his emails except the first one.”

The image at the top of this post is a quick thing I threw together with their Blockly demo. Took me about 5 minutes (where I could have written and tested it in Python in much less). On the other hand, it’s very close to the programming interface used by MIT’s Scratch, which my kids both enjoyed using when they were little. It might prove to be a very easy and useful way to add end-user programmability to a system at some point. Their ‘Code’ demo lets you create a program with the Blockly editor and then export it to working code in any of JavaScript, Dart, Python, or XML.