Paul Krugman, on Business Week's article titled "Waking Up From the American Dream"...
Suppose that you actually liked a caste society, and you were seeking ways to use your control of the government to further entrench the advantages of the haves against the have-nots. What would you do?
From the things that make me go, "Hmmm", department...
Years from now will programmers wonder what the heck the "managed" in "managed runtime" means?
Folks are trying to push back the history of the notion "Inversion of Control".
I can't recall the phrase itself, but the notion goes back at least into the late 1980s when the object-oriented community was talking about "libraries" (you call it) vs. "frameworks" (it calls you), e.g. Designing Reusable Classes, Johnson and Foote, 1988.
I bet the essence of IoC was also expressed by Peter Deutsch in 1983's "Reusability in the Smalltalk-80 Programming System". I can't remember if this paper actually used the term "framework". But that was a main point, and draws on the Smalltalk work they did at PARC in the 1970s, including the first "famous" inversion of control, Model View Controller, with Trygve Reenskaug
Update: This from Blogger in response... There is not a want to publish both RSS/Atom. If you do not want to yet switch to Atom, you can use your RSS feed until you choose to switch to Atom.
So if you want to publish both RSS and Atom from Blogger, let them know.
I can publish Atom if I change a setting in my blogger configuration. But I won't, at least not yet.
I've sent an email to Blogger/Google to explain this. Apparently, (from what I can see in the UI), I have to choose between RSS 1.0 and Atom. I cannot have both, unless I write it myself, and I have no interest in that.
How can the Blogger base switch to Atom this way until all the universe supports it first? How will the universe be encouraged to support Atom unless the Blogger base publilshes it? Catch 22.
One thing that Kent Beck mentioned in Test Driven Development was that if he's not finished test-driving a chunk of code, but has to leave it for a while, he'll leave one test failing. When he gets back to pick up where he left off, he runs the tests, sees the failing one, and by making that test pass, gets back into the mindset needed for that design problem.
I do this all the time. This is especially handy when you are programming at home and are susceptible to frequent family interruptions. It's also handy when you are done for the day. When you come back in the morning, the test is there ready to tell you exactly where you left off.
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the quantity group: fifty pound of pots rated an A, forty pounds a B, and so on. Those being graded on quality, however, needed to produce only one pot -albeit a perfect one - to get an A.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the quantity group was busily churning out piles of work - and learning from their mistakes - the quality group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Art is human; error is human; ergo, art is error. Inevitably, your work (like, uh, the preceding syllogism) will be flawed.
What you need to know about the next piece is contained in the last piece.
I have nothing to add. Buy the book.
Update: Note that the Python.NET described here is *not* a CLR implementation of Python. This is "regular" C Python. You drop the bridge DLLs into a Python folder, then import CLR, and at that point have access to all the dotnet classes, events, etc. There's been some confusion of this with the more experimental IronPython, which is an all-new CLR implementation of Python and not ready for production use.
The VisualWorks Smalltalk dotnet bridge does not yet handle dotnet events...
But registering for events in .NET was not part of the version 1 plan. It is extremely difficult and there is no solution whatsoever at the moment (AFAIK for any *-.NET bridge).
The problem is that you need to give .NET a delegate object to call (type safe callback) and that has to be part of the managed world. We are thinking about synthesizing such objects (their classes) and having an extra callback mechanism with dedicated marshaling
For the record, the very nice production quality Python.NET does support dotnet events in the manner described above. I have not looked at the code for how, but it is open source.
Here is an example of registering for a dotnet event in CPython...
def add_menu(self):
self.Menu = MainMenu()
self.tool_menu_item = MenuItem()
....
self.ellipse_tool_menu_item = MenuItem()
self.ellipse_tool_menu_item.Text = "Add &Ellipse"
self.tool_menu_item.MenuItems.Add(self.ellipse_tool_menu_item)
self.ellipse_tool_menu_item.Click += EventHandler(self.pick_ellipse)
....
def pick_ellipse(self, sender, args):
self.ellipse_tool_menu_item.Checked = True
self.canvas.current_tool(self.canvas.ellipse_tool)
....
Miguel de Icaza is crazy about this...
One of the fascinating things about Jikes's JIT engine is that it was completely written in Java. Absolutely mind-blowing. The upside is that many things can now be done in a higher-level language than C like JITing and garbage collection, the downside is that these systems are fairly heavy during compilation time and are best suited for server use and not desktop use.
And I am crazy about the following, and wonder how they compare...
This talk summarises two decades of work on Smalltalk and Self compilation and virtual machine technology and describes a novel attempt at an adaptive optimizer for Smalltalk that is written in Smalltalk and to a meaningful extent, portable across implementations... the explicit representation of code and execution state make it convenient to implement a hybrid architecture where an adaptive optimizer written entirely in Smalltalk, guided by type information obtained from the VM, produces optimized bytecoded methods that are executed by a more-or-less conventional VM.
Roy Osherove is asking about Smalltalk in the enterprise. Gemstone Smalltalk was the first object-oriented application server to my knowledge. The core architecture has been in development for about 20 years. The systems developed include manufacturing floor, billing, banking, insurance, shipping, and logistics applications.
There are a surprising number of new web applications running Gemstone Smalltalk too. I would probably choose Cincom's VisualWorks over Gemstone today since it now has a lot of server capabilities, better web tools and objects, as well as better product support.
Richard Demers connects the IBM AS/400 (which has an object/capability based OS) and Smalltalk.
The AS/400 is an interesting animal. Actually, seven years ago Dave Thomas (founder of OTI, bought by IBM) gave a keynote talk to Gemstone's company meeting. There he suggested that Gemstone Smalltalk be ported to the AS/400.
I am not sure the suggestion was seriously discussed at the executive level. The company shortly after decided to take on IBM, Sun, and Oracle in the Java/J2EE market. (This was before Weblogic made a name for itself.) And the rest is history... Smalltalk is still their cash cow.
What makes Smalltalk that much more productive?
Jim hits all the right notes. I would add a couple other notions...
There is no main. Rather than writing programs, you construct objects. Rather than running programs, you test objects. A Smalltalk environment will have several browsers up at a time. Some for browsing, others for editing. Another typical scenario is to have several *workspaces* up at the same time. A little code here, a few tests there.
This ties into my other notion, that Smalltalk is essentially *testable*. Before the onslaught of XP, Smalltalk culture was even then based on writing a little and testing a little.
Plus common practice (trivially achieved in the Smalltalk environment) is to keep this "image" of multiple windows and multiple, incremental tasks flowing between sessions. Smalltalk has trivial persistence that supports the development environment greatly.
Michael Lucas-Smith expands his adventure with registers to the 64-bit world.
The 64-bit world is interesting for another reason: data representation. Not only does the IA-64 have a large number of registers, and not only can you "rename" them so that they don't always refer to the same physical register, but since they are 64-bits wide you can fit a lot of data into them as "immediates" in a dynamic language like Smalltalk.
How would you represent a 64-bit floating point number in Smalltalk?
In the 32-bit world, you would have a 32-bit object reference where some number of bits would indicate the "tag" or the data type and some number would indicate the memory location where the data actually resides. The tag may be zero bits if all data is stored in memory and never immediately in the reference itself. Another option is to use a 2-bit tag, say the lowest two bits, to indicate the data type and then align the allocated memory to account for the "wasting" of the lowest two bits. (They indicate tags instead of pointing to byte aligned allocations.)
These two bits are then 00 or masked off to get to the allocated memory. Otherwise some other pattern (11, 10, 01) indicates the data is immediately in the reference itself. This may be a 30-bit integer (again, the tag is wasted), or a character (some other byte or 2-byte integer in the upper 16-bit word) or some other design. (Google should turn up some creative designs, this is off the top of my tired head.)
But for 64 bits the world of encoding gets *very* interesting. Back to the 64-bit floating point number...
In the 64-bit world, just represent a 64-bit FP number as... hey, a 64-bit FP number. Use all the bits!
But then how do you represent everything else if all the bits are used for FP? Well, there are a large number of 64-bit arrangements that are not actually FP numbers, rather they are "Not a Numbers" or NaNs. But not all 64 bits are used to indicate some arrangement is a NaN. Actually a small number of bits are used to indicate NaN (something like 10 or 11).
A very large number of integers can be represented as 64-bit FPs. Only the *really* *really* large need to be memory allocated. A lot of other interesting data can be represented immediately in the 64-bits (and so passed around in registers, stored immediately in vectors and matrices, etc.) These data might be characters (easily up to 32-bits of character data, more bits could represent common fonts, styles, etc.) 32-bit color, the same.
Dynamic languages like Smalltalk become significantly more efficient for number crunching (engineering, finance) because they're no longer using memory allocated numbers for floats and large integers.
