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.
