Spot any errors? let me know, but Unleash your pedant politely please.

Saturday, 14 March 2009

Scratch from MIT

My son, who is in year 6, has expressed some interest in programming (like lots of kids, he wants to be a games designer). I tried getting him interested by introducing him to Python. I thought he could get used to the language and OOP, without getting heavy with strong typing, verbose, unclear languages. Python gives fairly quick results (faster, probably if you don't use is like an Ada jockey who knows a bit of Java)

I'd looked very briefly at PyGame, and figured that it would be relatively easy to pick up.

Last week though, I followed a link to scratch, and it was very obvious that this was the place to start. I think I was right. I showed it to my son this morning, and with a little guidance, he finished writing a version of Pong today.

There are some aspects of scratch that I think could apply to a real IDE. Drag and drop constructs, statements, objects etc may b e a simplification too far, but the graphical representation of them seems a lot better than simple code colouring …
Scratch 1.3.1 (release of 21-Nov-08)
Uploaded with plasq's Skitch!

OK, it's little fisher price, and would need toning down in a real IDE, but it's also clear about what belongs where. It shows scope very well. It's not unlike Python's indentation based scope, but also more explicitly shows the end of the scope of a block with no additional code . There's no reason that this graphical representation couldn't be live generated while typing in a 'real' language. Something like this…
length.py
Uploaded with plasq's Skitch!

might look like this…
Untitled
Uploaded with plasq's Skitch!

There'd be a problem with the code becoming illegible in deep blocks. (exaggerating)…
Untitled
Uploaded with plasq's Skitch!

I think there's an advantage though. If the code is 15 or 20 levels deep in a single file/class/method/function, then there's some bad design going on there, and it should be refactored. The opacity would become a useful visual representation of the readability of the code.

Why the iPod Shuffle is broken

Having pondered the new (3rd gen) iPod Shuffle for a little longer, I think it's broken. I want it to fail. I want everyone who fancies one to reject it. There are two reasons. One I'd mentioned before, as a nitpicking detail: no control on the device itself. the second reason is that there's bloody DRM in the headphones. What it means is that only authorised manufacturers can make replacement headphones or extension cables that include the utterly necessary controls. The little inline remote has an authentication chip in it.

I don't object to the inline remote. I don't object to Apple selling a chip to other vendors that allows them to send the requisite signals to the device to control it. Plenty of devices have proprietary controls like this. Think TV remotes, for example. What I object to is doing this while having no controls on the device itself. Why ? It just feels broken. Headphones go missing, get trodden on, go missing down the back of the sofa. Having the player break at the same time is an appalling design decision. It's either stupid or greedy.

In programming terms, the shuffle ad its controls are highly coupled. They're so highly coupled that they should be one unit.

I've experienced the problem that Apple have introduced to an extent with a couple of televisions. Al functions are accessible from the TV remote, but not all functions are accessible from the buttons on the TV. This is a broken interface. A device, whether it is a tiny MP3 player or a big TV should still work fullywithout the remote, even if the interface by which its functions can be accessed without the remote are less convenient / more fiddly.

Edit: some doubt has been cast on whether the EFF and ilounge reports on the chip in the headphones has anything to do with DRM / DMCA. Maybe they're just trying to grab headlines.

Wednesday, 11 March 2009

Thoughts on the new iPod Shuffle.

The voices on the new iPod Shuffle are different for Tiger, Leopard and Windows.

I suspect that the voice isn't produced by the shuffle from the tag text in the sound files. I think it's added by iTunes as audio. This audio could be embedded as a new tag or it could be added as a separate resource file. I assume it'll take a while to process a whole library to add this data.

Edit: the Shuffle needs a new version of iTunes. I think this supports my hypothesis about the metadata.

Overall impression is good, but I'd like to pick some nits nits...

The control is on the headphones. What if you want to use other headphones ? (I never had a problem with the headphones that came with my old iPod, but the ones that came with my new one simply don't stay in my ears).

The control is on the cable for the right ear. What about the sinister left handed people. It would make more sense to have this on the main cable before the split.

The obvious fix is for some third parties to make a cable with an inline control and a headphone socket. The problem that introduces is that the combined cable will be too long, and the position of the control in that length of cable might not be ideal. Of note, the last pair of Sony headphones I bought came with a very short cable (about 18"), and an extension cable which adds another 2 feet.

Tuesday, 10 March 2009

Touch based tablet from Apple.

Maybe.

Think iPod Touch, but with an 8" display. All the better to surf with. Won't be much thicker

Will be a Touch device. Will use the app store. Apps will be full screen. Will not have a desktop.

Macintosh tablet

Ain't gonna happen.

Apple NetBook

Ain't gonna happen.

Monday, 9 March 2009

Am I writing Java in Python ?

That's what's bugging me today. Or rather Am I writing is like an Ada programmer would write Java ? It's going through too many filters.

It doesn't really matter, but I've been writing stuff as methods of classes, and maybe they could just be functions. I suspect my code is 4 times the size of a 'proper' Python programmer's code.

I've never used a tuple. I'm using dictionaries, but I fear not in a good way.

I want to overload _init_ all the time.

On the other hand, I'm starting to slip into Test Driven Design. I'm mostly writing unit tests for some code I'd already written, which is to support some functional tests that I'm automating. I had three levels of classes, and at the highest level, it was more of a sketch than an attempt to get it right. Once I started writing and running tests, it all got fixed up and fleshed out. Maybe I'll start with some unit tests tomorrow and then write the code.