Prion proteins may store memories: Study hints at vital job for two-faced proteins.
Hmm, I meant to follow up on this one, but don't recall how...
December 2003 Archives
Scripting Languages seem to be on the vanguard of programming language design and/or evolution these days. leaving more traditional, more academic languages, (and more traditional academics) in the dust. Much more should be said about this. For the moment, I just want to remember where I found this: O'Reilly Network: Why Scripting Languages Matter [May. 14, 2003] and this: O'Reilly Network: The Crafty Turk [Jul. 21, 2003]
--BF, wishing all my bottom-feeding friends a Happy 2004...
PS, I also bookmarked this nugget 'o wisdom from Timmy Boy too, thought I don't recall why: O'Reilly Network: Refolding the Instructions [Apr. 09, 2003]. Probably because it seemed consonant with Christopher Alexander's thinly-veiled Zen allusions...
A number of us have put off following up on a fascinating, and
surprisingly productive OOPSLA Workshop from back in 2000, in
Minnesota.
I should dredge up my notes from this confab and post 'em...
5 September 2003
Friday
Death Valley Days #2
Recall that Ronald Reagan was one of the hosts of Death Valley Days…
An UP Observation: We are remoras on the Gang of Four barracuda. Only the GOF out-takes seem to have stuck:
EXTENSION OBJECT
EDITOR
TYPE OBJECT
NULL OBJECT
MVC/DOC VIEW
Three of these came from the Smalltalk world.
While there was some talk about the POSA patterns, they didn’t seem to make their way into the discussion all that much.
The test of a pattern is whether it really does
Do a GOF Talmud Page, to go with the GOF Thoughts shrine. Include Proxy Revisited, Null Object, Extension, Serializer, Type Object, Editor, etc.
The two observations above are from my 1997 notes. The following list is from the OOPSLA 2000 Workshop on Pattern Refactoring.
GoF Outtakes
1. Null Object
2. Abstract Class
3. Interface Class
4. Boilerplate Class
5. Type Object
6. Reifaction/Objectify
7. Serializer
8. Extension Object
9. Product-Trader
10. Bureaucracy
11. Role / Extension
12. Property
13. Whole Value
14. Abstract Object
15. Curried Object
16. Factory Object
17. Natural Object
18. Tools and Materials
19. Layer Object
20. MVC
21. Master-Slave
22. Publish-Observer
23. Presenter
24. Multiple Representations
Interpreter -
Abstract Factory -
Factory Method - -
Template Method - -
Decorator - - -
Iterator broadened to Streams
Services
Provides Information
Structures
Coordination
Controlss
Interfaces
Problematic
Proxy
Wrapper
Façade Adapter Decorator Bridge Proxy
Double Dispatch
Delegation
Abstract Class
U.S. News: Colin Pillinger, space scientist: Gambling big on life on Mars (12/29/03)
Who is to say that Earth hasn't contaminated Mars with its own meteor ejecta?
This article contends just this...
We are in the midst of the greatest mass extinction since the demise of the dinosaurs, and
The Kill-Off describes whom (yes whom) is to blame, and why this culling differs qualitatively from those that have preceded it...
There's been a thread in comp.object about refactoring to MVC. The intent is to tame a purported Swing UI monstrosity, and instead to move towards MVC by-the-Hoyle.
Hmm. I'd have scored Swing as being well within the broad outlines of MVCs intent penumbra, if not umbra, already.
The broader, more interesting question is why the Swing solution is regarded as a Frankenstein. Those components mesh better than most I've seen. Swing is a modern, third-generation (nth?) design / architecture. If programmers regard it as hopelessly Byzantine, what hope is there left? What's the problem with Swing? Is it so broad that its hard to learn? This could be so. My experience with it has been the learning curve is something well short of gentle. Issues like layout intrude far to early for my taste. Few components work out of the box. Is it capriciously arbitrary? Is it that the elements integrate in something short of a "seamless" fashion? They do seem to demand arbitrary trowel work, and more mortar, than one would expect of a framework that aspires to being the substrate for pre-fab solutions.
Is the problem that Swing had to be rolled out essentially finished? It had to emerge full-grown. Many species bear young that have to fend for themselves. Few that engage in the quality side of the quality vs. quantity trade-off abandon them. Yet, being bound to your mistakes as soon as you publish an API really really does constrain evolution. It's team players vs. defectors, as always, once again. How do we avoid the lumbering pageant of slow, coarse grained growth / expansion / dominance and extinction?
The picture to the right is of Tryve Reenskaug, who built the first implementation of MVC at Xerox PARC during the early '80s. (The picture was taken by yours truly at JAOO 2003, in Aarhus, Denmark last September.)
Danny Dig, of UIUC's DCS, gave a nice presentation on the history of this pattern complex / compound pattern / architecture on the same day that Ralph Johnson braved the Big Ball of Mud quagmire. He accurately chronciled the trend towards closer coupling between Views and Controllers, and the ascendance of Mediator objects that buffer the relationships between Views and Domain objects.
The more intimate relationships between Views and Controllers has been driven in part by the absorption of input event generation facilities into the operating system, and its attendant low-level I/O facilities. The more refined divisions of labor among Views, Domain Objects, and the intervening Model / Adapter / Mediator / Mediaptors has been driven in part by the desire for GUI independence, and in part by the rise of automatic GUI code generation tools. Given this, designers are forced to foist their components on the world, ready or not. They must be treated as mature, full-grown artifacts before they are refined in the crucible of full-scale deployment.
I'm as distrustful of and unreceptive to fancy continental scientific ideas, such as Pasteur's germ theory, as the next American. Thus, you can imagine my chagrin when, after being surrounded by people with a nasty respiratory ailment for most of the last week, I woke up with a seemingly identical ailment today myself.
I must reluctanlty concede that this Frenchman may have been on to something with these pathogenic contagion notions of his. I suppose, all and all, that this is a less unsettling explanation that divine retribution. In any case, I find myself with no voice. Except this one.
Heaven help us were ideas subject to this manner of contagion...
Good judgement comes from experience Experience comes from bad judgement --The Murphy's Law Calendar (circa 1987)
This epigram is an old favorite of ours, and evidently quite a few others. I tried tracking it down, and came up with a gaggle of purported attributions, going back as far as Mark Twain. I'd like to believe the Twain attribution, but I've yet to find a solid citation for its source. The quip appears without attribution in a number of places, leading me to wonder if anyone really knows where it came from...The remark has been variously attributed to:
Barry Le Patner
Jim Horning
Fred Brooks
General Bolivar Buckner
Rita Mae Brown
Will Rogers
Buster Bunny
Bob Packwood
Mickey Mouse
Texas Bix
Anonymous
Cousin Woodman
Mark Lacas
Arthur Jones
DC Stultz
Evan Hardin
Robert Kennedy
Lazarus Long
An Australian Aviation Magazine
Mark Twain
If you want people to always say "As Thomas Jay Peckish always says" before they say something, then Thomas Jay Peckish has to always say it...
--Thomas Jay Peckish II
I had the distinct priviledge this afternoon of hearing Ralph Johnson (yes that Ralph Johnson) present our hoary chestnut, Big Ball of Mud to his Software Engineering seminar. The mere prospect of this caused me to start reflecting on it...
I still find myself haunted by Kent Beck's critique that this masterpiece of equivocation ought instead to have had the "courage of its convictions".
I've become increasingly receptive to this perspective over the years. Is there something about the metaphors we use to descibe software that blinds us to its fundamental nature? Is that untidy tangle we dismiss as anomalous really part and parcel of building this stuff?
The set of systems that can feasibly be built at all is strickly larger than those that can be built elegantly. For many tasks, and for many teams, this architectural style may be the only possible match.
We made a point of saying, and so it is oft said, that this paper should not be seen as an endorsement of Big Balls of Mud. Indeed, we made it clear that we were, by no means, recommending these kinds of designs. At the same time, we resisted considerable pressure to utterly repudiate this architecture, for a variety reasons.
For one thing, tangled legacy systems leave programmers no choice but to cope as well as they can. Infantry-style teams and processes insure system made in the team's image. Some problem domains may pose requirements so inherently muddled that must inevitably be mirrored in any possible solution.
While I still can't say I recommend this approach, I'm convinced that it was high time that someone try to describe and explain it. This architecture may as well be placed honestly and openly on-the-table, since its spectre looms large over its more respectable alternatives.
Noble et al. have nominated this work as perhaps one of Computer Science's first post-modern works. I'm quite sanguine about this characterization. I realized during Ralph's lecture that a legitimate descontruction of our argument, that is to say, a characterization of our unstated posture, might be that small teams of skilled chraftsmen can beat an underskilled human wave approach every time. Were we really advocating a world made in our (presumed) image?
And, this Slashdot nugget on role fragmentation suggests yet another possible perspective on this multi-faceted issue. (And, yes, it feels rather pointless to echo a Slashdot post in one's own weblog, but what the hell...)
Ralph observed at one point that Big Balls of Mud are what you get when you throw an army of Visual Basic programmers at a problem, and further, that that's just what you ought to expect to get. It's yet another corrolary to Conway's Law. Given that you've elected to employ a large number of modestly talented "infantry level" coders, a haphazzard hodge-podge is what you should properly expect.
Now, back to Beck's challenge. Kent made this remark, I've recently realized, back when his ideas about Extreme Programming were taking shape. XP would ultimately relegate concerns about design aesthetics to a secondary, or even tertiary position in its pantheon. You Are Not Going to Need It demanded that design flourishes be eschewed in lieu of immediate, established requirements. It is a defiantly utilitarian process that ultimately came to scoff at the petty egotistical inclinations of designers towards generality, extensibility, and elegance. Indeed, it gently mocks these inclinations as soft of wasteful hubris. Looking back, it seems that Kent had begun to see the Sirens of Elegance, of High Road Architecture, as of the major obstacles on the road to a more dependable software development process.
Have you ever been mystified, err, well, let's be candid, annoyed by Outlook's hexadecimal failure codes. This site has the low-down on 'em.
Now as to the enduring mystery of why I'm still using Outlook...
