Random Stuff Stefan Tilkov’s Weblog

There have been some (some? rather a few million) interesting posts regarding Apple's iPad. One worth reading in its entirety is Aristotle Pagaltzis's, from which I quote:

But how would the fundamental experience of the device suffer if Apple shipped a dev environment with the iPad, just like one used to be part of every home computer (incl. the Apple II)? Is that really an inconceivable proposition? Or heck, it could be a $20 download on the App Store for all I care. That’s no hurdle for a teenager, not even a big one for a preteen. Why must the iPad require a dev licence and a Mac to write code for? (Obviously: because that makes Apple a lot of money.)

Anybody can build a development environment for the iPad/iPhone, this seems to be just a matter of enough commercial interest or enough open source enthusiasts to combine their forces. The real problem is the fact that the only way to get software onto an iPad is through the AppStore. I don't even believe it should be Apple who address the development environment aspect; I'm pretty sure that there'd be a great option for somebody else to build an awesome environment, perhaps based on a modern dynamic language, and this could be hosted on any platform to produce applications for the iPad. But you wouldn't be able to install the development environment itself to the iPad, as the AppStore approval policy explicitly forbids installation of any sort of interpreter, nor could you install applications built with it unless they go through the AppStore.

Apple's reasons for insisting on the AppStore as the only delivery method are understandable from a commercial point of view, at least for now. But ultimately, they'll harm both the users and Apple itself – which makes me pretty sure this will change – who knows, maybe even the first generation of the iPad OS will allow the user to install applications via some other means than the AppStore. My guess is that Apple will wait until they have a very firm position, similar to the way the dropped DRM from iTunes music once they no longer had to rely on it.

Until then, at least there's the set of interpreters built into Mobile Safari …

One line of reasoning that I don't really buy into, though, is the one related to "tinkering". As Alex Payne writes:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

I have some sympathy for these feelings because I have similar personal experience. But the whole things smells a little like complaining about not being able to tinker with your car anymore. The level of detailed fiddling you can do with any sort of device that becomes mainstream has been going down steadily – while my grandfather probably could have repaired a mild engine damage without too many problems, I'm pretty sure not too many people do this anymore today. I believe it's fine to be able to tinker on a totally different level, even if it's in the form of Web apps that run locally. The hypothetical development environment on the iPad – can you imagine what kind of Scratch one could build? – would be more than enough of a compensation from my point of view.

The feeling I understand not at all, though, is the one expressed by Tim Bray:

It’s probably a pretty sweet tool for consuming media, even given the unfortunate 4:3 aspect ratio. And consuming media is obviously a big deal for a whole lot of people.

For creative people, this device is nothing.

Given the fact that I expect there to be millions of people who'll use an iPad to write, and paint, and sketch, using a multitude of applications built for the purpose, I beg to disagree.

Call for Papers for WS-REST 2010, Paper Submission Deadline: February 8, 2010

Call for Papers

The First International Workshop on RESTful Design (WS-REST 2010) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.

Background

Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.

This first edition of WS-REST, co-located with the WWW2010 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:

• Applications of the REST architectural style to novel domains
• Design Patterns and Anti-Patterns for RESTful services
• RESTful service composition
• Inverted REST (REST for push events)
• Integration of Pub/Sub with REST
• Performance and QoS Evaluations of RESTful services
• REST compliant transaction models
• Mashups
• Frameworks and toolkits for RESTful service implementations
• Frameworks and toolkits for RESTful service consumption
• Modeling RESTful services
• Resource Design and Granularity
• Evolution of RESTful services
• Versioning and Extension of REST APIs
• HTTP extensions and replacements
• REST compliant protocols beyond HTTP
• Multi-Protocol REST (REST architectures across protocols)

All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on "lessons learned" rather than describing an implementation.

Papers must be submitted electronically in PDF format. Submit at the WS-REST 2010 EasyChair installation.

Important Dates

• Submission deadline: February 8, 2010, 23.59 Hawaii time
• Notification of acceptance: March 1, 2010
• Camera-ready versions of accepted papers: March 14, 2010
• WS-REST 2010 Workshop: April 26, 2010

Program Committee Chairs

• Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
• Erik Wilde, School of Information, UC Berkeley, USA
• Alexandros Marinos, Faculty of Engineering & Physical Sciences, University of Surrey, UK

Program Committee

• Rosa Alarcon, Pontificia Universidad Catolica de Chile
• Subbu Allamaraju, Yahoo Inc., USA
• Tim Bray, Sun Microsystems, USA
• Bill Burke, Red Hat, USA
• Benjamin Carlyle, Australia
• Stuart Charlton, Elastra, USA
• Joe Gregorio, Google, USA
• Michael Hausenblas, DERI, Ireland
• Rohit Khare, 4K Associates, USA
• Frank Leymann, University of Stuttgart, Germany
• Mark Nottingham, Yahoo Inc., Australia
• Aristotle Pagaltzis, Germany
• Ian Robinson, Thoughtworks, USA
• Richard Taylor, UC Irvine, USA
• Stefan Tilkov, innoQ, Germany
• Steve Vinoski, Verivue, USA
• Jim Webber, Thoughtworks, USA
• Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

WS-REST Web site: http://ws-rest.org/
WS-REST Email: chairs@ws-rest.org

Tim Bray has a very interesting post on enterprise development – check out the comments. I’ve said something like this there too, but like to elaborate a bit:

I strongly believe that building your own software is an essential ingredient for a successful, information-centric company such as a bank, an insurance company, or even a telco. I think it’s an excellent idea to use commodity services in all areas where you don’t have, nor want to have, any competitive advantages. But you should build something on your own if you want to innovate.

I also wrote that while it’s pretty fashionable to deride the claims that enterprise software is “inherently more complex” than much of the Web stuff, it is in fact true sometimes. One of the reasons is the absurd complexity of laws in some countries, and the rate in which more and more complexity is added to them. If you’re in a regulated business, this tends to create a huge amount of complexity you simply can’t escape from (unless you change the laws, or rather the whole legislative and political process, of course).

Another source of complexity is the business side, coming up with more and more complex product requirements. In many Web companies, there’s no difference between the business and technology decision makers – perfect “business/IT alignment”. This simply isn’t true in most large businesses. As a tech person, you have a choice of quitting or adapting to it …

I still agree that many of the practices, technologies and tools used on the Web can be put to excellent use within the enterprise. But even if you are given free choice of weapons in terms of tools and methodology, the typical constraints can ruin your day pretty soon.

Anyway, while I see some issues with Tim’s post, I still think there’s a lot of truth in it. Given that I spend most of my time in enterprise contexts, I strongly believe putting more of the Web into the enterprise is an excellent idea.

Kresten Krab Thorup:

For many years, I have been searching for what I call the "holy grail of concurrent programming." I have been looking for a set of abstractions as powerful as classes and objects which describes activities and their coordination. Just as was the case for the medieval quest for the holy grail, I am not alone. Many other researchers are searching for this. I remember that at the time when I started doing my Ph.D. in 1996, I was talking to Doug Lea about this subject; and he urged me to continue this line of thought. My thesis subject ended up going down another path, but the issue has persisted at the back of my mind, ready to jump up whenever I experienced new evidence that might guide me.

For the last couple of years I have been pursuing these issues more persistently; as chief editor of the JAOO and QCon conferences I have invited speakers that have something related to this on their hearts and mind, and the last six months - since working more intensively with the Erlang programming language - they have started to grow into a more consistent picture.

So here is a little essay and some ramblings on some of the things I have found out so far.

Excellent stuff.

January 26-28 we'll be at OOP in Munich again. I'll do a talk on "REST with Java", and we (innoQ) will have a booth in the exhibition area, too (more about some of the stuff we'll talk about later). Send me an e-mail if you want to schedule a meeting …

Wie Markus Völter schon ganz richtig schreibt:

Am 18./19. Februar findet in einem schönen Hotel in der Mitte Deutschlands (Details folgen :-)) eine zweitätige kleine Unconference (Open Space) rund um DSLs statt. Die Idee ist: miteinander reden, philosophieren, diskutieren, demonstrieren, coden, voneinander lernen - rund um DSLs, intern und extern. Also Dinge wie: Scala, Groovy, Ruby, Eclipse, MPS, Parser, etc.
Das ganze ist keine Schulung, jeder Teilnehmer muss etwas beitragen!

Wir organisieren das gemeinsam ohne kommerziellen Hintergedanken, d.h. die Kosten werden geteilt (wer mit 200-250 Euro pro Person kalkuliert, liegt wahrscheinlich nicht falsch).

Bei Interesse an einer Teilnahme bitte eine kurze Mail mit einem Beitragsvorschlag per E-Mail an Markus oder mich, Rückfragen gerne auch hier in den Kommentaren.

Tim Bray has put up an excellent set of theses on Clojure. I can agree with most of them, but wonder about the idea that "Lisp is a handicap".

I understand where Tim comes from, and I fully admit that even after playing with Lisp, Scheme and Clojure for quite some time, I'm still not sure whether this is really an issue. I would only feel qualified to really comment on it once I have used it on a real project with some complexity. But what I found interesting is the example Tim gives:

(apply merge-with +
  (pmap count-lines
    (partition-all *batch-size*
      (line-seq (reader filename)))))

I find this particular example to be extremely readable if you read it from the inside out - the reader function presumably returns a reader for the file named filename; line-seq returns a (lazy) sequence of the lines in the file, partition-all cuts this into segments (using *batch-size* as the, well, batch size), pmap maps the function count-lines over the result in parallel, returning a list of maps; finally, merge-with + combines all of the values for the same keys in the map by adding them. (Obviously the source code is much more understandable than my prose version.)

I agree there is a ton of Lisp code out there that's intimidating, but I don't see this as a good example. Let's invent a language with similar expressiveness, but more traditional syntax:

apply(mergeWith(plus),
  pmap(countLines, 
    partitionAll(BATCH_SIZE,
     lineSeq(reader(filename)))));

I can't see how this would be easier to read. It's not the syntax (at least not in this case) that might be a problem if you're not used to it, it's the style of using nested function invocations – which I believe is something you get used to really quickly if using any kind of language that supports functional idioms.

I enjoy Twitter, but I feel I'm missing something. Blogging forced me to spend a little more time on a subject – not as much as an writing an article does, and certainly way less than a book requires, but definitely more than what's needed to come up with 140 characters, 120 of which often end up being copied from somebody else.

So I'll try to update this place a little more often, even though the Web is probably littered with blogs that end up having famous last meta-entries like this one …

These are my unedited notes from Don Box & Amanda Laucher's talk about Codename "M": Language, Data, and Modeling, Oh My!

• [Don has promised not to tweet. That's a good start.]
• Interesting similarities btw/ M and MPS
• M is a language for data - one of the most interesting places of data is a sequence of Unicode code points
• Great support for text processing perceived as critical
• Example: extract some data from text - tweets
• Intellipad - default environment for writing grammar files, this is where tool support shows up first, then in Visual Studio

• M code for a language definition (a function from text to something else, declaratively specified):

  module QCon
  {
      language Simple
      {
          syntax Main = empty;
      }
  }
  

• Main is the rule that is the entry point

• Open file in three-pane (or rather, four-pane) mode
• Show source file, grammar, show output - empty file yields Main []
• Amanda makes a great assistant ;-)
• Non-empty file produces errors
• Change "empty" to "any" - file with a single character works, more than that produces errors; change to any+, validates again

• Simple language for interpreting tweets:

  module QCon
  {
      language Simple
      {
          syntax Main = Tweet;
          syntax Tweet = Content*;
          syntax Content
              = RawText
              | Handle
              | HashTag;
          token RawText = (any - ("#"|"@"))+
          token Handle = "@" Name;
          token HashTag = "#" Name;
          token Name = (any - ("@|"#"|" ""))+;
      }
  }
  

• regular expressions at the token layer, context-free grammar at the syntax level

• Amanda: "Only crap languages make you define something before you have to use it"
• Discussion betwen Josh, Amanda, Don about whether or not the grammar is correct
• Good point about interactive grammar development using the three-pane editor
• Pattern names used to display data in a structured way
• Adding @Classification["Keyword"] syntax-colors the source
• M is structurally typed
• M consists of lists and records
• Generating the right-hand side:
• Intellipad crashes! [Boom!] :-)
• The spec for M is licensed under the Microsoft OSP (which makes people as happy as they can be working with Microsoft)
• Javascript-based implementation of parts of the language; subset of the three-pane mode
• Toolchain is written in C#, parser written in M, more and more compilers written in M

• Intellipad crashes! Again! [Boom!] :-)

  module QCon
  {
      language Simple
      {
          syntax Main = v:Tweet => v;
          syntax Tweet = v:Content* => v;
          syntax Content
              = v:RawText => v
              | v:Handle => v
              | v:HashTag => v;
          token RawText = (any - ("#"|"@"))+
          token Handle = "@" v:Name => v;
          token HashTag = "#" v:Name => v;
          token Name = (any - ("@|"#"|" ""))+;
      }
  }
  

• bubbles up the actual content, result is just a list of the strings extracted

  module QCon
  {
      language Simple
      {
          syntax Main = v:Tweet => v;
          syntax Tweet = v:Content* => v;
          syntax Content
              = v:RawText => v
              | v:Handle => v
              | v:HashTag => v;
          token RawText = v:(any - ("#"|"@"))+ => { Kind => "RawText", Text => v }
          token Handle = "@" v:Name => { Kind => "Handle", Name => v };
          token HashTag = "#" v:Name => { Kind => "HashTag", Topic => v };
          token Name = (any - ("@|"#"|" ""))+;
      }
  }
  

• Question from Josh: Isn't this mixing lexing and production rules? Don: Goal is to have no difference, but it can be pulled out

• Next: Consuming stuff
• Using TDD to Don's tweets
• VS project includes language grammar defined earlier
• Amanda: Can one debug a grammar? Don: Answered later
• M runtime can be hosted inside a C# program
• Recently stopped internally to use .NET 3.5/VS 2008, now exclusively on .NET 4 and VS 2010
• Language defintion is included in the program binary

• Showing off some

  var language = Language.load(/* MImage */ typeof(Program).Assembly, "QCon", "Simple"); // yields runtime that can parse a program
  dynamic result = language.ParseString(input);
  bool hasHashTag = false;
  foreach (var content in result)
  {
      hasHashTag = content.Kind == "HashTag";
      if (hasHashTag)
          break;
  }
  AssertEqual(true, hashHashTag);
  

• Demo is actually working

• Change AssertEqual to Assert.IsTrue to get around exception thrown
• Question from Ian Robinson: Q. Can LINQ be used to walk the result? A. Not yet, as dyamic and LINQ don't mix yet
• Not going to write any more C# types, has written all that are in him ;-)

• "This will fail!"

  var language = Language.load(/* MImage */ typeof(Program).Assembly, "QCon", "Simple"); // yields runtime that can parse a program
  dynamic result = language.ParseString(input);
  var query = (from content in ((IEnumerable)result).OfType<dynamic>()
              where content.Kind == "HashTag"
              select content).Any();
  Assert.IsTrue(query);
  

• It failed indeed.

• "This talk is not about integration of two features I don't work on"
• M is optionally typed, structurally typed
• optional typing: syntax Bob = any* : Integer32 => 42;
• only partially plumbed in the current version

• Example for structural typing (not really working yet):

  module Ola 
  {
      type HashTagRec = 
      { 
          Kind : Text where value == "HashTag";
          Topic : Text;
      }
  }
  

• Rudimentary grammar debugging: set breakpoints in input source text; 4th pane shows up, shows matching stack

• Syntactical and semantical editing support
• Semantics relies on hooks that are not there yet
• M is built using an M Grammar
• Language completion for M is built using C#
• Ambiguators for GLR need to be written in C#
• One of the metrics used to evaluate the language: XML. There is a grammar for XML, briefly demoed.
• MPS guys have a different religion – Microsoft believes people have a text editor they love
• <?magnum PI?> :-)
• Comment from Martin Fowler: Main difference to classic tools such as ANTLR is the dynamic - no code generation needed
• Comment from Ola Bini: Didn't see the type-checking and debugging before – now he's impressed

These are my unedited notes from Brian Guthrie's talk about Internal DSLs in Groovy, Ruby, and Others

• A DSL is a computer programming language of limited expressiveness focused on a particular domain
• PHP originally started out as a DSL, but is no more
• SQL is an excellent example of a DSL
• Ant as an example of focus on a particular domain
• 2 flavors of DSLs internal and external
• An internal DSL is a kind of API
• Expressiveness matters more than the implementation details
• methods in a DSL make little sense out of context
• Example: fluid interface as DSL, calendar.add("dentist").from(fourPM).to(fivePM).at("123 N Southwest Ave");
• Example of something that hides intent in lots of ceremony
• be declarative, be accepting
• every API is a conversation - with yourself, your team members, your business
• Patterns for internal DSLs
• method chaining | type transmogrification
• Explanation of fluid interface pattern using the Calendar example
• Example: Mocha, Ruby mocking framework as another example
• the finishing problem: what's the final thing that gets returned?
• nested closures | semantic model
• a lot of times, a DSL is an interface to a library, but there should be an underlying model

• Awsymandias: DSL to describe Amazon EC2 environments

  stack = define ... do |s| s.instance :db, :instance_type => "m1.large" end stack.launch

• (classical model of using ruby class methods and blocks)

• definition should != domain model
• high-level DSL should be separate from the domain model [I very much agree; much of it is due to the tricks you have to do to get something that reads nicely]
• keep domain model clean
• literal extension | string polishing
• monkey patching and converting something that's nearly code to actual code
• Groovy example of a simple DSL, similar to what you'd do with Hpricot
• digression: shows how to re-open classes in Ruby, using things like 5.seconds
• shotgun approach to opening classes
• Groovy's category support enables clean addition of methods to classes
• [Didn't know Groovy has some kind of extension method support, pretty neat]
• literal extension | method chaining
• Example: jQuery uses Javascripts prototype model to add functions to objects as needed to support fluid method chains
• method chaining andChaining andChaining
• example: Ioke
• DSL for Starbuck's weird combinations
• ispec is the coolest spec framework ever
• a DSL is an API, a language, a conversation
• be declarative
• know your audience
• use fluent interfaces, message chains
• nested function | closure
• audience comment: Showing a complex API that's simplified misses the point, which is about having domain experts understand the language [I disagree, the domain expert in this example might be someone who understands the simplified code, but not the convoluted mess it's become]
• Martin Fowler: both DSLs for programmers and non-programmers are useful
• Q. Another useful pattern: natural language interpretation, Cucumber as an example
• Q. Real world use? A. Often used in high-level functional test specs