I was reading a post written last year by Phil Hagelberg (technomancy) about his switch from SLIME to nREPL. And something really fantastic occurred to me. Bear with me as I explain.
First he describes the problems with swank-clojure:
Nobody really understood the ins and outs of the project ... Part of this was because it was just a really old quirky codebase ... but part of it was because it was a fairly literal port of the Common Lisp server.
Then he expresses his doubts about nREPL taking its place:
While I appreciated the idea, I thought that it would be a long time before Emacs support for it could catch up to the level of functionality in SLIME.
This looks like it's only about nREPL, but there's a hidden assumption at work: "A replacement for ___ with the features I need will take too long."
After a short while, nrepl.el begins to take form, and he describes his experience using it:
The main thing I've noticed about it is how accessible the codebase is; I've found it very easy to dive in and add features. So even though it's still missing a few things that SLIME boasts, it's on course to improve at a steady pace.
That's it! Do you hear the surprise in his voice? His assumption was proven wonderfully wrong by the evidence.
It was just the wrong solution, that was the real problem all along! We tried to take a solution that worked for Common Lisp, and jimmy-rig it to work for Clojure. But Clojure isn't Common Lisp. And 2012 isn't 2003.
Our requirements are different now. Our code should be too.
In other words, when we approach a problem, we need to strip away assumed requirements until all we have left is actual requirements. The actual requirements are usually much smaller and simpler than we think. And often, the quickest and safest route to meeting them is to start from scratch.
I've put this idea into practice. In 2013, I've written:
- an intuitive window manager
- a super-flexible window manager
- a simple music player
- a version of clojuredocs.org that's updated for Clojure 1.5
- a Clojure-like programming language for embedding in ObjC apps
- a Clojure IDE
- a new window manager that's scripted in my own programming language.
It's not that I'm a great programmer or anything. I'm pretty average actually. And it's not like I'm coding all day and night, either. It's just that I looked for the actual requirements in all these problems, and they turned out to be deceptively simple.
I wonder what other tools we use that we can vastly improve if we get rid of assumed requirements?
Update: I think Richard Stallman just helped prove my point.
My name is Steven Degutis, and I've been writing software professionally for a decade. During that time, I've written many apps and websites, quite a few technical articles, and kept up-to-date with the rapidly evolving software industry.
If you have software needs for web, mobile, or desktop, and are looking for a seasoned software professional, please reach out to me at firstname.lastname@example.org to set up a phone call.
- Self-employed – present
- Clean Coders – 5 years
- 8th Light – 2 years
- Big Nerd Ranch – 1 year
- Self-employed - 1 year
- Web: full-stack
- iOS (UIKit)
- macOS (Cocoa)
- REST APIs
- AWS / EC2 / ELB
- HTML5 / CSS
Over the past decade, I've written a total of 169 technical articles on various programming languages, frameworks, best practices, and my own projects, as I kept up-to-date and active in the software industry.
Subscribe via RSS / Atom.
- 2017 — "Clean code" isn't actually clean
- 2017 — Passion in your field is overrated
- 2017 — What I learned in 5 days of writing an experimental website
- 2014 — Age of the Polyglot
- 2013 — How to Program
- 2013 — Ignore the Naysayers
- 2013 — Writing Clearly
- 2012 — Reinvent the wheel
- 2010 — Good usability
- 2009 — Twitter is the wrong tool
- 2009 — We're all pretty bad at driving
- 2008 — Why I Code
|March||Notes on Haskell Extensions|
|February||Second thoughts on front-end tools|
|February||First thoughts on front-end tools|
|February||Some thoughts on GUIs|
|February||First thoughts on OCaml|
|February||First thoughts on Haskell|
Here are some of the projects I'm most proud of. They were created using a variety of technologies, running on several different platforms and OSes. They're all finished products, and many of them are open source.
I made Docks in 2009 for users who wanted to swap out icons in their Dock with a single click. Its unique functionality and design aesthetic attracted the attention of Apple, Engadget, MacWorld, and led to an acquisition of my start-up by Big Nerd Ranch.
This toy was made in a weekend to entertain my 1 year old daughter. It lets you create bubbles with your fingers, which then simulate physics by bumping into each other and falling.
When I couldn't find an app in the App Store that let me make very simple lists extremely quickly, I made one myself. I use it almost every day to organize and track my activities.
I created this app to increase my productivity by letting me move windows around in macOS using keyboard shortcuts. It grew into a community-driven highly extensible app, using Lua for its plugin system.
Implementing this elite social network gave me experience integrating both Apple Pay and credit card payments (via Stripe.com) seamlessly into web apps, for a frictionless and pain-free payment experience.
This isn't just any chatroom. In this web app, you can see what everyone is typing while they type it. I made this in order to scratch my itch for making real-time apps and games, and learned how to use WebSockets in the process.
This was written in 2009, before the time of Slack, when IRC was the main way for programmers to get short-term assistance from each other. Its purpose was to be a beautiful app with an emphasis on simplicity and usability over technical power.
This is an app I actually use every single day. It lets you move windows with global keyboard shortcuts. Since it uses Vim-like key bindings, it should feel pretty natural to any programmer. There's no configuration needed; it Just Works™.
As an evolution of Phoenix, Hydra was my first attempt at embedding a full Lua virtual machine into an Objective-C app, to make a lightweight and efficient window manager that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.
These may be tiny, but they're interesting technical feats.
|Lua4Swift||Swift framework for embedding Lua with a native Swift API.|
|choose||Command line fuzzy-matching tool for macOS that uses a GUI|
|music||Command line music daemon for macOS that only speaks JSON|
|hecto||Command line text editor with an embedded Lua plugin system|
|ZephSharp||Window manager for Windows using Clojure for scripting|
|management||Minimalist EC2 configuration & deployment tool in Ruby.|
|go.assert||Assertion helper package for writing tests in Go.|
|go.shattr||Go library for printing shell-attributed strings to stdout.|
|OCDSpec2||Objective-C based testing framework with Xcode integration.|