Radio Hackers Becoming Hacked Off

Some Radio UserLand hackers are becoming discouraged by the sheer weight of the program's UserTalk code and the bugs, quirks, and complexities it contains. Mark Paschal, who offers help frequently on the customer support discussion board, says that it is "as jury-rigged a Rube Goldberg device as ever." Jeremy Bowers believes it need a "serious housecleaning."

For those who haven't looked around Radio's object database yet, the program runs atop one of the most intricate, fascinating, and strange codebases you will ever find in a development platform. I'm digging into it deeply for Radio UserLand Kick Start, and I keep discovering ingenious things that can be used to bootstrap an elaborate new program, Web site, Web service, or software library; customize a feature of Radio; or reinvent the program completely (just as it was once an MP3 playlist manager that became a weblog publishing tool). As I told someone this weekend, the book could be 100 chapters long instead of 20 and I wouldn't run out of things to write about.

I'm not at a point where I can judge Radio's fitness for large-scale development, since my own needs are met by simple scripts, drivers, and callbacks. However, if most of their beefs are related to specific UserTalk verbs rather than the kernel, they can be avoided.

One thing I think there's a huge need for is a bug database where Radio and Frontier developers can submit bugs and vote on the ones they'd most like to see fixed.

Radio Userland · Salon Blogs · 2003/05/25 · 3 COMMENTS · Link

Comments

Beside the bugs, the main problem for me with Radio is that there is no developer documentation. And this not coming from a "new" developer, but someone that have been using Userland products over six years. For example, with Frontier, you had a document (not anymore available) from Matt Neuburg called the "the walk" which described the way Frontier and mainResponder where handling request. Such a document to understand how a file is parsed in Radio doesn't exists. And since the Radio code base is full of indirection, its hard to follow what is happening.

For example, do you know that you could use somehow the filters, like the final filter with Radio. Its possible, I made some tests, but its not clear if the #filters table that were in the user space is now a UserLand preserved space.

As you noticed, Radio can be much more than a weblogging tool. And I use Radio all the time for my PHP projects. But since there is no documentation about this, only people that have knowledge of previous UserLand frameworks like the website framework can have a grasp on what is going on. I hope your book will help here, but I doubt, since you don't seems to focus on this aspect of Radio.

Cheers

-Emmanuel

#1 · Emmanuel D�rie · 2003/05/26

I really, really tried to like Radio Userland. Eventually, I was just overwhelmed by its sheer cruftiness.

I gave up on the product literally while I was in the middle of coding a replacement news aggregator. What I wanted to do, was add a few extra features to the aggregator. However, I found that what I had to do was write a whole new aggregator (albeit through cutting and pasting swathes of code from the old one), because the old aggregator's code was so badly factored, and resistant to new features being added.

Sure, I've seen code at work that is just as bad, but the difference is that in those products, the end-user isn't expected to have to delve into the code. I never see the code for Photoshop, all I see is the deliverable that is compiled from it. For Radio, being a programming environment means that the code _is_ a deliverable, and things like this makes it rather painful to customise.

I think there's basically two problems. The first is Usertalk. Compared to modern scripting languages such as Python or Ruby, Usertalk isn't really a particularly good scripting language. It's only advantage is the object database underneath it.

The second is simply that the code inside Radio has evolved over a long period of time, and several radical changes of direction. As such, the code develops strata, layered on top of each other, without sufficient refactoring to make it coherent and seamless. Meanwhile, old ways of doing things hang around for reasons of backwards compatibility, until one day someone realises it's broken but nobody noticed.

#2 · Charles Miller · 2003/05/28

Is it really a requirement to delve into the Radio codebase, or just something developers would like to do because in principle it should be easier than coding from scratch?

The underpinnings of a from-scratch Radio tool seem pretty sound from my explorations to date -- the object database is more than 10 years old and well-tested and UserTalk is a mature language with lots of simple verbs that seem to work well.

As for tools that extend Radio's features (adding features to the news aggregator), though that should be possible, I don't know that UserLand has ever claimed it's designed with that in mind. Their mechanism for extensibility is user callbacks, not the scripts in the system table that support the big features like content management and news aggregation.

#3 · Rogers Cadenhead · 2003/05/28