In part 1 of this two part blog post I described the general setup of the Joy of Coding conference that I attended last week. In this post I would like to zoom in on the content: the sessions, and what I learned from them.
Introduction
Before I dive into the individual sessions, a general remark: as I said in part 1, this is not a conference specifically targeting any subculture like Java, .NET, or other group. It's a conference for software developers in general, and especially those who wish to improve. That was also reflected in the program (just like the Joy aspect :smile: ). For reference, here is the full conference program once more:
Credit: Jettro Coenradie from Joy Of Coding organizing committee
Programming as Distributed Cognition
The opening Keynote: Chris Granger on "Programming as Distributed Cognition: defining a super power".
Chris is known mostly for the LightTable code editor, which is awesome. By the way, it's also open source :smile: .
First let me explain (part of) the title as described on EduTechWiki:
Distributed cognition refers to a process in which cognitive resources are shared socially in order to extend individual cognitive resources or to accomplish something that an individual agent could not achieve alone. Human cognitive achievements are based on a process in which an agent's cognitive processes and the objects and constraints of the world reciprocally affect each other. Cognitive processes can be distributed between humans and machines (physically distributed cognition, Norman, 1993; Perkins, 1993) or between cognitive agents (socially distributed cognition). Salomon (1993, p. 112) has pointed out that distributed cognition forms systems that consist of an individual agent, his or her peers, teachers, and socio-culturally formed cognitive tools.
Basically it says that knowledge doesn't only reside within humans: the medium matters. We think by means of the medium. Most famous example is probably paper, and the art of writing/sketching. This has enabled us to express and share ideas with each other that would have been impossible without such a medium. Chris's talk was mostly about how computers (as a medium) could and should enable everyone, not just programmers(!), to share and describe ideas in a way that computers can execute on. Think about it: how many systems/programs are not being built today, just because the people who know what they'd want to build can't do it, because they lack programming skills?
One quote that we hear a lot nowadays is "coding is the new literacy". But as Chris pointed out that's a very wrong way to look at things: we as humans shouldn't be forced to use coding to express ideas, instead the computer as a medium should allow us to model our ideas and intuitions. Let's face it: we really don't want "everyone" to start thinking in code, do we?
Chris presented one example of how that's totally nuts: imagine a button in the browser with a simple counter on it: each time you press the button the counter should increment by one. Conceptually this is very simple, and in an ideal world non-programmers should be able to build this easily. But looking at the code, and all the technologies involved (HTML, CSS, JavaScript, callbacks, closures, etc) this would even today cause a lot of programmers a hard time. Surely it can't be the way forward if we want non-programmers to be able to express/build/model this kind of thing?
Chris has written a must-read essay on this topic, and explained this idea of modeling vs coding in the first half of his talk.
In the second half he then went on to demo the new tool/product he's been working on, Eve. From his own introduction of Eve:
Eve is our way of bringing the power of computation to everyone, not by making everyone a programmer but by finding a better way for us to interact with computers. On the surface, Eve is an environment a little like Excel that allows you to "program" simply by moving columns and rows around in tables. Under the covers it's a powerful database, a temporal logic language, and a flexible IDE that allows you to build anything from a simple website to complex algorithms. Instead of poring over text files full of abstract symbols, you interact with domain editors that are parameterized by grids of data. To build a UI you don’t open a text editor, you just draw it on the screen and drag data to it. It's much closer to the ideal we've always had of just describing what we want and letting the machine do the rest. Eve makes the computer a real tool again - one that doesn't require decades of training to use.
So, like Excel has made it possible for everyone, especially non-programmers, to hack around with grids of numbers, the purpose of Eve is to provide a similar tool for relational data.
As Yan Cui (one of the presenters at Joy Of Coding) has already noted in his excellent recap of Joy Of Coding, Chris's keynote related closely to Bret Victor's Learnable Programming message. For more on this topic, watch for instance these talks by Bret: Media for Thinking the Unthinkable and The Humane Representation of Thought.
Language Workbenches & Domain Specific Languages
After the keynote I attended the workshop: "Hack your language with Rascal". The workshop was conducted by Tijs van der Storm and Jouke Stoel, two researchers from the "Centrum voor Wiskunde en Informatica" (Research Institute for Mathematics and Computer Science).
Rascal is a meta-programming language. To explain what that means (from its website😞
The one-stop shop for metaprogramming
You want to use the best tool for the job when analyzing, transforming or generating source code, so normally you will end up with many different tools, possibly even written in different languages. Now the problem is to integrate these tools again. Rascal solves this problem by integrating source code analysis, transformation, and generation primitives on the language level. Use it for any kind of metaprogramming task: to construct parsers for programming languages, to analyze and transform source code, or to define new DSLs with full IDE support.
The workshop itself had a more modest goal: extend JavaScript with new statements and expressions, and obtain the new language SweeterJS :smile: . To implement such a scenario you have to define these new constructs and prescribe how an interpreter (or compiler) can convert them back into ordinary JavaScript. The hands-on part consisted of implementing the latter by extending the so called desugaring function, that parses a SweeterJS statement/expression and translates it to JavaScript. One example of such a statement was the "todo" statement. Normally you'd use comments for something like that. Here, "todo" was promoted into a real statement. A nice idea. Another fun one was the "dont" statement, that takes another statement as an argument and *doesn't* execute it. Of course, these are simple and even silly examples, but it goes to show you can extend your favorite language very easily to make it do what you want/need.
What you need though is a grammar of the base language. As Jouke told me (and this surprised me) such grammars are hard to come by. Most language definitions/specifications are incomplete, only available as documentation, or as a compiler implementation. This has been the biggest obstacle so far in working effectively with Rascal.
The source code for the workshop can be found on GitHub, and the instructions (prerequisites, installation of Rascal, workshop details) are all contained in the doc subdirectory, so if you're interested, have a go at it!
Currently, Rascal is mainly a research tool, targeted at programming language designers and researchers. But especially the ability to define Domain Specific Languages, either standalone or embedded within a mainstream language, is where the tool also becomes interesting for ordinary software developers.
Let me conclude this section by pointing to more material on DSLs:
- Wikipedia article on DSLs
- Martin Fowler about DSLs (really an entry point for a lot of content)
- The book about DSLs, by Martin Fowler and Rebecca Parsons (links to Amazon)
- DSL Engineering, another (almost free) book, by Markus Voelter
- InfoQ presentation by Martin Fowler (about 25 minutes)
Programming Styles
The lunch keynote was given by Crista Lopes on "Exercises in Programming Style". This was another one of my favorites: I'd seen a video of Crista presenting on programming styles last year (watch the 40 min InfoQ-recording from the StrangeLoop conference for an impression), and was very glad she'd be here!
Crista Lopes is a professor at the University of California, Irvine where she teaches some advanced programming courses to undergraduates. Her main course is about using different ways to think about problems and program them using different programming styles. Note: the term style doesn't refer to layout formatting, indentation etc. It is the way a certain algorithm is programmed, for instance in a functional style, or an OO style.
The problem with these two styles is that they're not well defined. Ask 5 people how to solve something in an object oriented way, and you'll get 5 totally different solutions. So what's a computer science professor to do? Well, she was inspired by Raymond Queneau, a French writer who had written "Exercises in Style". In that book, Queneau tells the same simple story 99 times, each time in a different style. Examples are: metaphors, anagrams, past, present, hesitation, etc. It turns out that applying a certain style is like forcing some constraints.
So she came up with a relatively simple problem: term frequency. She wrote it down in different styles (all in Python), and tried to think of constraints to describe a certain style. In this way she managed to describe 33 program styles. Some less familiar examples include composing functions, continuation passing style, data flow, etc.
The main take away from the presentation is captured in this photo by (again) Yan Cui:
Credit Yan Cui (source)
Resources:
- Crista has written a book on this subject with more background on each style including exercises.
- Get the code (including a list of constraints for each style) from Github to play around with it yourself.
ChatOps
In the afternoon I opted for some more presentations. The first of which was a talk by Ben Straub: "Hacking culture with chat robots". I had no idea what to expect, but it sounded good :smile: .
Ben shared his experience of using chat software within the development team. Examples of such chat room products are Slack, HipChat, Campfire and IRC. Their purpose is to offer one central place for all team communication. Most of them offer a lot of integrations with other tools like Github, Google Drive, Heroku, IFTTT, Jira, Twitter and many more. This means you can set up developer oriented workflows with them, going way beyond just an ordinary chat room. However, this is only step one!
The next step is for your team to integrate a chat bot into the room. Again, some well known exampleshere are Hubot, Lita and Err. A chat bot is an automated participant in the chat room, 'someone' you can give orders. Of course for the chat bot to really do something you have to program the corresponding script first. For chat bots like the ones mentioned above a lot of scripts and plugins are already available, which makes using them fairly easy.
The third step is to have some fun with your chat bot, for instance by turning on GIF search. Example:
Credit Ben Straub (source)
In the final step you can (and should) start automating stuff. And you can automate pretty much whatever you like: let your bot post notifications from other tools to the chat room, execute commands you send to it, ask it for the most current (foursquare) location of your remote coworkers, let it deploy your changes to production(!), let it manage AWS EC2 instances, etc, etc.
Take away no 1 of Ben's talk was that having chat software for communication and a chat bot for automating a lot of the typical developer workflow activities can greatly enhance a team's productivity. Also, everyone in the team can gain insight because all the chat content is fully searchable. Furthermore, when onboarding new team members, they get instantaneous access to the history of the chat, and can see what's been going on, what's happening right now, etc, all of which will allow them to get up to speed much faster.
The term for this kind of developer workflow automation is ChatOps (this links to an introductory article). It's kind of "where DevOps meets IM".
The second take away was that you don't need to limit this automation to your development team, you can also use the chat bot for company wide stuff. Here Ben had a great example of employees 'highfiving' each other for something cool or outstanding they'd done.
Employees are allowed (and even encouraged) to give a monetary reward to a coworker. The exact amount will depend on what exactly the accomplishment is and is determined by the high-fiving employee! It works like this:
Credit Ben Straub (source)
In this example Patrick high-fives Greg in the chat. The immediate effect is that this gets broadcasted by the bot to everyone in the same room (presumably everyone within the company), accompanied by a funny animated GIF showing a high-five. So everyone can see what Greg has done, and that he has earned himself a gift card for $75. This is real money, because what happens behind the scenes is:
Credit Ben Straub (source)
So, when Patrick posts his high-five message to the chat (Slack in this example), the bot forwards this message to a third-party gift card service that has an API for ordering gift cards, Tango in Ben's example. The bot then sends back the animated GIF to the chat. Meanwhile, at Tango the order is processed, and an email goes out to Greg containing (or telling him to expect, can't remember exactly) his voucher.
In the end it's more about recognition than money of course. Ben's experiences with this were very positive: the transparency makes sure people don't abuse the system, and of course there are a few constraints like maximum reward per day, per employee, and of course you can't high-five yourself. This boosts morale. A great example of gamification in the enterprise!
Resources:
- The presentation is available on Ben's website, with many more examples.
- Here is a free ebook in For Dummies style about ChatOps.
- A talk about the use of ChatOps at Github (where the term originated)
Declarative code
The next talk was by Tom Stuart (author of the excellent book Understanding Computation), and was about writing more declarative code instead of imperative code. It was an awesome talk, but with a lot of Ruby code (most of which I didn't understand), so I can't recollect the exact message or content. I've asked Tom, and he would release a transcript as soon as the video would be available on InfoQ. I'll update this post accordingly.
AWS Lambda
The last parallel talk was by J. Randall Hunt of Amazon Web Services, talking about AWS Lambda. Most of this went over my head, and it also had a bit of a sales-pitch ring to it that I didn't particularly like, but the core message and promise of AWS Lambda is very interesting (from the web page):
AWS Lambda is a compute service that runs your code in response to events and automatically manages the compute resources for you, making it easy to build applications that respond quickly to new information. AWS Lambda starts running your code within milliseconds of an event such as an image upload, in-app activity, website click, or output from a connected device. You can also use AWS Lambda to create new back-end services where compute resources are automatically triggered based on custom requests. With AWS Lambda you pay only for the requests served and the compute time required to run your code. Billing is metered in increments of 100 milliseconds, making it cost-effective and easy to scale automatically from a few requests per day to thousands per second.
The obvious comparison here is to electricity: instead of having your own on-premise generator, you consume power whenever you need it through a well defined interface (sockets), without having to care where it comes from.
A real life example of AWS Lambda is the bike share program in New York City where they've used AWS Lambda to run the software for this program.
Cool Code
The closing keynote was given by Kevlin Henney about "Cool Code". Kevlin is a well known speaker at conferences all over the world, who always knows how to entertain the audience, and personally I'm a big fan of his.
This presentation was a whirlwind tour through some old (and new) code examples that were in general more esoteric than useful, completely in line with the Joy aspect of this conference :smile: . A few examples:
Credit David Horne, 1983 (source)
Can you guess what this program does?
It's a fully functional chess program, written for the ZX81, and using less than 1K of memory!
A second example comes from the infamous FizzBuzz industry (source). Here's the source code (C++):
#include <iostream>
#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_VECTOR_SIZE 110
#include "boost/mpl/if.hpp"
#include "boost/mpl/int.hpp"
#include "boost/mpl/vector.hpp"
#include "boost/mpl/push_back.hpp"
using namespace std;
using namespace boost::mpl;
struct Fizz{};
struct Buzz{};
struct FizzBuzz{};
template<int i>
struct RunFizzBuzz
{
typedef vector<int_<i> > Number;
typedef typename if_c<(i % 3 == 0) && (i % 5 == 0), FizzBuzz,
typename if_c<i % 3 == 0, Fizz,
typename if_c<i % 5 == 0, Buzz, Number>::type>::type >::type t1;
typedef typename push_back<typename RunFizzBuzz<i - 1>::ret, t1>::type ret;
};
template<>
struct RunFizzBuzz<0> // Terminate the recusion.
{
typedef vector<int_<0> > ret;
};
int main()
{
typedef RunFizzBuzz<100>::ret::compilation_error_here res;
}
This program can't be beaten with respect to run-time performance: it will actually never run! It doesn't even compile! But, here is the error message:
\Main.cpp(36) : error C2039: 'compilation_error_here' : is not a member of
'boost::mpl::vector101 <SNIP long argument list>'
with
[
T0=boost::mpl::int_<0>,
T1=boost::mpl::vector<boost::mpl::int_<1>>,
T2=boost::mpl::vector<boost::mpl::int_<2>>,
T3=Fizz,
T4=boost::mpl::vector<boost::mpl::int_<4>>,
T5=Buzz,
T6=Fizz,
T7=boost::mpl::vector<boost::mpl::int_<7>>,
T8=boost::mpl::vector<boost::mpl::int_<8>>,
T9=Fizz,
T10=Buzz,
T11=boost::mpl::vector<boost::mpl::int_<11>>,
T12=Fizz,
T13=boost::mpl::vector<boost::mpl::int_<13>>,
T14=boost::mpl::vector<boost::mpl::int_<14>>,
T15=FizzBuzz,
<SNIP of elements 16 - 95>
T96=Fizz,
T97=boost::mpl::vector<boost::mpl::int_<97>>,
T98=boost::mpl::vector<boost::mpl::int_<98>>,
T99=Fizz,
T100=Buzz
]
Neat, isn't it? Read the original article to understand how this works.
One last example (couldn't find the source for this one):
What do you think this program will produce?
No, not an approximation of π of course. This turns out to be an example, not of programmer humor, but math humor. The program produces e.
If you don't want to wait for the video of Kevlin's closing keynote of Joy of Coding but you're still interested, have a look at this video, from the GeeCon 2012 conference. A lot of the examples are the same.
Conclusion
If you made it until here: congratulations. You've now got an impression how much I learned from this conference (and from the research for this blog post :smile: ), and hopefully you'll agree that it's definitely worth your time and money to attend a non SAP-related developer event every once in a while. My next non-SAP conference will probably be the new conference around Domain Driven Design: DDD Europe. See you there?
Thanks for reading!
1 Comment
