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.
I am also working on establishing an API for converting data between Cloje and host-language types. At the moment, Cloje mostly uses the host language’s native data types, so the API will mostly do nothing, but it’s important to have the API available early on. For one thing, it allows users to write forward-compatible code that interoperates with the host language, and will continue to work even if I change how Cloje data structures are implemented. But more importantly, it forces me to think about how host-interop will work, so that potential issues will come to light early in the design process.
Those are the two main features planned for 0.2. It doesn’t feel like much compared to 0.1, to be honest. I considered delaying the release even further so I could put more into it, but that is a perilous and often self-defeating strategy. I think it will be better for the project, and for my own motivation, to have a consistent release schedule, even if that means more modestly sized releases.
Even so, Cloje 0.2 will be an especially small release. This is mainly because I spent the majority of my Cloje time over the past 6 weeks doing research and thinking and planning about open source project management, particularly as it relates to diversity and inclusivity. More writing about that, and announcements of project policy and efforts along those lines, is forthcoming.
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.
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. Continue reading Surprises in clojure.set
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. Continue reading Implementing Metadata in Cloje
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.
Continue reading Cloje 0.1 Post-Mortem
Over the past couple months, I’ve been tinkering with a new side project: Cloje, a clone of Clojure built atop Scheme/Lisp.
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.
Today I tagged version 0.1 of Cloje. This is more of a “milestone” than it is a “release”. If you want to play around with it, you can clone the repository. Installation and usage instructions are available in the README. Future releases of Cloje will be available on each host language’s package manager for easy installation.
Version 0.1 of Cloje includes about 160 functions and macros. Most are reimplementations of basic Clojure features, plus some Java-look-alike functions, and a few additions to fill in some gaps. [Update (May 4): I should mention that Cloje was written from scratch by myself, guided only by Clojure’s public documentation and observable run-time behavior. None of Clojure’s source code was copied, studied, or consulted at any point in the creation of Cloje.]
Tentative plans for Cloje 0.2 include:
- Syntax for maps, vectors, sets, regexps, and more (optional, pick-and-choose which to enable)
- Hash-set data structures
- Lazy sequences
- Implementing the last few clojure.string functions
- Various higher-order functions, map-related functions, and memoization
- Packaging scripts, so Cloje can be made available on each host language’s package manager
Also in Cloje 0.2, I will be changing the primary goal of Cloje. I initially intended to faithfully emulate Clojure’s behavior, with the goal that existing pure Clojure code would run on Cloje. The experience of developing Cloje 0.1 has convinced me that this is not a practical or desirable goal. I’m writing a post with more about this, but for now you can read about the change of goal in Cloje’s goals document. [Update (May 9): The aforementioned post has been published.]
That’s all for now. If you play around with Cloje, let me know what you think!
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!
On Programming Languages and Technologies
On Development and Management Practices
On the Community, Conferences, and Groups
There is a half-jocular saying among atheists, that the surest way for a Christian to lose their faith is to read the Bible, cover to cover. The idea is that if you really scrutinize it, and don’t gloss over the strange, antiquated, or inconsistent parts, it stops seeming so profound and special. I don’t know if that’s really true of Christianity, but I have recently had a similar experience that shook my belief that Common Lisp was a profound and special Lisp dialect.
Continue reading A Personal Lisp Crisis
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. Continue reading Ambienome Brain Dump
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. Continue reading A Rubyist’s Impressions of Common Lisp
This is the second part of my post about what I’ve been working on lately. In the first part, I talked about data structures and serialization. In this post, I talk about the physics engine and object selection via mouse picking.
For Ambienome’s physics engine, I’m using SquirL, a Common Lisp port of the popular Chipmunk 2D game physics engine. I’m not far enough along yet to know how well it performs in my own game, but from running the demos, it certainly seems performant enough for my purposes. If it turns out to be somewhat sluggish, many Common Lisp implementations can perform some pretty aggressive optimization, given the right type declarations. As a last resort, I could create an FFI binding to the actual Chipmunk library, although that might not be any faster than a well-optimized Common Lisp port. One benefit of a binding to Chipmunk would be using its new features that have not been ported to SquirL (which hasn’t been updated in 2 years).
Continue reading Physics Engine and Object Selection