Quick note -- I'm working on a deep database feature in FeedLand, adding support for reading lists. Deep in the sense that it's under several layers of user interface. It's like digging up the foundation of a house and figuring out how to add a new room on the third floor. It's something of a high wire act, but I honestly think I figured it out. #
It's far from the first time I've implemented reading lists, I've done it before with simpler apps in JavaScript, and richer apps many years ago, in Frontier.#
This time it's in JavaScript and MySQL, and thus is, in one way, fairly compariable to UserTalk and Frontier's object database. But we didn't have the SQL querying capability in Frontier, so it's not comparable in that way. What we're doing now in FeedLand would not have been possible in Frontier.#
To implement this feature in MySQL I needed two tables to the database, one for reading lists, and the other for reading list subscriptions. This part is very easy. Not necessary in Frontier's object database because the structure is ad hoc, like JavaScript objects are ad hoc. You could store relational database tables in a JS object, but there would be nothing to prevent you from breaking the rules in some or all of the "records."#
Where it gets complicated is the code to access the database, and use the reading lists while everything is running. The Frontier code to implement the structures would also be simple, and easy to debug. It's just straight line code, with if's and else's. The runtime takes care of suspending your thread when you need to wait for a result, it does not show up in the syntax of the language. The Frontier programming language also has an intimate relationship with its database, whereas in JavaScript and MySQL there are layers of levels between the JS stack and the database. There really don't need to be any layers at all, that's what Frontier proves. #
It took me years to dig out from under all the layers and gruntwork that's here that wasn't in Frontier to figure out what exactly the difference was.#
And since I designed Frontier, this is self-praise, for which I apologize, but let me share with you the secret that makes Frontier so much better. For years in development I factored and refactored every time I came up with a simpler way to do something. I had been programming for a decade when I started Frontier, and had used some great highly factored tools before -- specifically Unix and THINK C, and I understood the process, having done it with commercial Mac, IBM and Apple II end-user products. I treated every aspect of development as you would treat the user experience of end-user software. And since you are an intimately involved user, there's a huge advantage here. I just had the time, and took the time to do the factoring that so far no one else has taken. At least to my knowledge and that's a big caveat because we don't generally use each others' platforms in tech, unlike other arts and sciences, we tend to live in and create our own caves. But Frontier was a product at one point, with several thousand people working in it, and most of them understand what I'm talking about here .#
You know those obnoxious sites that pop up dialogs when they think you're about to leave, asking you to subscribe to their email newsletter? Well that won't do for Scripting News readers who are a discerning lot, very loyal, but that wouldn't last long if I did rude stuff like that. So here I am at the bottom of the page quietly encouraging you to sign up for the nightly email. It's got everything from the previous day on Scripting, plus the contents of the linkblog and who knows what else we'll get in there. People really love it. I wish I had done it sooner. And every email has an unsub link so if you want to get out, you can, easily -- no questions asked, and no follow-ups. Go ahead and do it, you won't be sorry! :-)