May 21, 2013 § Leave a Comment
In my opinion, BitC is the most innovative take on systems programming we’ve seen since the invention of C. While sad that it failed, I am deeply impressed by the thoughtful post-mortem by Jonathan S. Shapiro. Here are links to the various threads of his analysis (and the equally thoughtful responses):
- [bitc-dev] Retrospective Thoughts on BitC
- [bitc-dev] Retrospective: The Issues with Type Classes
- [bitc-dev] Retrospective Thoughts on BitC [David Jeske]
- [bitc-dev] Retrospective: separate compilation and dynamic linking needs programmer knowledge?
- [bitc-dev] Instance coherence: the shape of a solution
- [bitc-dev] Retrospective: shape types
- [bitc-dev] BitC Lessons For Other Language Developers – Simple vs. Too Simple
- [bitc-dev] An unusual design pattern
- [bitc-dev] Type Clases, Overloading and Genericity
- [bitc-dev] Subtyping/subclassing
- [bitc-dev] Wrong notion of const-ness
September 26, 2011 § 1 Comment
[Diagram updated on 10/27. Thanks to @frozencanuck for his feedback.]
The RIBS diagram is my third attempt to extend the wildly-succesful Model–View–Controller design pattern to encompass first the The DCI Architecture and now the REST architectural style. This time, I started by reverse-engineered the design principles behind the Ki Statechart Framework, particularly their use of statecharts as coordinating controllers.
I also have a clearer picture of what I am doing: trying to identify a general design pattern for computational systems.
Here’s what it looks like so far:
- The purpose of a System is to manage a Resource
- A System contains a Resource, one or more States and their Behaviors, an Interface for each State, plus relationships with zero or more Peers.
- An Interface (which could also be a System of its own) consists of active Actions and passive Presentations available to an external Client.
- When a Client invokes an Action, the System routes it to the appropriate Behavior for the current State (the routing is necessary if there are multiple concurrent states, otherwise it can be elided).
- A Behavior can in general a) adapt a Resource, b) interact with a Peer, and c) initiate additional Behavior
- Resources present to an Interface and adapt to a Behavior
- Views are Interfaces
- Models are Resources that can adapt and present themselves
- Controllers manage State, routing, and connections with Peers
- Views can be systems, whose Resource is a drawing context and Behavior is hit detection
- A Model object could itself be a system, with a database row as its Resource and business logic as its Behavior
- Hypertext is an Interface (HTML) which uses Routes (URLs) to embed State
- Behavior is driven by a small set of Actions (HTTP verbs) against a specific Resource
September 16, 2011 § 2 Comments
[Update: this post has been obsoleted by RIBS: Marrying the REST and MVC Design Patterns « iHack, therefore iBlog]
SIDA stands for “State • Interface • Data • Algorithm“, and is a refinement of my earlier “DIDA” model (where the “D” stood for Design). DIDA in turn was an expansion of the well-known Model–View–Controller design pattern based on insights from the Data-Context-Interactions architecture.
- Concrete States
- Clear Interfaces
- Consistent Data
- Concise Algorithms
- Presentation of Views
- Controlling of Actions
- Binding of Roles
as shown in the accompanying diagram.
In a simple system, the state is implicit and the relations are absorbed into one of the artifacts, reducing SIDA to the traditional View, Model, and Controller, respectively. For more complex systems, however, it may make sense to design explicit objects for each relation, e.g., traits for roles, presenters for views, and strategies for actions.
In addition, SIDA is intended as a general architecture, describing the internal structure of everything from databases to web services to GUI applications. An interface as defined from inside the system may appear as data or an algorithm from outside the system.
The most interesting (and perhaps unusual) aspect of this diagram is how it makes state a central features, something developers never use. If state really is so central to the design process, perhaps it deserves explicit language support, as provided by UnrealScript or typestates (as in Rust).
This is all still merely a hypothesis on my part, as I haven’t actually put any of this into practice yet. Anyone with more experience care to comment?
September 15, 2011 § 2 Comments
[UPDATE: This post has been obsoleted by SIDA: Moving Object-Oriented Design beyond Model-View-Controller]
I recently read about The DCI Architecture: A New Vision of Object-Oriented Programming, a successor/complement to the original Model–View–Controller design pattern, by one of the original authors. The DCI stand for:
July 1, 2010 § Leave a Comment
June 29, 2010 § 1 Comment
I have some friends (Hi Dustin) that are serious language geeks, whom I often get into debates with. One of my common refrains is “to do it the Ruby way”, because (while Ruby has its warts) it does so many little things beautifully well. So, as future ammunition, I figured I should try to collect links to my favorite Ruby features (much as many others have already done before me).
August 4, 2009 § 2 Comments
To their credit, they’re offering a 20% discount on the User-Friendy-but-Ugly-Safari-Hack 1Password from Agile Web Solutions. Unfortunately, since Steel.app is freeform and 1Password is structured, they say you have to cut and paste everything manually.
Not true! If you (like me, and I suspect many others) used a consistent column scheme for storying your passwords, it is actually quite easy to migrate your data automatically. Find out how below…
Update: you can use a similar process to import from Steel.app into PasswordWallet, a simpler but less intrusive alternative to 1Password.
July 14, 2008 § 1 Comment
A lot of people are busily activating iPhone 3Gs and upgrading old iPhones to the new 2.0 software. And they’re downloading apps on the app store, most particularly Apple’s free iTunes Remote utility.
Perhaps the coolest little bauble in the free apps, Remote turns your iPhone into an Apple remote, so you can use it to control iTunes on your computer, or your AppleTV, when you’re on your local wi-fi network.
One of the most surprising and enjoyable elements is the iTunes Remote. Full and comprehensive access to my fairly large iTunes library on the iMac: all playlists, etc, with the ability to control volume, jump around in songs, see artwork – just like the ‘iPod’ iPhone application!
The Remote is one of Apple’s own applications rolled out for free over the App Store for the new iPhone software and it is absolutely brilliant, with an amazing user interface and flawless integration. It’s the best iPhone application I’ve used yet and I just love it! It sets the perfect example of an iPhone app.
The NYTimes reader is nice as is the Google app that gives me decent access but it’s the Apple Remote app that is just, well, cool.
The iPhone remote application is worth the upgrade alone. Gone is the need to use Apple’s minimalist remote control, and replacing it is a full color touch sensitive remote that would put a Logitec all-in-one unit to shame (although of course it won’t work my TV). For Apple TV fans, bliss.
Support for the Remote app for the iPhone and iPod touch (awesome)
One of the first apps I downloaded while doing the App Store video walkthrough today was the new iPhone Remote for iTunes. There’s only one word to describe it: perfectomfgthisissocool.
Verdict: download it now.
It’s that simple: the iPhone is now a house-wide wireless remote control for your music library. I would hate to be one of the companies that sells house-wide wireless remote controls for your music library right about now.
Shall you have an iPhone or iPod Touch, you can now remote control your iTunes libraries (Mac and PC, Folks) with the little yet jaw-dropping awesomely fantastic Remote application.
Now, once again Apple is showing the way to the Future : how we’ll be able to control any *connected* device from our smartphone – er, iPhone.
One of the delicious new freebies in the iPhone 2.0 software update: a lovely little app that will turn your iPhone or iPod touch into a remote control for your Apple TV or within iTunes. It works over WiFi and even hoovers up the cover art or preview image of what you want to play. The Shuffle-like Apple remote magnetically attached to the side of my monitor seems so quaint now.
You’ll probably remember last month when I wrote about a rumor stating that Apple planned to make their own iPhone remote for release in the App Store. Well, it turned out to be true, and it’s awesome. Apple, with a stroke of genius, has decided to call this iPhone application Remote. It’s free, it’s 1MB, and it’s available through the App Store that was launched yesterday.
July 10, 2008 § 1 Comment
A big thank you and welcome to everyone who’s joining the Shoes community for ShoesFest 2008. On Friday, July 11th and 25th (local times vary), we are encouraging people with or without programming experience to join us in creating and running Shoes programs on Mac, Windows, and Linux so they can email us with feedback about:
- platform compatibility issues
- performance bottlenecks
- confusing, missing, or under-documented APIs
Here’s Ten Steps for making the most of your involvement in ShoeFest, whether for one hour or twenty-four:
- Download Shoes for Mac OS X, Windows, or Linux
- Read _why’s answers to common questions
- Use an IRC client to join the discussion on irc://irc.freenode.net#shoes
- Try one of the Shoes Tutorials people have written
- Read and run a few of the included samples, or programs from The Shoebox
- Scan Nobody Knows Shoes, and review the poster of the most common APIs
- Use `shoes -m` to bring up the manual (On OS X, you can do ⌘-?)
- Modify/extend an existing app to try out particular APIs or techniques
- Write your own Shoes app. It could illustrate use of a particular API, replicate a similar app on another platform, or just be something you’ve always wanted to write
- File bugs by emailing shoes AT code.whytheluckystiff.net; copy why AT whytheluckystiff.net if you’d like to be permanently added to that mailing list
June 27, 2008 § 3 Comments
- Friday, July 11th noon GMT to Saturday, July 12th noon GMT
- Friday, July 25th noon GMT to Saturday, July 26th noon GMT
< 8 AM New York / 5 AM San Francisco / 9 PM Tokyo / 3 PM Amsterdam >
The goal of these events is to write and share fun little applications using Shoes, a clever little cross-platform GUI toolkit written in Ruby. This will allow us to test, document, and file bugs on how the various Shoes features work on the different supported platforms (Linux, Windows, Mac), in preparation for our next major release on July 31st, 2008.
No Ruby — or programming — experience is required; we’d love to find out how easy it is for novices to learn Shoes! Of course, if you happen to know the Ruby C API, expert help is always appreciated.
Shoes comes with its own built-in manual. Use `shoes -m` to bring it up. (On OS X, you can do ⌘-?.)
- The latest Shoes binaries for Mac/Windows/Linux
- The Shoebox, a friendly place to share Shoes (and Ruby-Processing) apps in peace and harmony
- Hackety Hack, the programming tutor that motivated Shoes
- Nobody Knows Shoes, the introductory guide
Spread the word! Everybody could use a nice set of Shoes.