Once upon a time, far far away I was in working on my undergrad in a department that had a mix of equipment. They had a lab full of IBM PC clones running MS-DOS. These were mainly for the first couple years for Turbo Pascal work. What was really exciting was the senior lab of Sun workstations. I instantly fell in love with the Sun 3/60s. Even though they were no longer state of the art (SparcStations had recently come on the scene), they were still powerhouses for working with Lisp and Smalltalk.
This was originally posted on the SteelSeries Technology Blog and the work was supported by SteelSeries. Since this was based on work I had originally done for RubyLisp, I’m including it here as well.
I recently needed a more flexible and performant way of manipulating structured data, specifically data coming into the system in the form of JSON.
GoLisp has a way to convert back and forth between JSON and Lisp which uses lists for arrays and association lists for objects. This worked fine but association lists can be cumbersome to work with and relatively time consuming. To address this, I ported the frame system from my RubyLisp project, making some improvements while I was at it.
A frame is a collection of slots. A slot is a key-value pair. So
frames are structurally much like data structures such as Dictionaries
and Maps. In fact, the underlying implementation is a Go
map[string]*Data. What makes frames special is the functionality
that is built on top of that.
Thanks to the wayback machine, I found my original post that resulted in rSpec posted on July 5, 2005.
Test Driven Development (TDD) has made it to prime time. Big companies are paying big money to have their programmers trained in how to do TDD. It’s a popular topic at conferences… agile and otherwise. My book on TDD won a Jolt award. So everything’s rosy, huh? Everyone who’s doing TDD is fully understanding it and getting the full benefit, right?
I gave a talk a bit over 4 years ago in which I looked out at the next ten years and made the prediction that our current languages and paradigms wouldn’t hold up. More specifically, that functional programming would be pretty much required for tackling cutting edge problems. And yet, I didn’t do much about it. Sure I spent some time with Clojure, but then I’ve been using Lisp for longer than I’ve been using OO, so since about the mid 80s.
What is it that we do? Are we programmers, software engineers, or computer scientists? All of the above, some combination, or none?
My thesis is that it depends. All three are real things. All three are very different. Let’s look at each, in turn.
Today this arrived in my inbox. I’m abandoning all hope of productivity for the next while.
Thirty years ago on January 24, 1984, the world was introduced to Macintosh … and 1984 wasn’t like 1984.
One of the memes going around today was “What was your first Mac?” As I spent a few minutes reminiscing, I thought I might as well write about it my history with Mac and, more generally, Apple.
I get asked quite regularly what books I would suggest, so I’ve put together a list. Since this will be a living document, changed and added to over time, I’ve make it a page. I’ll be adding to it over time, and will try to post a note when I make any significant additions.
You can find it using the Books link in any page header.
Once again, I am attempting to start writing more. Looking back, my most recent attempt was six months ago. Well, here goes again. This time starting from scratch, exploring Github Pages as a hosting platform and using Jekyll for publishing. Wish me luck (and motivation).