Lately I have been working on designing Cloje's host interop API. I had the outlines of a design for the API already, but as I started filling in the details and thinking about different use cases, I realized that my simple design would have had some serious problems in actual use. The host interop API was scheduled for Cloje 0.2, but I have decided to push it back to 0.3 to give me time to get it right.
I wrote this post mostly for my own benefit, to help me focus and organize my thoughts. But, it might be interesting to anyone interested in API design.
I previously posted that I was planning Cloje 0.2 to have a variety of new features, and aiming to release it in mid to late June. However, for a number of reasons, I am reducing the scope of version 0.2, and moving the target release date to July 5.
Cloje 0.2 will definitely include the hash-set data structure, and a library of set operations based on clojure.set, as previously written.
[Update August 2, 2015: Parts of this post have been revised to "tone down the snark". This post was a byproduct of frustration with the design of the clojure.set API, but in some places I had expressed that frustration in ways that were merely cathartic and sensational, not constructive or informative.]
Lately I have been implementing the clojure.set API for Cloje, and as usual, Clojure's APIs are full of surprises, particularly if you pass unexpected types.
Indeed, every clojure.set function I have looked at so far has its own peculiar way of handling this obvious edge case. In general, the lack of type checking results in unexpected or unpredictable behavior that may confuse the user and make bugs harder to diagnose.
Let's start with some fairly mundane examples, then work our way up to the truly puzzling. I'll then explain why this is a problem, and describe how I'm addressing it in Cloje.
This week I've been doing planning for Cloje, and trying to figure out how I might approach implementing certain Clojure features. Even if I'm not going to write the code for several weeks, I want to avoid painting myself into a corner.
One such feature is support for metadata. I see three potential approaches one might take when implementing metadata:
Wrap the object with a metadata container
Inject metadata into the object
Store the metadata separately from the object
Each of these solutions is pretty hairy, and there are significant trade-offs involved. So, I wrote this blog post to explore these approaches and hopefully help me decide which to use.
Last weekend I announced version 0.1 of Cloje, a clone of Clojure built atop Scheme/Lisp, my latest side project. Developing it was an interesting experience, so I wanted to take some time to write out my thoughts. Cloje is still an ongoing project, but this is something of a post-mortem of its first two months of development.
Cloje is partly a fun learning exercise, but it may also be of practical interest to any Schemers/Lispers out there who have wished some of the cool features from Clojure were available in their language of choice.
Cloje currently targets CHICKEN and Racket, two popular implementations of Scheme. One of the chief goals of Cloje is portability. Most of the code is written using standard R5RS and SRFI features, so it would not be very difficult to add support for more Scheme implementations. I will be happy to add Common Lisp as a target, if a Lisper volunteers to help write and maintain it.
In mid 2012, I moved to downtown Detroit and joined Atomic Object as a full-time software developer. Ultimately, it wasn't the right fit for me, and I recently decided to go back to freelancing. Nevertheless, it was a positive experience, and I've gained new friends, knowledge, skills, and experience.
Over the course of the two years I was at Atomic, I wrote a wealth of articles for the company blog, Atomic Spin, on a variety of topics related to software development, ranging from specific technologies, to best practices, to community groups and events. Each article was crafted with care and attention. Enjoy!
Over the past 7 months or so, in addition to learning and using Common Lisp, I have been giving thought to the social issues affecting Common Lisp and its community. Over the past two months, I have been working on two projects, described below, to try to address the issues that most affect newcomers.
Lately, I've been focusing so much on Common Lisp itself, that I have barely spent any time on Ambienome, the whole reason I've been learning it. It has been so long that I can barely remember what I was working on. (Physics engine integration, I think?)
That's no good, so I wanted to take some time to set my thoughts and ideas for Ambienome onto paper (so to speak). This will help me slide back into that mode of thinking, hone my ideas by putting them into words, leave a journal of how the game evolves, and maybe spark some interest in anyone reading this.
Caveat: you should not interpret any part of this as a promise or firm description of how the actual game will be. I'm just unloading my thoughts and ideas as they exist now. Everything is still subject to change, etc.
It has been nearly 6 months since I dove into Common Lisp. I have been studying and/or using Common Lisp almost every day, working on Ambienome and related code. So, I wanted to take some time to document my observations, feelings, and impressions of Common Lisp at this time. Be advised that this is a fairly long post, even though I have trimmed out a lot of details and examples to keep it from growing even longer. (Apparently I have a lot of impressions!)
I have approached CL from nearly 8 years of programming in Ruby. I mention this because my experience with Ruby has certainly colored my impressions of CL, and many of my observations are about how CL compares to Ruby.
Over the past couple months, I've been tinkering with a new side project: