More of a programming nerd than is strictly healthy. See also {nevyn.nu, thirdcog.eu, twitter}

Projects

Overooped

Faking generics in ObjC

If you have every touched C++, Java or C# and then moved to Objective-C, you have at some point written one of the following in a source file:

NSArray/*<MyThing>*/ *_queuedThings;
NSDictionary *_thingMap; // contains MyThing
-(MAFuture*)fetchThing; // wraps a MyThing

With TCTypeSafety, you can write pretend that you’re writing in a language with generics and write:

@interface MyThing : NSObject
...
@end
TCMakeTypeSafe(MyThing)

(later...)
NSArray<MyThing> _queuedThings;

Why?!

Assume that we have some kind of Future class. Assume also that we have a factory that returns Futures that wrap the asynchronous creation of a MyThing. We might want to define the interface for such a factory like this:

@interface MyThingFactory : NSObject
- (TCFuture<MyThing> *)fetchLatestThing;
@end

Later, when we use the factory:

MyThingFactory *fac = [MyThingFactory new];
NSString *thing = [fac fetchLatestThing].typedObject;

… actually generates a compiler warning, since typedObject returns MyThing, not NSString. (Note that we did not have to give TCFuture knowledge of the MyThing type to get this benefit, or modify it in any way except make it TCTypeSafety compatible).

This way, we can ensure that even though we have wrapped our MyThings in a TCFuture, we haven’t thrown away type safety, so that if we want to change the return type of fetchLatestThing, we can just do so in the header and then fix all the compiler warnings, rather than going through every single usage of fetchLatestThing and fix any now invalid assumptions on the return type.

This is also useful for collections such as arrays and dictionaries:

NSMutableArray<MyThing> *typedArray = (id)[NSMutableArray new];
[typedArray insertTypedObject:@"Not a MyThing" atIndex:0]; // compiler warning! NSString ≠ MyThing
NSNumber *last = typedArray.lastTypedObject; // compiler warning! NSNumber ≠ MyThing
NSLog(@"Last typed thing: %@", last);

What?!

The syntax for indicating protocol conformance of a variable is the same that you would use for template/generics specialization in other language. Also, the namespace for protocols is separate from the namespace for classes, so we can have a protocol with the same name as a class. So if we implement a protocol with getters and setters that take and return the type that we are interested in, we can get type safety. For example, we can create the protocol MyThing as such:

@protocol MyThing
- (MyThing*)typedObjectAtIndex:(NSUInteger)index;
- (void)addTypedObject:(MyThing*)thing;
@end

We then need to add support for these methods to NSArray and NSMutableArray. However, the type we are specializing on is only a compile time hint and does not affect the type of the instance, so in the implementation, we can just say that these return ‘id’.

@implementation NSArray (SPTypeSafety)
- (id)typedObjectAtIndex:(NSUInteger)index;
{
    return [self objectAtIndex:index];
}
@end

@implementation NSMutableArray (SPTypeSafety)
- (void)addTypedObject:(id)thing;
{
    [self addObject:thing];
}
@end

Tada! Write a macro that generates this protocol for you (like, say, TCMakeTypeSafe), and you have instant type safety.

There must be downsides.

Absolutely. You can only “specialize” on a single class: you can’t create some generic facility that would let you specialize both the key and the value of an NSDictionary. You have to use weird selectors such as -[NSArray typedObjectAtIndex:], since the protocol conformance sadly does not override the method signature for your array instance, and using -[NSArray objectAtIndex:] will still give you type-unsafe return values.

Worst of all, by applying the TCMakeTypeSafe macro on your class, it will suddenly look like it has the interface of both a to-one accessor, NSArray, NSDictionary, and whatever else you add support for in TCMakeTypeSafe. Thus, you wouldn’t get compile time warnings if you changed your NSArray into an NSDictionary, as you normally would. I think this trade-off is worth it, but I’m not sure.

Where can I get it?

At nevyn/TCTypeSafety at GitHub.

Update: turns out Jonathan Sterling had almost exactly the same idea only a few days ago.

Subtextual notation

We’re still writing code as if on a teletype, and still feeding it to a black-box compiler, and getting magic out. There must be a more visual approach, that’s faster to code in than ascii, more succinct, giving you a better overview, an IDE that talks to you. I’ve been hunting for a visual programming language for a long time, as you probably know. Heck, I even wrote one (no, that’s not Quartz Composer).

So of course I had to back Light Table when I saw it. I can’t but feel that Chris Granger’s project is overambitious and too broad to build something general and practically useful, but it’ll be a very interesting journey.

While researching Light Table, I ran into Jonathan Edwards’ thoughts on it, “An IDE is not enough”. He’s been working on a visual programming language of his own, called Subtext. He’s chosen a very specific problem—conditionals—and extrapolated a language from that. I’m really not sold on his visual representation, nor the incredibly mouse and context menu-heavy interface, but I really like the idea and the thoughts behind it. While waiting for the revolution, give your brain something to chew on with the embedded video below the quote.

Much of the design of our programming languages is an artifact of the linear nature of text.

Jonathan Edwards in his Subtext 2 presentation

The hackbook project is alive! Or at least limping around. Finally got myself a cheap pair of Vuzix Wrap 920 head-mounted displays. Wearable computer + monitor, check! The stereo vision in them is horrible, but I only want to use one of the screens so that I can see my surroundings anyway, and on its own one of those screens is actually pretty decent. Haven&#8217;t dared to open them up further to see if one of the monitors can be detached yet, tough&#8230; Don&#8217;t have any input devices yet, either.

The hackbook project is alive! Or at least limping around. Finally got myself a cheap pair of Vuzix Wrap 920 head-mounted displays. Wearable computer + monitor, check! The stereo vision in them is horrible, but I only want to use one of the screens so that I can see my surroundings anyway, and on its own one of those screens is actually pretty decent. Haven’t dared to open them up further to see if one of the monitors can be detached yet, tough… Don’t have any input devices yet, either.

Fantastic and beautiful conclusion to Everything is a Remix, by Kirby Ferguson.

You can’t discover anything if you can’t see what you’re doing.

The above presentation by Bret Victor is amazing, and I couldn’t stop tweeting about it the other day. My mind was blown at:

4:20. cool! I mean, I’ve seen live editors before, but I never thought of actually using sliders on numbers. Clever! I remember now though, that this has been done by Codea (and probably others) before.

5:25. What. That changes the way I think about programming visual things. I keep thinking of all the times I’ve tweaked an animation or gradient, recompiled, redeployed to device, and get to experience my change maybe a full minute later. How many solutions have I missed, had I just been able to drag a slider to try variations?

I’ve tried to come up with solutions to this problem several times before. My first try was RemoteParameter. However, it is incredibly clumsy to integrate into the code being modified: modified variable must be KVO compliant, it only works for a single spot in the code (so it will fail if you’re e g modifying the background color for all cells in a list), and the editor UI is atrociously bad.

My second try was with NuRemoter. This tool I still actually use, and is somewhat useful in working with living code (sending calls in the middle of animations, debugging time sensitive operations, etc). However, it is not at all visual, and any code I improvise in the NuRemoter UI will be in Nu, which I can’t use as-is in my project without rewriting it into ObjC. I have a few thoughts here, though: first off, I should make it easier to hook Nu code into our code base, so that things that are naturally expressed in a script-y langage, can be. Secondly, the NuRemote protocol can be used as a payload delivery system for other tools. For example, if I ever write an animation construction kit, I could use NuRemoter to upload and inject animation descriptions into the app, and immediately try them out. (I’ve thought of integrating it into my Localizer localization app, too).

Wait, animation construction kit? Well, Core Animation is incredibly powerful and easy to use, but expressing animations in code is both unintuitive and slow (see: write/compile/deploy/test cycle), and maybe tobi is a better animator than me? I want something like the GLSL Shader editor: define input parameters (perhaps start and end locations, duration, intensity) and a sample image as a placeholder for the UIView being animated, and then define animations Keynote-style, possibly with values substituted for parameters. Output a json file, load it at runtime and use it instead of all the animation code. Shouldn’t be THAT hard to build?

6:10. My jaw drops just a tiny bit further, but enough to mark the time. Well, typing autocompletions into the autopreviewing document so that they run automatically is pretty obvious, but I love the idea of showing you what the thing does, rather than having you read documentation. Maybe the right sidebar in Xcode should have movies instead of help snippets?

7:43 and 8:12. How the hell did he do that‽

11:30. Again, how did he do that‽ He’s obviously not re-evaluating the whole file on each change. Maybe he’s been careful when writing the file so that it can be re-evaluated in the context of the currently “running” web page/js-vm? It looks like an incredibly nice way to code games, though. A little bit like Unity I guess; I remember having my mind blown the first time I saw that editor, too.

13:00 and 14:10. Now he’s just showing off. Surely this editor must be specifically written for this game engine he has constructed, and not something generic. Still want that code+editor, though!

Around 16:00 he re-iterates again how easy it is to be creative when you can visualize your results live, and how it doesn’t just apply to visuals or animations, but entire gameplay ideas. I’m so very sold on the idea.

Around 20:00, I really love the idea of supplying sample input data and see how that affects the code you just wrote.

Around 26:00, I should’ve realized that this is the same guy as the one who made That Math Video that blew my mind pretty thoroughly last year. I didn’t, until I checked his web site in preparation for this blog entry. He has plenty of new interesting entries there, if you haven’t checked them out lately.

However, out of all of these, the moment that perhaps isn’t the most interesting to me as a programmer, but never the less tipped me over from “yes, I am impressed” into a squealing, giggling pile of fanboyism, is 31:30. Probably the most amazing animation editor I’ve seen, and probably the most intuitive power user UI I’ve seen, and it’s just an experiment he made? MIND BLOWN.

I love how, instead of trying to solve the problem of tiny hit targets with giant thumbs, he has the user select the layer with her left hand, while manipulating it with her right. It’s a touch surface, and the user has two hands: why is nobody else using this fact‽ (my mind was similarly blown in ‘05 by the same multi-hand usage by TactaPad, which sadly never became an actual product).

Compositing all the different animations the user wants to get into the scene by just scrolling back time and immediately performing the next animation is equally genius (also seen, but not at all as well implemented, in Garageband.). Just look at the amazing speed at which he composes that scene!

However, out of all the amazing things Bret is showing us, none are as inspiring as his outro. Ever since I started programming, I’ve felt an idea or principle just at the edge of my consciousness. I know it’s related to creating a user interaction paradigm that is more natural, but I can’t describe it more clearly than that. I just know, for example, that multitouch is a step in the right direction. I haven’t thought about it too much in the past two years as I’ve been busy at Spotify, and Bret’s note at the end that doing only one thing will not give you insights really hit home.

Alright, enough gushing. I hope that after all that, you did actually watch the video, and that you found as much inspiration as I did. Right now, I just want to stop everything I’m doing and take a few months off life and make tools. I should probably finish a few projects first though…

Rapid network protocol prototyping with TCAsyncHashProtocol

github:TCAsyncHashProtocol. I like constructing simple network protocols from plist/json-safe dicts, and transmit them over the wire as json. Easy to prototype with, easy to debug. Give TCAHP an AsyncSocket, and this is what it’ll do for you, plus support for request-response, and arbitrary NSData attachments.

It is an embarrassment and almost an insult that my example project is a massive 200 lines. I hope to be able to reduce the verbosity and boilerplate clutter of using TCAHP without making it heavy-weight. At the very least, I recommend that you use SPLowVerbosity.

An example of using TCAHP to send a request to update the server’s MOTD:

[_proto requestHash:$dict(
    @"command", @"setMessage", // the command is 'setMessage'
    @"contents", msg // Send 'msg' as the new message to set.
) response:^(NSDictionary *response) {
    // The server has replied.
    if([[response objectForKey:@"success"] boolValue])
        NSLog(@"Successfully updated message!");
    else
        NSLog(@"Couldn't set message, because %@", [response objectForKey:@"reason"]);
}];

And on the receiving side:

-(void)request:(TCAsyncHashProtocol*)proto setMessage:(NSDictionary*)hash responder:(TCAsyncHashProtocolResponseCallback)respond;
{
    NSString *newMessage = [hash objectForKey:@"contents"];
    if([newMessage rangeOfString:@"noob"].location != NSNotFound)
        respond($dict(
            @"success", (id)kCFBooleanFalse,
            @"reason", @"you should be kind!"
        ));
    else {
        _message = newMessage;
        respond($dict(
            @"success", (id)kCFBooleanTrue
        ));
    }
}

(Note the latest piece of magic that I added, where the selector of the delegate method is created based on the value of the key ‘command’ in the message. I quite like it.)

As you can see, the resulting protocol is very weakly typed. In theory, this means you will be making typos and not understanding why the hell your network seems broken; in reality, I’ve never had that problem.

“If you are going to end up with a crappy to mediocre blender anyway, then why bother spending more or availing yourself of the advice and service of a specialty retailer? Reducing the overall quality of products thus destroys a key competitive advantage of Walmart’s smaller rivals.”

— Is your stuff falling apart? Thank Walmart (grist.org). yay for progress?

“By categorizing our cognitive flaws, documenting not just our errors but also their embarrassing predictability, he has revealed the hollowness of a very ancient aspiration. Knowing thyself is not enough. Not even close.”

— Is Self-Knowledge Overrated? at the new yorker. not very surprising, but sort of confirms that everyone’s an idiot, not just me :P

I&#8217;ve been trying to build a wearable computer since forever, but I sort of got stuck because there aren&#8217;t (or I can&#8217;t find) any good HMDs (head-mounted displays) that don&#8217;t cover your entire field of vision (covering just one eye is fine, but being see-through would be the best, of course). I&#8217;ve had a Google Alert on the AirScouter for a year or so, and it seems they&#8217;re finally releasing them in some sort of product. I want one *so badly*, but they&#8217;re targeted at industrial application and priced thereafter, at $5200 :( I may be a huge frickin&#8217; nerd, but I can&#8217;t really justify spending that kind of money on yet another hobby project…

I’ve been trying to build a wearable computer since forever, but I sort of got stuck because there aren’t (or I can’t find) any good HMDs (head-mounted displays) that don’t cover your entire field of vision (covering just one eye is fine, but being see-through would be the best, of course). I’ve had a Google Alert on the AirScouter for a year or so, and it seems they’re finally releasing them in some sort of product. I want one *so badly*, but they’re targeted at industrial application and priced thereafter, at $5200 :( I may be a huge frickin’ nerd, but I can’t really justify spending that kind of money on yet another hobby project…

Reblogged from The Daily What