During the weekend of September 18th, St. Louis became a geek mecca for three days while the third annual Strange Loop conference was in full swing.  The Ballpark Hilton was stormed by nine hundred code slingers who came from the four corners of the earth to revel in the aura of their heroes and vigorously engage in religious wars about their favorite technologies.  It was pretty damn glorious.  Strange Loop is the brainchild of Alex Miller: gentleman, community leader, founder of Lambda Lounge, and parentheses parser extraordinaire.

Here is a brief recap of the best sessions I attended, and my overall impression of the conference this year.

Sunday

Sunday was broken up into two three-hour workshops, followed by a dinner with conference speakers.

• Introduction to Clojure.  Clojure gets a lot of love at Strange Loop.  It’s a functional language in the Lisp family that runs on the JVM.  The workshop was conducted by Stuart Sierra, co-author of the Apress title Practical Clojure.  A three hour introduction to anything is bound to be pretty intense, and this workshop didn’t disappoint.  I felt like I was drinking from the Clojure firehose the entire time.  Stuart did a deep dive into language syntax, types, conventions, etc. while attendees followed along in their REPLs.  Stuart is a very good presenter, and in general I found the session to be quite informative.  My only critique is: he spent too much time on data deconstruction, and I believe it cost him time at the end of the workshop, so he was unable to cover all of the material he had prepared.  I think it would have also been nice to see examples of Clojure programs “in the wild”–demonstrations of what can really be done with the language (beyond a slide deck).
• Introduction to Django.  There are two OOP scripting languages that Strange Loop folk aren’t afraid to admit they use: Ruby and Python.  Of the two, I am more interested in Python, and so I decided to attend a workshop on Django, a popular Python web framework.  Of all the sessions at Strange Loop, I probably learned the most from this one, primarily because I had been working through the Django tutorial already, and also because Jacob Kaplan-Moss is a great presenter.  He walked attendees through the creation of a small Django application, from start to finish, while explaining every key concept in detail as we worked.  It was well-paced, everything was very clear, and really illustrated how Python is simultaneously unassuming and powerful.  Django is similar to other MVC frameworks (Rails, ASP.NET MVC, Symfony) but, more than any other, favors simplicity over, well, anything.  It has no “controllers” per se–each HTTP action is mapped to a Python function that invokes the model and renders a view.  It reminded me of Sinatra in some ways, but with a bit more plumbing.  The configuration cascades, so things defined at the global project level can be overridden in each module (or “app”).

The speaker dinner was very nice — I sat at a table with Bill Odom and Mark Volkmann, local Midwest speakers whose sessions I attended on Monday.  The food was good, the bar was open, the company was nerdy, and a good time was had by all!

Monday

The problem with Monday was that there were too may good concurrent sessions, and I could only choose one to attend for each time slot.  This seemed to be a common lament for tweets adorned with the #strangeloop hashtag.

• Category Theory, Monads, and Duality in (Big) Data.  Erik Meijer (Microsoft) opened the conference with a keynote about the “duality” of noSQL systems and traditional RDBMS storage architectures.  Duality, in this context, does not refer to the Slipknot song (that would have made the talk far more exciting), but rather to the mathematical concept wherein two things share a special relationship because one is a reflection of the other, but with inverted properties.  Meijer’s point was that noSQL systems and RDBMSes share a similar, fundamental approach to storing data, but differ about how dependent data is referenced (think: foreign keys).  In an RDBMS, dependent data points to its principle, but in noSQL systems, the principles point to their dependents.  Meijer’s conclusion was, therefore, that noSQL should be re-branded as “coSQL”, because it is complimentary, not antithetical to, RDBMSes.  I’m not entirely sure what I think about his conclusions.  I am not as mathematically literate as I would like to be, but whenever I hear someone claim that: “you know, X is really just a special case of Y” I get a little nervous, mostly because abstractions can be easily frozen.  Because we have been dealing with RDBMSes for so long, it is easy to slip into a pattern of seeing all data storage as a variation of the relational pattern, and possibly missing the unique things that noSQL solutions offer.  But I don’t think this was Meijer’s intent, nor do I think most people would come to this kind of conclusion.
• CSS3 and Sass.  In this session, Mark Volkmann talked about the new CSS3 features added by the W3C in recent years.  CSS is the mainstay of web design, and some of the additions to the CSS specification are quite exciting.  More importantly, Mark also talked about the Ruby gem Sass.  Sass does for CSS what jQuery did for JavaScript — it creates a thin abstraction layer over CSS that supports nifty things like variables, mixins, selector inheritance, selector nesting, functions, and even the ability to do away with curly braces in CSS files forever!  Sass files are syntactically very similar to CSS–in fact, pure CSS can be placed in a Sass file and Sass will work just fine.  The Sass executable accepts the Sass file as input and generates a normal CSS file as output.  It can even be set up to “watch” a directory, and any changes to Sass files in that directory will trigger automatic CSS generation.
• Building Applications with jQuery UI.  I’ve used jQuery for a while, and I’ve used jQuery UI on a number of projects, so much of this session was a refresher for me.  Scott Gonzalez, development lead for jQuery UI, talked about effects and widgets libraries, covering each in brief.  A significant amount of time was spent demonstrating how a developer could tap into the jQuery UI API and make custom widgets, which was particularly interesting to me because I had not yet tried my hand at it.  I was delighted to discover how simple and elegant the widget API is.
• A Tale of Three Trees.  Last year I took a job at Fpweb.net.  Until that time I had only worked with centralized version control systems, but at Fpweb, the development team uses git.  It took me several weeks to become comfortable with the git workflow, and a few months before I actually began to understand git internals.  In this presentation, Scott Chacon explored the git –reset command; specifically how it impacts the user’s working directory, the index, and the current working branch.  Reset takes one of three arguments for manipulating source files: –soft, –mixed, and –hard.  Previously I had only used –hard to nuke changes that I knew I didn’t want.  This effectively forced my working directory and index to reflect the HEAD pointer in git.  The –mixed argument removes commits from the git index (but leaves the changes as uncommited), and the –soft argument allows you to move the HEAD pointer without destroying changes in the working directory or the index.  Scott talked about several interesting (and somewhat terrifying) things you can do with reset, like create “phantom” commits of files that never existed in the working directory, or magically materialize branches by directly manipulating the git index.
• Vim: From Essentials to Mastery.  Since I’m a .NET developer I don’t use vim daily, but I’ve been making a concerted effort to use it for side projects and learning new languages on the *nix platform.  Vim is undoubtedly a powerful editor; it supports a massive variety of language syntaxes, and has more plugins than you can shake a stick at.  The initial learning curve is steep, since there are lots of keyboard shortcuts that have to be committed to memory, but the shortcuts all follow intuitive conventions and the productivity gained by never removing your hands from the keyboard is significant.  In this session, Bill Odom covered a handful of “must-know” commands, talked about some very useful plugins (like NerdTree), and took general-use questions from the audience.  When Odom started talking about registers, he quickly went over my head, but the “essentials” were great stepping stones in my journey.
• We Really Don’t Know How to Compute!.  Gerald Sussman is pretty much the patron saint of functional programming.  His seminal work Structure and Interpretation of Computer Programs is a classic text in computer science.  I’m pretty sure he invented parentheses.  The general demeanor of attendees in his presence was a mix of awe and adoration, sprinkled with a side of childlike hero worship.  Dr. Sussman’s keynote presentation began with the observation that the human genome is a supremely compact collection of information that is used to create complex life.  Modern computation, in comparison, is painfully inefficient and inaccurate, and is used to produce wonders like Angry Birds (my words, not his).  Unfortunately, that is about all I got from his keynote, as the remaining hour or so was a high-speed roller-coaster ride through electrical engineering, physics, and LISP.  But at least I wasn’t alone–the live tweets during his presentation consisted of two basic reactions: “OMG what a genius!” and “Owwww my head!”  I realize that Dr. Sussman is used to speaking to graduate students who are steeped in the halls of higher education, but I do wish he would have tempered his presentation for a lay audience that could have gotten more out of it.  Still, I take his presentation as a personal challenge to improve my understanding, and perhaps if he speaks again in the future I’ll be better prepared.

Tuesday

• Teaching Code Literacy.  I had the privilege of sharing a lunch table with Sarah Allen on Monday, and our brief conversation about programming and education piqued my interest in her session.  I’m glad I attended; it was easily one of the best sessions at Strange Loop.  As an experiment, Allen created a game called Pie Bakery to teach students the basics of programming.  The game framework is written in Ruby, but she created a Ruby-based DSL called Pie that students use to create their own game instances.  Pie is a stripped-down, simplified language that focuses on core programming concepts and makes it very easy for students to grasp what the program is doing.  While working with students, Allen made two key observations that I thought were very interesting.  First, students were far more likely to continue programming when feedback from their code was immediate.  The Pie Bakery application can run a game as soon as its basic structure is defined, so students could see the results of their effort immediately.  The second observation she made was that students were more likely to persevere when errors were encountered if they were programming in a group setting.  The social aspect of programming made the debugging activity less tedious.  These two observations, I think, can be roughtly translated into the Agile principles of immediate feedback via continuous delivery, and pair programming.
• The Future of F#: Type Providers.  The (handful) of .NET developers at Strange Loop were very excited about this talk, as it was the only Microsoft-oriented session at Strange Loop.  Yes, we had a small room, and yes, everyone tried to slip in unnoticed to avoid the mocking glares of the Haskell and Clojure fanbois, but we learned a lot and had fun doing it.  Joe Pamer, development lead for F# at Microsoft, talked about F# Type Providers, a new way to query data from nearly any source, in a strongly typed way, without using reflection or code generation, and with all the benefits of Intellisense.  If it sounds like magic, it pretty much is.  Basically, a data source (such as a database, web service, OData feed, etc.) defines a data “schema” which can be understood and deconstructed into objects, properties, namespaces, etc.  Type providers can read this schema, and provide data to the IDE at design-time that will make it appear as if strong types based on that schema have been generated, but in reality, only IL will be generated when the project is compiled.  Pamer also talked briefly about the F# tooling improvements in VS2011; sadly, there will be no refactoring support, but the language remains a first class citizen in the IDE, so we can expect a better integration experience.
• “Post-PC Computing” is not a Vision.  Allen Wirfs-Brock, Mozilla Research Fellow and member of the ECMAScript standards committee, talked about the “post-PC computing” mantra, and how it is really a simple statement of future change, but not a statement of vision at all.  Apple and Microsoft didn’t have a “post-mainframe computing” vision; they had very specific ideas about bringing computers into the home, into the hands of normal people.  It was this specific vision that allowed them to succeed.  The future of computing, Wirfs-Brock argued, is definitely a web-centric vision, at the core of which will be a shared, ubiquitous language: JavaScript.  He spent the latter half of the talk reviewing new changes to the ECMA standard, and how JavaScript is finding a home, not only in the browser, but on the server as well.
• Simple Made Easy.  If Gerald Sussman is the patron saint of functional programming, Rich Hickey is at least a Bishop.  Maybe even the Pope.  His homage to LISP, the Clojure programming language, was definitely a pet favorite of attendees and presenters alike, and for good reasons–it is terse, powerful, and has a pretty sweet logo.  Anyway, Hickey talked about the concepts “simple” and “easy”, and how they are really two different ideas that often get equivocated in software development.  He talked about the etymology of each word: “easy” refers to the comfort level a person feels when doing something they are familiar with, whereas “simple” refers to a thing and its complexity (or rather, lack of complexity) in relation to other things.  Hickey contends that developers are too focused on things that are “easy”, that they feel more productive with things they are already familiar with, or that have lower barriers to adoption (fits within an existing environment, team-mates already know the technology, already approved by the authroitah!, etc.).  Unfortunately easy things are not necessarily simple things.  The word “simple” emerged as a way to describe a rope which only had a single strand, in contrast to a complex rope which consists of multiple strands that are entangled in a braid.  Simple software should avoid complex entanglements; it should do one thing, and one thing well, and it should be carefully decoupled from its dependents.  This not only makes software maintainable and extensible, it also makes it easier to understand.  The human brain can only focus on a handful of ideas at one time, so when software is complex (i.e., tangled, intertwined), a developer is more likely to forget essential pieces of information when writing or changing that software.  By carefully thinking about the nature of the software we write, and by choosing languages and tools that promote “simple” development (not necessarily “easy” development), developers can write better, more maintainable software.

Closing Remarks