Manifest Density - recent comments

Tom comments on after Twitter

2009-07-02T17:52:07-05:00

Naw, man. I've been rocking ossification for years. If you want to call me out, though, I had a pretty inexcusable use of "pullulate" a few posts ago.

Daniel M. Laenker comments on Harlem Shakes / Passion Pit

2009-07-06T10:19:08-05:00

Year of Earnest Music Composed in Cabins

I'm kind of confused. Would this have something to do with Grandaddy, or...?

Tom comments on Harlem Shakes / Passion Pit

2009-07-06T10:40:23-05:00

No, more like Bon Iver or Fleet Foxes. I like Grandaddy! Thanks for reminding me of them -- I lost my copy of the Sophtware Slump years ago and really need to find an MP3 version.

Daniel M. Laenker comments on Harlem Shakes / Passion Pit

2009-07-06T11:22:46-05:00

Year of Earnest Music Composed in Cabins

I'm kind of confused. Would this have something to do with Grandaddy, or...?

Wes comments on GTFS and NextBus don't match up

2009-07-06T12:59:17-05:00

Could the Lat and Long descrepancy be explained by NextBus putting the bus stop on the street (as that's where buses stop, and they're tracking buses) while WMATA puts the stop on the sidewalk, where the shelter or the flag goes?

Tom comments on GTFS and NextBus don't match up

2009-07-06T13:14:45-05:00

That's a good suggestion, and one I'll have to investigate more thoroughly. But based on the one or two stops I've examined, I think the answer is "no". And worse, the distances make it look unlikely -- only a handful of the matches I generated (see here and here) are within 10m of the corresponding GTFS stops. It's weird -- right now my best guess is that NB may be using a different coordinate projection system (although the fact that I got these coordinates out of their google map system would make that very strange indeed).

Dylan Matthews comments on iphone/nextbus progress

2009-07-09T00:56:47-05:00

But it has all the memory safety of C combined with all the blazing speed of Smalltalk! What could go wrong?

Justin comments on iphone/nextbus progress

2009-07-09T01:09:05-05:00

Cool... neat to see you working on iPhone stuff.

But: P.S. Objective C suuuuuucks -- really?

I'm honestly curious why you think so. I'll admit I haven't programmed any other compiled languages except for straight C, but I've been doing Cocoa for about five years and really enjoy Objective-C, Cocoa or no.

Justin comments on iphone/nextbus progress

2009-07-09T01:10:25-05:00

Cool... neat to see you working on iPhone stuff.

But: P.S. Objective C suuuuuucks -- really?

Justin comments on iphone/nextbus progress

2009-07-09T01:12:27-05:00

Hmm, sorry about the double comment, but I got an HTTP 500 after submit instead of a redirect.

Tom comments on iphone/nextbus progress

2009-07-09T09:40:47-05:00

The double comment's my fault -- I'm not sure where those 500 errors are coming from, but they're appearing fairly frequently. I really need to move this site to Wordpress.

The thing I don't like about Objective C is mostly just that it's confusing. Which isn't the language's fault, necessarily, although it could certainly be a bit nicer about it. I remember string manipulation in C++ being a total pain in the ass, too, so it's likely that I'm just cranky about going back to a compiled language -- any compiled language.

With that said:

* For beginner stuff, the strongly-typed-but-not-really nature of things just means your app will unexpectedly crash instead of the compiler yelling at you first

* The crash reporting leaves a lot to be desired. Did the iPhone simulator just disappear unexpectedly? Is the debugger just showing some unhelpful bit of assembler? Time to add a bunch more NSLog()s!

* I've been pretty unimpressed with the documentation. I've gotten to the point I'm at through a combination of Apple's materials, the O'Reilly SDK book, 4 or 5 hours of the Stanford iTunes U class, and tons of googling. None of them has felt like THE introductory text (the Stanford thing is the best of the lot, but it's video, and therefore a pretty terrible way to learn programming). Interpreted languages' communities are just a million times better at this stuff for whatever reason.

* I've already learned and completely forgotten how reference counting/autorelease works. I'm positive I'm going to have to completely revamp my app to plug leaks once its basic functionality is complete.

* This isn't about Objective C per se, but while the SDK seems very well-designed in general, the map stuff has a couple of extremely lame aspects to it. In particular, they really only want you to do point-type annotations. If you want to draw a region or a vector on the map you're going to need to drop another transparent view on top of it, pass through all the touch events and deal with keeping the scale and position in sync. It's kind of a nightmare. At least, that's my understanding of it at this point.

Justin R. Miller comments on iphone/nextbus progress

2009-07-13T18:46:46-05:00

Cool, thanks for the detailed reply.

For beginner stuff, the strongly-typed-but-not-really nature of things just means your app will unexpectedly crash instead of the compiler yelling at you first

Yeah, this can happen more frequently. Recommend getting absolutely zero compiler warnings, or treating warnings as errors, to help with this. But yeah.

The crash reporting leaves a lot to be desired. Did the iPhone simulator just disappear unexpectedly? Is the debugger just showing some unhelpful bit of assembler? Time to add a bunch more NSLog()s!

Crash logs might help with this.

I've been pretty unimpressed with the documentation. I've gotten to the point I'm at through a combination of Apple's materials, the O'Reilly SDK book, 4 or 5 hours of the Stanford iTunes U class, and tons of googling. None of them has felt like THE introductory text (the Stanford thing is the best of the lot, but it's video, and therefore a pretty terrible way to learn programming). Interpreted languages' communities are just a million times better at this stuff for whatever reason.

Yeah, I hear that. I love the Apple docs now that I know Cocoa, but it's not what I learned off of. And I think iPhone in particular was hampered by several months of NDA out of the gate.

I've already learned and completely forgotten how reference counting/autorelease works. I'm positive I'm going to have to completely revamp my app to plug leaks once its basic functionality is complete.

This is just one of those Cocoa things you have to master. The two basic rules are: 1) if you use a method with alloc, new, or copy in it, you need to release, and 2) if you need a variable around beyond the current scope, you need to retain it, then release it when you're done in the other place(s).

This isn't about Objective C per se, but while the SDK seems very well-designed in general, the map stuff has a couple of extremely lame aspects to it. In particular, they really only want you to do point-type annotations. If you want to draw a region or a vector on the map you're going to need to drop another transparent view on top of it, pass through all the touch events and deal with keeping the scale and position in sync. It's kind of a nightmare. At least, that's my understanding of it at this point.

I've only done a bit with MapKit, but yeah. It's a 1.0. You can file a Radar on it, though, for later releases.

Tom comments on iphone/nextbus progress

2009-07-13T19:16:13-05:00

Thanks for writing back -- this is extremely helpful. Your explanation of the rules for memory management is the best I've seen!

Justin comments on iphone/nextbus progress

2009-07-14T00:39:23-05:00

There are a couple other subtleties to memory management too, but the same two rules apply. Here's an example.

Say you have an instance variable that's a (let's say mutable) dictionary that holds some certain data through the life of the app.

Say you then make a new object [[NSObject alloc] init] and add it to the dictionary.

If you look closely at the docs for NSMutableDictionary, it tells you that objects get retained when added, so that they are guaranteed to stay around. So if you want the object to disappear when the dictionary is done with it, you would release it right after adding it to the dictionary. You create it (retain count 1), add it (retain count 2), and release it (retain count 1). Dictionary releases it (retain count 0) and thus frees it.

But again, same rules apply -- just need to know that some methods retain things when they are needed. For data-type objects, arrays and dictionaries are the main ones to remember.

While the alloc-new-copy rule helps you remember when you need to be responsible for a release. one more way of looking at retain counts is useful (this, by the way, is from the Hillegass book).

Think of retains as leashes & collars around the neck of a dog. Everyone who wants to make sure the dog sticks around puts a leash & collar on it (retain). When you don't care anymore, you remove the collar (release). When no collars are left, it runs away.

So an array/dictionary retains, then when it's done, releases.

Nicola comments on how else can you explain carbon fiber?

2009-07-20T15:24:05-05:00

Check out "The Morning of the Magicians" (Pauwels and Bergier) or "The Spear of Destiny" (Ravenscroft) for the origins of the Nazi occult myths. Also, try "Black Sun" (Goodrick-Clark) for an academic overview of the genre...