Charles Miller tells how Google is raising the ante on web user interfaces...
if you develop web applications and you aren’t looking today for ways to include dynamic interface techniques like those made practical by XmlHttpRequest, you’re going to end up losing to someone who is.The good news is creativity will be unleashed. The bad news is we'll get to experience some wrong paths. Such is life.
Ian Bicking in a comment on James Robertson's blog...
Alan Kay is doing a bad job getting his ideas out. Which is weird, since it's not that he isn't trying. There's a lot of writing about Kay on the web, but very little by him. From what I can tell, he doesn't even have a web page; "Alan Kay" on Google produces 10 biographies. These days primary sources are the norm. I think his ideas are being overlooked as a result.
Like Joel Spolsky, when I tried Google Suggest for the first time, I immediately set it to be my home page. Was Google, now Google Suggest.
Google is very publicly raising the bar on the quality of interfaces that people will expect from web pages.Some insight into what it's doing.
Sean McGrath, dynamic language advocate and Jython provocateur (!?), writes...
Psssssst: every time you use a JAR/CLASS you don't control, you have yourself an integration problem :-)Heed the call. Consider a recent topic in this blog...
I asked the question about the dotnet CLR (or CLS or something), why would you want one way to integrate outside the VM and another way to integrate inside the VM?
The counter example to this dichotomous approach is Erlang/OTP which is a scalable, robust, productized demonstration that a simple integration mechanism is suitable to both integration scenarios.
Let's complete this post by repeating Sean's message...
Every time you use a JAR/Assembly/Class/Object/API you don't control, you have an integration problem!
And even when you do control them, if they are heavily used, you have essentially the same integration problem, which is the reluctance, cost, time, perhaps inability, to change them with agility.
A fun, insightful explanation from Tim Bray on a really big problem you're not going to need to solve...
You... don’t want to have to temporarily store millions of values while you do the sort.Here’s the trick: nobody will ever look at more than the first hundred or so results. So you don’t have to sort at all, you just have to find the highest relevance values. Here’s the algorithm...
I wrote a few days ago that the sale of IBM's PC organization might benefit the industry by shaking things up, and motivating overdue innovation.
Robert X. Cringely takes this into a very interesting scenario that if true, certainly would force a good bit of out-of-the-box thinking!
Anonymous writes in yet another comment...
what exactly is the benefit of being able to run a variety of dynamic languages on either of those platforms? It seems to me that moving forward the most meaningful common runtime environment, for any application written in any programming language, is the network and its associated protocols (TCP/IP, HTTP, etc.)I agree. Then what *is* the benefit of dynamic languages on these platforms?
Personally, if I am asked to use the CLR or the JVM, I want to be able to use a dynamic language. I've used Jython, JScheme, and SISC a good bit.
Generally, remember when most programmers eschewed garbage collection? Those of us using dynamic languages then had a more difficult time integrating with "non-managed" (how droll) run-time than we do now intgrating with the JVM and the CLR. (So welcome thus far!)
When these systems go completely dynamic, integration becomes that much easier. In fact end-of-life'ing the JVM and the CLR become real possibilities. So my ultimate motivation for promoting this migration is to rid the world once and for all of the JVM and the CLR, those regressive monstrosities that they are!
Edd Dumbill on dynamic languages...
The ongoing silence from IronPython quarters does not encourage me at all.I'd prefer that academics work on advanced systems rather than re-engineering the industry's past mistakes. OK, just give them a grad student or two.It's time that the free software and academic worlds stopped waiting for Microsoft... Novell needs to take Mono to the academics and get them working with it.
James Robertson reports on this interesting success story...
The insurance system - the rate of change drove them to build a meta-data system. It grew to handle hundreds of insurance products. Once it wa sin place, it was easy to add new ones. It was handled by a team of about 10 developers. After a merger, they were faced with another team that had 700 hand coded forms that dealt with only 9 insurance products. In theory, the merger was in part to acquire the leading edge advantage of the Smalltalk insurance products. Politically, the larger team won and forced a re-write in C# (a political compromise).You can argue about how easy it is to integrate with some specific reporting package or XML parser. But Smalltalk can access all kinds of reporting packages and XML parsers, and has a few of its own.What they discovered was that Smalltalk's pure object model makes it far easier to deal with meta-models. C# and Java stand in the way. It's very hard to come up with patterns that would map the existing design onto C#. C# and Java are physically designed against meta approaches. The upshot - if you need to deliver a meta-model driven system, then expect to fail in C# or Java...
The real question is how well the language supports your business *ideas*.
With the [Smalltalk] system, changes were delivered immediately - the replacement C# system delivered them much more slowly - and it also required a larger team. The Smalltalk system was also faster.D'oh.
Read about other business successes with Smalltalk at Jim's site.
Ian Bicking in a comment captures the problem better than I have...
The CLR is trying to do something difficult. It's not just the kernel upon which languages can be built, but an infrastructure so that languages can be intimately combined. I suspect that there are some combinations that are poorly thought out. For instance, I don't think cross-language inheritance is useful or productive -- better to provide good alternatives (e.g., delegation); language implementations can pretend those alternatives are subclassing if they really desire to.Data sharing is important. But why this way with the VM and another way outside the VM? The essence of running a common runtime was interesting about 15 years ago. See the late Mark Weiser's work at Xerox on the Portable Common Runtime. This approach addressed the *critical* issues of sharing a common runtime. There may be one or two other critical issues, but they don't require a common object model. The CLS object model in practice turns out to have some uncommon and subtle anomalies; it's a hard problem for questionable results.But cross-language data sharing, including the sharing of objects, is quite important. You can't do that without some significant spec. Now, it might be a better, more evolutionary approach to put different languages on the same VM, and let them figure out the interoperability issues later. But even though that's a different process, it just delays the work, it doesn't remove it.
A third approach to language interoperability is to standardize on a common intermediate form. This is a variation on the privileged language approach, permitting different languages to interoperate as long as they use a common back-end. In spite of several attempts in this direction, the restrictions on language designers and implementors have proven too severe for wide adoption. We hope our more modest approach (agreement on important parts of the runtime environment), by analogy with the success of common operating systems, will prove better in practice...A good bit simpler than the CLR. Someone didn't get the memo.PCR itself is about 20,000 lines of C and about 200 lines of assembler.
The problem with the complexity in dotnet's CLR is that it's not addressing the *right* problem. Compare this to Erlang, Indigo, REST, and other simplifying approaches to "postmodern" programming. Agile software demands we keep our options open and avoid premature commitment to unnecessary complexities.
To repeat a quote from Dan Ingalls, below, "You clearly want the kernel to be as small as possible, so that you encounter barriers to change as infrequently as possible."
I agree with everything Ian writes here... and at the same time I don't feel Microsoft should get kudos for tackling the problem itself. They made the wrong choice to address the problem by overcommitting the kernel of the solution to ideas that just don't pay off in practice.
Simplicity, stratified design, regularity, small pieces loosely joined.
There are a lot of ideas, but really good ideas are hard to snatch because they look so humble when you first see them. You expect the solution to be beautifully complex and a good solution is pretty plain until you see how that plainness plays in a complicated way to make something better than you could get in your head all at once.
Tin Bray reports on a dynamic languages summit at Sun...
It’s pretty clear that dynamic languages are a hot area, maybe the hottest, in the world of software development. We need to do more to make them easily usable by people in the Java ecosystem...Looks good, based on the people who've managed to implement good dynamic languages on the JVM, and who've used them. The missing ingredient I'm wondering about is, did they try to invite some really experienced implementors of *high-performance* dynamic languages? Sun did have Gilad Bracha there with Anamorphic/Strongtalk experience.I confidently predict that as time goes by, more and more of the code written in the Java ecosystem won’t be in Java. This is a good thing.
Anonymous (you again?) writes in a comment...
Not sure what you mean by the "baggage in all the specific object model stuff".Consider the Common Language Specification. There is a lot of unnecessary stuff there. The design is begging to be more stratified. (See "Lisp: a Language for Stratified Design (ps))
Reading from "Smalltak-80: Bits of History, Words of Advice" (1983, pdf), Dan Ingalls writes...
You clearly want the kernel to be as small as possible, so that you encounter barriers to change as infrequently as possible.Given todays computational power relative to 20 years ago, reducing barriers to change is a nearly universal overriding quality we want in software systems. Certainly that is why dotnet itself has replaced C++ as Microsoft's vehicle for software development. Before that, a popular Microsoft combination was to use VB for most of the flexibility and C++ for the "services" available to VB to munge about.
The gravitational pull of this progression is centered in Lisp and Smalltalk. Undeniably the progression of the popular languages is essentially toward these spheres of influence. Along the way, ML and Haskell and other systems of course. (But even ML and Haskell come out of the *Lisp* and functional programming community.)
If you are looking for true enlightenment, read Richard Kelsey's "Realistic Compilation by Program Transformation" (1989). And if you get hooked and need a deeper fix, read the original lambda papers by Guy Steele.
Yes, the CLR has some baggage.
Considered Opinion writes in a comment...
Perl > Python > Lisp > Smalltalk - and none are well suited to typical business applications (good at all of: Security, GUI, RDBMS, Reporting, Distributed Computing, Reasonable Performance...)Ignorance is bliss.
On a much lesser note -- all have much smaller populations than MS or Java.At least you got that going for you. Ours go to eleven.
James Robertson writes about potential futures for ObjectStudio Smalltalk.
One option that might be in Microsoft's best interest could be Microsoft throwing a bit of money and expertise toward Cincom to get a Smalltalk running on the CLR. Work with the IronPython and CLR folks on dynamic languages, maybe even on some of the features Jim lists that make Smalltalk as good as it is.
Who knows? Could help Microsoft's dynamic language capabilities in general, and both organizations may benefit from a first-class Smalltalk system on that platform.
Updates: From comments...
"for any reasonable success, you need to interoperate intimately with .NET (or Java if you like)"This will come as a complete surprise to all the Perl, Python, Lisp, Smalltalk, and other developers who have been achieving "reasonable success" very well without such capabilities. Better get a memo to them soon.
"Just put a Smalltalk coprocessor on a removable PC card, add a field gate array processor and upgrade it twice a year. Get the extra registers Smalltalk has been craving that Intel doesn't have. With today's competitive chip manufacturing processes, it's within reach.Not sure the future success of Smalltalk should ride on convincing PC owners everywhere to put a co-processor into their boxes, no matter how cheap it may be.The most popular class libraries get put in the VM.
The most used classes in the VM get put into the field gate array.
"
First of all, this suggestion seems to ignore the reality that Smalltalk execution is very efficient on the processors those PC owners already have in their boxes.
Second of all, putting classes into the VM, not to mention onto hardware, is not a very smart decision. Read a little about the history of Lisp and Smalltalk then look at the CLR for potential improvements that could be made *there*.
"The most used classes in the field gate array get (automatically) submitted to a company that balances cost, demand, distribution, and chip limits to create a run of these PC cards."Sorry. You flipped the bozo bit.
End of Updates.
Someone's question...
"...Why run Smalltalk on .Net? Seriously, I just don't get it...why would you want to?..."
In a comment on James Robertson's blog, Socinian answers the question...
Access to unique device hardware, network security, code/data security, active directory access, etc. Managed code, because eventually, more than one machine will be executing/managing it. Also connecting to 3rd party applications. You can't just compile/link, DLL call, API function call, or SOAP any more.I agree with the vision. The current implementation of dotnet, plus the baggage in all the specific object model stuff, etc. would not lead me to believe this is the vision for that runtime model, however. (N.B. I have been wrong before.)You have to look where things are going. Cell CPU's, programmable appliances, utility computing, virtual OS, and large cluster computing. Do you want to rewrite a new VM for each of these and what's ever next? Let someone else do the work, so you can focus on a productive application. It's easy to get stuck in a one CPU perspective of the world. Unfortunately, this will change the way applications are created, used, and migrated, as surely as cell phones changed the time and place that we communicate over distance.
I would consider Erlang/OTP, Gambit Scheme, Cincom (VW) Smalltalk as better starting places (among several others), for inspiration if not implementation in support of this vision. Note that Gambit Scheme has hosted Erlang in a prototype that appears to be roughly equivalent in scalability. Note that the Cincom Smalltalk VM appears to be scalable for web systems and capable of running Python a good bit faster than CPython. So I am nominating them as candidates for hosting multiple languages on multiple platforms in support of the dynamic vision above. And with a fair bit less overhead than is apparent in the dotnet runtime as per its own definition.
Just a guess, but with some evidence.
Update 3: Anonymous points out that Jim Weirich has an inspired exposition of the spreadsheet implementation in Ruby. Very nice.
Python and Ruby are excellent languages. There are just a few small cracks in these languages where if you look carefully through them toward Smalltalk and Lisp, you can see how truly gifted, or maybe just lucky, the designers of those original dynamic languages were. These are just small cracks though, as Jim pointed out in Ruby and Ian Bicking mentioned about Python, for example, that delaying some of the operators with Formulas is difficult or impossible.
This is a lesson for designers to be as regular as possible. (If you are into the theory of regularity in design: pdf) End of Update 3
I've wondered several times in conversations why the concept of a spreadsheet is not more easily a first-class feature of popular programming languages. There is a long history of constraint programming of various flavors that show up typically as an API in an imperative language or as the dominant style of a new language. (Mozart/Oz comes to mind as a language that emphasizes constraints but does not make them dominant.)
Kimbly points to an approximation in Python...
>>> ss = SpreadSheet()
>>> ss['a1'] = '5'
>>> ss['a2'] = 'a1*6'
>>> ss['a3'] = 'a2*7'
>>> ss['a3']
210
'a1*6'. A first-class implementation would be done entirely in the language per se. After the text 'a1*6' is passed around, which functions assume it is just text and which assume it is a constrained expression? (We like objects.)
When I have seen a "spreadsheet" implemented in a language, invariably the objects are exposed through a user interface primarily, and programmatically through an awkward API at best. (With certain exceptions, in particular Lisp, which make programmatic integration essentially transparent, everything looks the same.)
In Smalltalk, maybe, using points rather than the alphanumeric column/row convention...
ss := Spreadsheet new.
ss cell: 1@1 value: 5.
ss cell: 1@2 value: (ss cell: 1@1) * 6.
ss cell: 1@3 value: (ss cell: 1@2) * 7.
(ss cell: 1@3) value
210
Update: Matthias Ernst asks in a comment...
Don't you rather want:The use of a block here is intended to "delay" the computation until a change to a dependency forces a revaluation.
ss cell: 1@2 value: [(ss cell: 1@1) * 6]
Add cell value caching and invalidation after change.
The problem then is the programmer has to know where to put the blocks to delay computation and where to force the revaluations. Instead of blocks, though, my intention is to use some new object, a Formula, say, and to make those objects implicit as much as possible.
So the message Spreadsheet>>cell: aPoint value: aFormula would store the formula at the cell's point in the spreadsheet. If aFormula is not a Formula, then it is assumed to be a constant, and so the spreadsheet would wrap the constant in a subclass of Formula, say ConstantFormula. (Probably the thing to do is to send the argument the message Object>>asFormula which would simply return itself if it is already a formula.)
The result of the message Spreadsheet>>cell: aPoint is a Formula (which may be a ConstantFormula) and so to get its value, send it the message Formula>>value. (e.g. the last expression in the example returns 210.
But what about (ss cell: 1@1) * 6? The expression (ss cell: 1@1) results in the formula at the point 1@1. The result of multiplying a formula by a constant is a new formula that does the obvious multiplication when evaluated. (And since multiplication is commutative and Smalltalk allows you to redefine "system" methods, numbers should understand (through double dispatching) that the result of 6 * (ss cell: 1@1) is also a formula.)
*"is not a formula" does not mean your code should test for the class of the object. Rather a message, say Object>>isFormula, should be sent to the object. the default implementation for all objects returns false. The implementation of Formula>>isFormula returns true. Other implementations may return true as well if they are intended to behave as formulas rather than as constants in a spreadsheet.
**Double Dispatching: Yes, multiple argument dispatching in CLOS is better, and yes, Python has this in 2.4. Maybe something should go into Smalltalk, but the good news is you are free to try it then tell the rest of us. (Dan Ingalls, Ralph Johnson, Andrew Black)
Update 2: Gavin McGovern writes in a comment...
One of my favorite spreadsheets is Levoy's "Spreadsheets for Images",Nice. Thanks. This is kind of like Kurt Piersol's spreadsheet in Smalltalk he presented at OOPSLA '86. He uses image processing as an example of operating on non-numeric data. (Unfortunately or not, he also extends the syntax for operating on spreadsheets. From the examples above, I am not yet convinced this is necessary.)Bit backwards: he essentially put Tcl (+ image stuff) in a spreadsheet. But a neat example nonetheless of a alternative user interface.
Update: More good architecture from FLW via Chris Petrilli.
I was a real architeture student for a couple of years. In the middle of my umpteenth all-nighter getting a drawing acceptable for some reverse-disaffected grad student's criticism, I figured I was never going to make a living making great architecture. Now as it turns out, even the great architects don't make a living making great architecture. What crap is this? Or this? Or this?
Then again there is this, and this, and this. Perhaps this. As in any system, the bigger the badder. Small pieces, loosely joined seems to be a recurring theme. How about this?
A gem from Brian Foote. Heed...
People want assembly to be antiseptic, and free. It ain't. It takes time, and skill, to fit materials to the site, and the task, and craft them into an integrated whole. People don't want to live or work in prefab trailer park modules. They want real homes, real stores, real offices.I've been re-reading some of Christopher Alexander's work, and remain skeptical that either good buildings or good code can be seamlessly, effortlessly conjoured up out of Lego blocks.
Good dynamic languages (e.g. Lisp, Smalltalk, Python) are dirt simple...
Compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain...(via James Robertson)If you have a thick skin and don't mind being laughed at, try explaining to a Lisp programmer why your application needs XML!
I don't want to go too far toward making some classically stupid prediction. But frankly I am not looking for much change in our current programming languages.
We need all new models rather than incremental "improvements". Agile languages can be improved incrementally without a lot of central organization.
This is all dancing around the real problem of making computing more accessible to "end users". Face it, programmers are today's telephone operators and we are simply in the way. We'll continue using our quaint little notations for some time to come, but these efforts should be focused on eliminating what can be automated toward all new concepts in computing.
Doc Searls says IBM's selling of its PC line is sad news. Although I use a Thinkpad at work (and should be getting an upgrade real soon now), I'm not sure this is sad news.
Where is the PC market going? I think it needs a good shake up to bring some creativity back. Maybe this shedding will allow some of that... well, this is IBM we're talking about. But maybe this will shake enough up to jump start the beginning of 21st century consumer computing rather than squeezing out ever finer inefficiencies of a 20th century product line.
