Michael Lucas-Smith calculates the methods that can use register allocation effectively...
I put in italics the methods that would require a spill object. Only 0.37% of methods in the system will spill!. Clearly this indicates that the technique will work even on a system with 8 registers like an x86.
I think that is to some degree optimistic since no registers will be left on the x86 for intermediates.
Keith Ray responds to my recent item on coordination via databases...
As long as databases only store data, and don't store whole objects (data+algorithms), they will always risk disassociating meaning and values.
I understand there is this risk. But the scenario we're comparing to is the distributed messaging paradigm where messages have no algorithms associated and the various end points use different languages. People have decided they don't want the "whole objects" scenario.
I think there is a tremendous benfit to whole objects in either scenario, if good choices are made about the language. The majority has not gone along with that. Ever. Back in the days when CORBA and OODBs were hot topics at OOPSLA, there was a clear message being presented from an aggregated look at the experience reports. Namely, distributed Smalltalk and the Gemstone Smalltalk OODB were relatively easy wins, while distributed CORBA and other OODBs would work OK but were a pain in the ass.
Jay Han responds to my item on using databases for coordination...
We know that databases provide concurrency control and transaction management. These features let applications share data -- you can call this coordination at low level. But what about coordination at high level? How can they exchange semantics of data? e.g. "9999-12-31 in date field means now? never? forever in the future?" or "20 point means 20 basis point." (Schemas and constraints can check syntax of data but not the "validity" of data.) Because I don't see how databases provide meaningful (hence ad-hoc) coordination, I don't quite understand Patrick's last sentence above especially the second half.
Databases have no advantage nor disadvantage in this respect (the "meaning" of data) to any other coordination mechanism.
Edd Dumbill makes an interesting observation about XML and databases based on submissions to XML Europe 2004...
Databases. Though there's a reasonable amount of interest in the W3C XML Query language, there's not much to say about XML and databases. It doesn't seem to me that the integration of XML with relational databases has taken off in the way we once thought it might. Is this just a temporary lull in the convergence activity? Probably.
Jon delivers a great sermon on dynamic languages and wraps it up with an observation...
Somebody asked me yesterday why platform vendors like Microsoft and Sun are never at the forefront of dynamic-language innovation. I don't know why that's so, but it does seem to be true.
Sun has been at the forefront in the labs, e.g. the Self language was partially a Sun effort. The Java HotSpot VM is essentially a productization of many dynamic language implementation innovations.
I think an answer to the question above has more to do with the psychology and sociology of programming than it does with anything else. The big companies are almost by definition the ones whose value chain ends with giving the majority what they want. What they want is not always what works good in laboratories, nor is it necessarily what is "best for them".
Looking at language evolution in the long run, especially as plotted against a graph of Moore's Law, clearly the trend is to become more dynamic. A good indicator is a major industry journalist writing about such things.
I don't know what the name will be for the ultimate dynamic language, but it is almost certain to have {curly braces} in the syntax and come from Microsoft. Well, sociology may determine the syntax to have <angle brackets>, but it almost certainly will come from Microsoft. 8^)
Tim Bray on the tripod of objects, messages, and tables...
...for me, this essay brought into focus the fact that anyone who isn’t comfortable with object-oriented design, and with relational data modeling, and with wrangling XML messages; anyone not comfortable with all three, I say, just isn’t fully trained.
Well said, for developing today. But what about tomorrow? When he writes...
Lots of architects have learned, painfully, that you usually can’t magick relational rows away behind object/class abstractions. The right way to think about a database is as a set of normalized tables that are designed to be addressed with SQL strings.
...I can only suggest that we need to upgrade our languages to provide more magic.
Lisp, Smalltalk, and Python come to mind. These are the magic we have for now, but there's more to come if we stay the course. Our databases are still based on early 1980's implementation ideas. Let's keep the good concepts and upgrade the rest. Our messages are struggling with nascent infrastructure and representation issues.
Our languages (i.e. "objects"), our databases, and our messaging are all struggling to become more dynamic. As they do, they will also become more unified, or at least "unify-able".
Jon Udell... For me every document is a database, and every database is an assembly of documents.
Fair enough, I like the convergence too. Hopefully our tools will provide some examples and guidance toward good structures for documents for various scenarios. There are best practices in the decision support arena that are not always employed even by us professional nerds. New query tools and calculators would do well to steer the evolution toward the paved roads or we may be processing XML on the cow paths for longer than necessary.
Keith Ray writes about multiple return values in Python and Smalltalk...
# Python example...
beforeNotAfter, afterNotBefore = foo.findNonOverlappedElements( before, after )
# do stuff using beforeNotAfter
# do stuff using afterNotBefore
"Smalltalk example..."
foo findNonOverlappedElementsOf: before and: after
doing: [ :beforeNotAfter :afterNotBefore |
"do stuff to beforeNotAfter".
"do stuff to afterNotBefore" ]
The other aspect of the Smalltalk solution here is "tell, don't ask". We tell 'foo' to find the non-overlapped elements, and we tell foo what to do with the resulting lists of elements (execute our block). This forces a certain cohesion to our code. The Python example is violating the spirit of the Law of Demeter, if not the actual Law (1) because we ask and then work the results of what we asked.
But I don't see how the Law of Demeter is involved in this. Neither the Python nor the Smalltalk examples divulge anything about the implementation of foo. There are no undue dependencies.
In fact this is one use of a Block in Smalltalk that obfuscates the code. Python's simple syntax for returning tuples into a multiple assignment is the simplest mechanism for this scenario.
Americans increasingly [tell] pollsters that they believe in prayer and miracles, while only 28 percent say they believe in evolution.
Isn't evolution a miracle?
New Year's Day we had 5" of snow and great sledding. The only good sledding snow in the last four years down in the valley.
Last night the snow was even better. But I had an all day meeting in the office. Checking in with my family throughout the day, my boys spent all day outside. The sledding was great. For them. 8^(
Before I even left the office, the landscape had been receiving a coat of freezing rain. The fun would be over. But wait...
Up ahead in the driveway there is a snow ramp and kids are falling down hard in the road. The ice coating is almost perfect and the roads are empty.
Several of us make the full trek up the road. Again and again. There was plenty of sledding left this night.
Tomorrow the muscles will ache and I have Part 2 of the two day meeting. 8 am.
On DevHawk the discussion continues about objects and data. Herewith are some thoughts...
Objects are first and foremost for code organization. Computers could do their work just fine, thank you, without objects. And so if the "data" or "messages" or "documents" are not going to map to objects, then will we be better off?
I think the salient, yet somewhat conflicting, points include these:
In addition to objects, the other code organization mechanism that will lessen your burden is pattern matching. The better pattern matching is integrated into your language, the less code you will have to write when passing semi-structured data around.
Erlang is a good example of a language that does not have "objects" per se, but Erlanf does have a very convenient pattern patching syntax for interprocess messages. Languages that have both objects and pattern matching are even better off.
Update: What happened to IBM's San Francisco framework for Java? Was it too ambitious? Will MBF be more practical? After a half decade of EJB and J2EE, is there anything comparable? In any language? See MicrosoftBusinessFramework.
From the PDC, maybe the best presentation I have view thus far... the Microsoft Business Framework.
From the Chandler email list, some references to the use of continuations in the Haystack system and the Python language...
In September, Hamish Harvey described some of the neat things about Haystack, including UI continuations. (Harvey's message was posted Fri, 26 Sep 2003; there's an article describing Haystack's continuations at http://haystack.lcs.mit.edu/papers/uist2003-uicont.pdf.)
I just wanted to add a reference to a tutorial article on continuations using Python: "Continuations Made Simple and Illustrated" by Denys Duchier at http://www.ps.uni-sb.de/~duchier/python/continuations.html.
I also want to second Harvey's enthusiasm for the idea. When the design work on CPIA gets into high gear, I strongly recommend reviewing this technique.
Regards,
Don Dwiggins
Jim writes...
The plain truth is, not that many projects really need complex distribution mechanisms. Most apps look a lot like this:
I think we have gotten too far away from this wisdom. The typical database has distribution and coordination built in. That means for the most part you get to write your application in isolation. The database also to serves to coordinate the application's own actions.
We need to get back to the future and look at how to simplify coordination and not just message passing. Databases are a coordination mechanism for one or more applications, and one mechanism is better than two.
Just some thoughts on my current favorite hammer and nail, the XML-based nested tuple space and some coordination systems I'd like to know more about...
It seems to [Tim O'Reilly] that the original Unix/Linux architecture, and the architecture of the internet, are based on a model of "small pieces loosely joined" (to quote David Weinberger). Web services can also operate on this model. However, there are alternate visions, including .Net and J2EE, in which there is a quest for "one ring to bind them all."
Tim also wishes that Nat Friedman (of Novell/Ximian) would finish up Dashboard for Linux
I'd like to learn more about Dashboard in 2004. In fact there are three "connecting" systems I'm wondering about...
Central and Groove do many things, but to boil them down to their essence, at least the parts that interest me most right now, I would say the following. Central provides awareness of selected information among a set of Internet-enabled applications all under my control. Groove provides awareness of distributed actions among a set of shared Internet-enabled applications under a small community's control.
Dashboard on the other hand peeks into the more or less internal information of less deliverately cooperative applications.
Kind of the downside of each of these, from my cursory understanding, is that these underlying connecting mechanisms are each tied to larger frameworks. Apps in Central almost have to be Flash from top to bottom as far as I can tell. Apps in Groove have to be Windows based or at least use SOAP to get to Groove on Windows.
Apps in Dashboard... there are no apps "in" Dashboard from what I can tell. But Dashboard has to be able to peek into the apps your interested in, and they seem to have to run on Linux.
Would each of these capabilities benefit from more loosely coupled "connective tissue"?
Central-like connections could be made by having any application's selections be published to a local blackboard (aka nested tuple space).
Groove-like connections could be made by having the distributed applications communicate by implementing persistent shared spaces and/or queues (aka nested tuple space).
And Dashboard... perhaps Dashboard-like connections would be enabled to work with any app that uses a local searchable tree as its working memory (aka nested tuple space).
The obvious and simple fact is that, yes, there is quite a bit of functional overlap between spreadsheets and databases. They both, basically, are representations of tables of data and most folks want to perform interesting operations against those tables. Databases are more structured, spreadsheets appear more flexible and easier to use...
Task mind meld aside, what is more relevant about the application is that it's web-based. No, strike that, the big deal is it's DATABASED. Ahhhhhhhh. Sure.
I spent the day yesterday at the Oregon Museum of Science and Industry with my wife, youngest son (11), and his friend across the street.
The whole place is "hands on", but the physics and chemistry labs are the best.
2004 will be the year of the Posi-Blog for me. Every post will be about something I think is good, or I won't post. It's too easy for me to slip into disconnected curmudgeon mode.
A have several drafts that have been sitting around for a while so my first excercise will be enlightening for me, to find out which ones are Posi-Action and which ones can be edited to be so. And which ones can't --- you'll never know.
Happy New Year!
Signing off for 2003. One last post...
Dan writes about good news for organic beef farmers. "They're not allowed to feed animal remains to their cows."
Here in Portland, Oregon we get Painted Hills beef.
Another break in the holiday festivities to note that Don Box is asking us to think good thoughts...
Think HyperCard. Think VB 1.0. Think classic ASP.
I think it's going to matter big time going forward as the industry wakes up from its C++/Java-induced haze and starts thinking about making computers programmable again.
