Simon St. Laurent

Simon St. Laurent is a web developer, network administrator, computer book author, and XML troublemaker living in Ithaca, NY. His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference.


You can find his writing on everything from technology to Quakerism to life in Dryden to gardening to New York State politics aggregated at simonstl.com.

Formulating Elixir

Simon St. Laurent and Jose Valim explore a new functional programming language

I was delighted to sit down with Jose Valim, the creator of Elixir, earlier this month at Erlang Factory. He and Dave Thomas had just given a brave keynote exploring the barriers that keep people from taking advantage of Erlang’s many superpowers, challenging the audience with reminders that a programming environment must have reach as well as power to change the world.

Elixir itself is a bold effort to bring Erlang’s strengths to a broader group of developers, adding new strengths, notably metaprogramming, along the way.

Watching Elixir grow has been a unique experience for me. I’ve seen other languages (JavaScript and XSLT) emerge, but Elixir combines solid foundations on prior (Erlang) work with a remarkably open conversation about how to structure the language. Jose tries things and asks for feedback, takes suggestions well, and values questions about how best to make the language accessible. Even without a standards organization, the process has remained open, stable, and productive.

Whether you’re interested in Elixir itself or just in the challenges of creating a new combination in a world filled with past experiments, it’s well worth listening to Jose Valim.

  • We’ve had functional programming since 1959 – why the burst of interest now? [2:10]
  • Moving from Ruby to Erlang “making Rails thread-safe, that was my personal pain-point” [3:13]
  • “Every time I got to study more about the VM, the tooling and everything it provides, my mind gets blown.” [6:12]
  • Why Elixir started, and how it’s changed as Jose learned more. [10:08]
  • Integrating new Erlang features (R17 maps) into Elixir. [15:43]
  • When can you use Elixir in production? [18:07]

I’m looking forward to seeing a lot more Elixir, even as I need to catch up on updating Introducing Elixir. I’m not sure it will conquer the world immediately, but it will certainly leave its mark.

Comment

Yes, CSS is code

Learning from "The Humble Border-Radius"

One of the best things I overheard at the Fluent Conference was (more or less):

“CSS live coding? I was like, that isn’t code. But then it was.”

Lea Verou had changed the mind of a skeptic.

CSS is not Turing complete (Update: Lea points out that I’m wrong about that), and I’ve long been grateful that it wasn’t designed as an imperative programming language. It can be too much code for designers, too little code for programmers, and yet it’s code.

I think about the graphics work I tried to do with shapes and sprites and assorted kinds of vectors over the years, and then watch this keynote. Even with the glitches and coming improvements she notes, it’s clear that whatever tools I was using at the time, they weren’t declarative enough. (I’d also just seen this JSFest talk on CSS box-shadow by Vince Allen, so I was looking forward to more CSS graphics magic.)

Read more…

Comments: 3

The web is eating software

Web technologies have become the default, and are spreading

photo: KF - http://en.wikipedia.org/wiki/User:KF/DetailsA few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:

Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.

That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).

Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.

On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.

Read more…

Comments: 2

Implementing hypermedia clients: it’s not rocket science

Not ugly, not complicated

hypermedia

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Layer 7 Principal API Architect Mike Amundsen demonstrated how to build hypermedia clients, for situations with and without humans in the driver’s seat.

(If you’d like to know more about hypermedia in general, this interview provides more background.)

In his talk, Implementing Hypermedia Clients: It’s Not Rocket Science, Mike explored how hypermedia approaches drive conversation between clients and servers, and the application structures that result from those structures.

  • 1:44 – “The Semantic Gap: Hypermedia tells us what we can do, but it doesn’t say why.”
  • 6:04 – Hypermedia and application control information – links!
  • 8:09 – Control factors – “I accept RSS, can you give me RSS?”
  • 10:41 – Foundations of the class scheduling domain example
  • 16:30 – “What is a hypermedia client that a human would use?”
  • 19:24 – “Faithful Hypermedia Clients (FHCs) pass along whatever the server returns, and lets a human sort it out.”
  • 31:20 – “So what’s a Hypermedia for machine client?… Makes choices, not waiting for a human”
  • 33:25 – Working with Maze+XML
  • 37:10 – The power of generic types

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment

How to (semi-)automate JavaScript refactoring

Disposable robot assassins and spreadsheets

Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Giles Bowkett demonstrated a wide variety of ways to write code that helps refactor code, showing developers a variety of ways to clean up and simplify their JavaScript. He gave ‘disposable robot assassin at large’ as his title, but it fit better with the code he was demonstrating.

Bowkett explored many options and iterations of his automation ideas,

  • The roots: Martin Fowler’s classic Refactoring. [at 00:50]
  • “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
  • Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
  • “More complex information… surfacing an implicit object model.” [at 7:45]
  • Filter scripts and text streams [at 14:45]
  • “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
  • Building on JSLint [at 20:10]
  • Switching to a Ruby parser for JavaScript to calculate differences [at 21:49]
  • JavaScript parsers: Esprima [at 27:26]
  • “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
  • Grepping through git history [at 32:53]
  • “Automatic refactoring will let you get to better code much faster.” [at 36:25]

It’s an amazing mix of capabilities that let you build your own robot (code) assassins.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment

Writing without knowing

Sometimes you need to be your customer

Sometimes you just need to leap into sharing your learning, even when you haven’t yet learned much. “Beginner’s mind” usually becomes more abstract as a person advances, making it difficult for beginners to learn from experts. If you can dare to write while you’re learning, you may find unique opportunities to create content that appeals first and foremost to learners.

Despite that, the “learn from the master” story remains powerful: of course, only those who know best should be trusted to teach! Sometimes that comes with the old guild-flavored model: masters should select worthy apprentices and mentor them for a long while.

The apprenticeship model has its benefits, but I’ve spent most of my career promoting what I generally call the DIY model. Even in the thriving field of programming, we don’t have enough masters willing to spend their time with apprentices. Masters seem better at talking with masters than with newcomers, and even the journeywomen and journeymen sometimes forget the difficulties of the paths they’ve followed to get there. The DIY model drops that lost formality and replaces it with books, videos, and occasional classes, combined with a lot of self-study.

Getting the DIY story right is incredibly difficult. Unless you’re lucky enough to be teaching in person, which has its own challenges, you have to anticipate what a reader or viewer will need. The feedback loop runs mostly through reviews, both during and after the creation of the piece. Getting ahead of that feedback loop means doing something scary: write about what you don’t know.

Read more…

Comments: 4

Go node without code

Command line tools improve development workflow

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Adobe Community Manager Brian Rinaldi showed off ways Node makes possible a new world of utilities, showing JavaScript developers a toolkit they will want to integrate into their workflows.

In his talk, Go Node Without Code, Brian talked about the many ways Node and the npm ecosystem of JavaScript packages can help front-end developers, even if they don’t want to leap to server-side programming.

Tools Brian explored include:

  • UglifyJS, the “JavaScript parser / mangler / compressor / beautifier toolkit” [at 02:00]
  • Less, “for building CSS, but offers a lot of features you don’t get in straight CSS” [at 06:15]
  • Grunt, addressing the “just adding steps to my workflow” problem. [at 9:09]
  • GruntIcon, “A mystical CSS icon solution” [at 18:18]
  • Automaton, a “task automation tool” [at 25:00]
  • HTTPster, a dead-simple “local static development server” [at 30:05]
  • The slightly more configurable Node-static [at 32:00]

You will need to be familiar with the command line for a lot of it – if you’re not, it’s a great time to learn!

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment

What should programming look like?

Can it really be simplified?

Even as we all scramble to use the programming tools we have today, developers look ahead hopefully, dreaming of better tools. What shape should those tools take? Who should they be for?

A few months ago, I had the privilege of talking about programming’s future with three great and very different programmers:

I’d encourage you to listen to the whole conversation, but to get started, you might explore these highlights.

Read more…

Comments: 3

Web application development is different (and better)

On both front and back end, the Web challenges conventional wisdom

The Web became the most ubiquitous distributed application system because it didn’t have to think of itself as a programming environment. Almost every day I see comments or complaints from programmers (even brilliant programmers) muttering about how many strange and inferior parts they have to deal with, how they’d like to fix a historical accident by ripping out HTML completely and replacing it with Canvas, and how separation of concerns is an inconvenience. Everything should be JavaScript.

(Apologies to Tom Dale, who tweeted a perfect series of counterpoints just as I was writing. He has visions of rebuilding the rendering stack in JavaScript, but those tweets are not unusual opinions.)

The Web is different, and I can see why programmers might have little tolerance for the paths it chose, but this time the programmers are wrong. It’s not that the Web is perfect – it certainly has glitches. It’s not that success means something is better. Many terrible things have found broad audiences, and there are infinite levels to the Worse is Better conversations. And of course, the Web doesn’t solve every programming need. Many problems just don’t fit, and that’s fine.

So why is the Web better?

Read more…

Comments: 2

Please nominate for the web platform awards

Recognizing the people who've built the Web

This March, we’ll be announcing the Web Platform Awards at the O’Reilly Fluent Conference. Fluent is all about JavaScript, HTML5, CSS3, and the best practices that make up the Web Platform, and we’d like to recognize the people who’ve made it the powerful ecosystem it is today.

The description is pretty simple, but I think includes a huge number of potentially great awardees:

The awards recognize individual contributors who have demonstrated exceptional leadership, creativity, and collaboration in the development of JavaScript, HTML, CSS, and the supporting Web ecosystem.

We hope to hear about many ways people have “demonstrated exceptional leadership”. It may be standards, it may be coding, it may be explaining, it may be community, or it may well be something I haven’t thought of yet. What matters is that you can tell us why you think they should get an award.

Read more…

Comment