Red Echo

November 30, 2009

MJ just left for home. She came up from Portland on Friday, having spent Thanksgiving with a group of college friends. I always enjoy spending time with her. We joined Barry and Maja over at AND house for an evening of music, spent Saturday relaxing and napping, then went out to the Seelie Court Reunion party at TCoB. I really enjoyed Manahan’s set – and I’m told I missed a great performance from Chadwick by leaving at 3 am. Oh, well – can’t stay out all night every Saturday. Sunday, more chilling out; today, we both worked, then went out for dinner and drinks at Liberty. Nice to have time to catch up.

I haven’t done any actual work on Radian in the last few days, but I’ve posted a few more things on the blog. I feel a little nervous putting my work out further into the public eye, but it really is time to get serious.

November 26, 2009

Downtown, Thanksgiving

New Radian blog

I’ve set up that second blog I mentioned yesterday. I am sure I will continue to make references to Radian here, but I plan to use the new blog for a more in-depth look at the design process. I’m also hoping to get a public source archive up soon; that and other resources will all show up on the new site:

The Radian Programming Language

How do you type non-Latin characters on a standard QWERTY keyboard? In Mac OS, the system hasn’t changed in twenty-five years: holding down the “option” key shifts to an alternate keyboard mapping, where accent characters are “sticky” and combine themselves with whatever letter you type next.

On Windows, the system is so arcane it is functionally useless: you have to hold down “Alt” and then type in a four-digit numeric code, using only the 10-key pad, not the normal number keys!

I’ve never figured out how to do this on Linux before, but apparently the Linux solution is remarkably clever:

You pick a key on your keyboard you don’t use much, like [Insert], [CapsLock], or [menu], and make it the “compose key”.

Then to make any character, you just hit the compose key, then type the two obvious keys that, when combined, make up the character.

November 25, 2009

Dinner with Ava

It’s the dark part of the year, and I’m spending most of my time indoors. I’ve been playing a lot of music, working hard on Radian, and quietly enjoying life at Sunrise and time with Ava. I don’t have any Thanksgiving plans; I’ll probably spend the day at work – the joy of contracting! – then make dinner with Ava. MJ is coming up to visit for the weekend; I’m looking forward to a few days catching up with her.

I’m thinking about putting more of my work on Radian out in public: a public source code archive, I think, and perhaps a second blog, where I can talk my way through the design process in more detail. I’ve been reluctant to put too much of a spotlight on this project yet, since it’s a long way from being a useful tool; but it’s an interesting problem space, and there’s no way it will ever become a useful tool without help from a lot of other people, so it might be time to start opening up.

November 16, 2009

Syntax across languages: samples of corresponding operations in a variety of programming languages.

November 12, 2009

I have just about finished putting together a basic module system for Radian, which will allow programs to span multiple source files. Designing this system was more difficult than I had anticipated; the module system says a lot about developer workflow, so I had to think pretty far ahead about the things I expect people to do with this language and the ways they will likely want to do it.

The module system came about because I want to start building a standard utility library, and in order to do that the compiler needs to link a program together from multiple source files. I want to have some semi-automatic mechanism for linking against the standard library, but it seemed more sensible to build that on top of a generic linking mechanism than to start with the special case and generalize it.

Lessons learned from experiences with other languages:

  • Modules should not be able to define global identifiers. A client program can always import a qualified symbol into its unqualified namespace, but there’s no way to prevent imported global identifiers from conflicting with each other.
  • Source files should import dependencies explicitly. Interpretation of a source file should not depend on any external context, like a project file, an environment variable, or the contents of some shared directory.
  • Support modules should be initialized and finalized explicitly, in the main program, so that the programmer can control the dependency order.
  • The structure of the program should be visible in the filesystem. Don’t trip people up by introducing a parallel-but-different structural hierarchy.
  • Makefiles are evil. The language must allow the programmer to describe the program in such a way that the compiler can identify all of its parts and build a finished executable in one step.

The system I’ve built works like this. You invoke Radian on a program file; this is equivalent to the “main” function in C. This program file may import module files, which may in turn import other module files, using the import statement:

import foo

This statement declares the name “foo”, representing the contents of the file “foo.radian”, which the compiler expects to find in the same directory as the client file. Imports are simply placeholders, to be resolved at link time, so circular references are not a problem.

The Radian compiler treats the contents of an imported module file as the body of an object declaration. The top-level functions and other declarations in the file become the members of the imported object. A source file cannot simultaneously be a program and a module, since only a program file gets the implicit “io” variable allowing interaction with the rest of the system.

That’s all I’ve built for now. As far as the standard library goes, I think I’ll throw an implicit “radian” import into the top-level namespace of every file. All of the standard utilities will be members of this namespace – much like “std” in C++. This will allow me to extend the standard library in future versions without introducing name conflicts. To make this more convenient, I want to extend the import statement, like Python but in a more sensible order:

import stack from radian

This would define a new item named “stack”, equal to “radian.stack”; you could extend the “from” expression arbitrarily to handle deeper nesting. You wouldn’t have to have imported the “from” identifier on its own; you could import only the item you wanted and leave the rest of the package unimported.

Proceeding onward, I expect that you’ll be able to treat subdirectories as modules – if you had a subdirectory “foo” next to your program file, containing a module file named “bar.radian”, you could import it like this:

# get access to the module file only, resulting in 'bar'
import bar from foo
# import the whole directory, resulting in ''
import foo

I’ll need to design a package system as well, but that is still some distance ahead. It’ll probably look something like python’s packages, which remind me of Mac OS X bundles. I am fairly well convinced that the convenience of a standard central package directory is outweighed by the configuration hassles and dependency tracking issues, so I think I will require packages to be included in the project folder. If people want to keep a central repository of useful libraries, or several such repositories, they can always make a softlink/alias into the project folder.

November 7, 2009

Performing at Seacompression

November 5, 2009

music workstation

I am playing at Seacompression!

Michael H. called up last night, wanting to know if I was interested in the opening slot at Seacompression. Well, heck yeah! Seattle’s biggest burner party, hundreds of people and a huge PA system? No way am I turning that down. So I’ll be playing from 7 PM til 7:45 this Saturday, the 7th. Seacompression is going to be in Hangar 30 at Sand Point (aka Magnuson Park); tickets are $20 presale, $30 at the door.

Yeah, it’s early, so I’m not expecting a huge crowd – but man, this is exciting. Come see me play! I can’t wait to crank it up and try to make you dance.

One improvement I made when redesigning my music machine was to add a compressor, right at the end of the signal chain, to help manage the overall dynamics. It happened to be that one-in-ten craigslist item that simply didn’t work, so I’ve been getting along without it, but the replacement arrived yesterday and I’m really glad I stuck with the idea.

Practically all the music you hear has been passed through a compressor: you can make as loud a noise as you want when you are playing an acoustic instrument, but there is an upper limit when you are playing through a PA system, and exceeding that limit will create distortion. The problem is that music can be very “peaky”, especially dance music: the loud bits, like kick-drum hits, are very much louder than the quiet bits. Turning the overall level down far enough to avoid distortion leaves the body of the mix sounding quiet and anemic. The solution is to compress the dynamic range, reducing the difference between the loudest and the quietest parts of the signal: this is the job a compressor does.

So why is this important for my music machine? When a DJ spins a record, they’re reproducing a signal that has already been compressed during the recording/mixing process. The DJ can set a nice hot level for the overall sound and rest assured that the peaks have already been tamed. I don’t have this luxury: since I’m making music from scratch, I have to manage levels by hand as I go, and I generally have to leave the overall level lower to make up for the peaks. This is fine for ambient and downtempo stuff, but when I try to play louder, thumpier, more uptempo music, I end up doing a lot of work riding the level knobs without having much to show for it.

The compressor, then, lets me delegate one more tedious job to a happy little robot, yielding a clean, consistent, punchy sound. And it works! I fired it up this morning and spent a few minutes playing before work. Drums, hats, bass, lead, pad, arp – build ’em up, break ’em down, crank it, back off – the sound stayed nice and full and clean. Yes! This is exactly what I wanted.

November 4, 2009

This essay certainly contradicts the prevailing wisdom, but it makes some reasonable points. It’s OK Not to Write Unit Tests:

I’m not saying that all unit tests are worthless, nor that you should never write one ever again. But I am suggesting that you take a good hard look at the time you’re spending and ask yourself what benefit you are really deriving.

What I’m saying is that it’s okay if you don’t write unit tests for everything. You probably have already suspected this for a long time, but now you know. I don’t want you to feel guilty about it any more.

Test what can fail. Test stuff that’s easy to test. But don’t beat yourself up trying to get 100% code coverage. 100% code coverage doesn’t mean all that much, anyhow.

November 3, 2009

Awesome: a visit to the imaginary town of Argleton, which shows up clearly on Google Maps despite not actually existing. Current best theory is that it was inserted by Google’s data provider as the equivalent of a trap street.

The possibility of actually visiting an imaginary place seemed irresistible. In terms of my journey, not to go there would be a dereliction of duty, like saying ‘I could have made a detour to Rock Candy Mountain’ or ‘Tir-nan-Og’, ‘but I decided to press on directly to Maghull instead’. So today I decided to make the expedition – from the world we know to a fictitious and uncertain place.

Reaching non-existent lands can be accomplished in many ways, but I decided to use Google itself to navigate to this one. After all, they invented it.