Quote...
As predicted by Dick Cheney on le show, the Dr. David Kelly story has slipped from America's journalistic radar. But it's still big news in the UK, as is the subsequent war between Tony Blair's government (backed by Rupert's newspapers) and the BBC. I have become a believer in reincarnation: Spiro Agnew is alive and working for Tony Blair, and, in this country, Dr. Fred C. Schwarz (of the Christian Anti-Communism Crusade) has come back as a leggy blonde anorexic.
James Robertson asks the 64-bit question for Smalltalk.
Implementing dynamic languages with 64-bit words always had an appeal to me for this reason:
You can encode 64-bit floats as literals. Everything else can be encoded within a NaN. The result is that arrays of large floats are more efficient in space and time, enabling more efficient analytical computing. You can also encode more information in an immediate object, like characters with styles, full 32-bit integers without shifting tag bits, etc.
I am beginning to believe this sincerely. Note that it does not say "only weapon", but it does say "most compelling"...
Jython, lest you do not know of it, is the most compelling weapon the Java platform has for its survival into the 21st century
Franz now has a SOAP implementation for Common Lisp. Great news.
"When I last looked at SOAP it was annoyingly complex. But that doesn't mean it's not important..."
Perl 6 looks to be delivered on the Parrot virtual machine, which looks to be more and more suitable as a target for the full Scheme language.
If the goal is truly to provide a universal base for executing any language then toss out the virtual machine altogether. Or at least abstract it away for language providers.
Don't make them twiddle with bits just because they implement "compilers". Let them simply translate to another higher level language, as Richard Kelsey demonstrated well over ten years ago!
We (the industry) seem to be stuck in a virtual machine rut. Has anyone asked why that's a good idea?
My track coach in high school told me what "assume" means 25 years ago. We base soooo much on unproven assumptions in this industry.
"Perl 6 to Scheme. Come in, Scheme."
Martin Fowler urges the data people and messaging people to talk, but not to define a single model.
This makes sense whether you are talking about enterprise databases or enterprise messages. I would add two points. The final one, if you want to cut to the chase, is addressed pretty well by Cutter's Doug Barry.
The first is that although enterprise models are not easily "big designed upfront" there are proven techniques for supporting their emergence. The best I know of comes from Ralph Kimball, who I've written about before in the context of enterprise integration.
The other point I would add is that Martin is really addressing at least two significant issues. In addition to the perils of enterprise modeling, he's made an implicit point about messaging and databases. I'm not going to put words in his mouth but he could have pointed to his peers efforts to illustrate what he means by enterprise messaging.
I am not sold on the idea of general messaging. There are special cases where a high performance message product makes sense, e.g. broadcasting large volumes of financial information on a trading floor is the motivating example.
In the general case, messaging is just too much like a crippled database that assumes the consumer is not the provider. You end up with an additional product and all the associated costs. I think there is a lot of room for improving 80 percent of the cases a relational database is applied to, but not at the expense of an entirely new and yet severely limited product like messaging. (Hint: every messaging product has some kind of simple persistence mechanism you can't get to in a general way. Why?)
I would choose either low cost databases for Martin's integration scenarios, or, more ideally, a simple XML-based tuple space-like database. Either approach can be used in a myriad ways without assuming the consumer is not also the provider.
Doug Barry kind of addresses this issue in a Cutter report. He is a fellow traveller from the Object Oriented Database market. A full OODB is overkill. So is a full relational database, but at least they are commodity and not so esoteric.
This second point is we need simpler database products rather than messaging products.
Via Lambda the Ultimate we see Don Box wanting less code to espress a simple concept. This makes sense and corresponds to the conventional wisdom that programmers can get X lines of code running per day no matter what the language.
Reading between the lines the argument is that *explicit* static typing is just not a good idea, period. Dynamic languages and static languages based on type inferencing are the result of taking this direction to the limit.
I am not convinced static typed delegates vs. static typed classes in and of itself is that significant. Why not simply be able to pass methods around as first class objects without having to declare somewhere that it takes no arguments and returns a boolean? In a large post-modern system there will be at least a half dozen different such explicit declarations for programmers to keep track of.
Jython provides an example of how anonymous classes can be replaced by simple functions rather than pre-declared "delegates"...
In Java...
Button button = new Button(parent, style);
button.addActionListener(new ActionListener() {
void actionPerformed(ActionEvent e) {
// Take some action here.
}});
In Jython, this can be replaced with a keyword parameter and function argument...
button = Button(parent, style, actionPerformed=self.actionPerformed)
...
def actionPerformed(self, event):
## Take some action here.
I came across a new book on rule-based expert systems with Java and Jess. No review yet.
From the Manageability weblog comes the question and some answers about the ability to hide concurrency issues through one form of abstraction or another.
Functional programming is dinged for not having a concept of state or time. This is a misstatement. There are several ways to represent state and time in functional languages. It's just that none of them are that much better than they are in other styles of programming.
Toward the end of the item there are some subtle observations...
In short, it's all about coordination, and if you can build effective coordination mechanisms then you're on the right track to solving the real problem. To say that it can be abstracted away isn't solving the problem, it's denying the problem exists.
Ah, but what the item does not address is what are the various ways of abstracting concurrency. Abstracting does not always mean "hiding 100 percent".
The key is to build appropriate abstractions for representing concurrency, rather than hiding concurrency. For example an effective technique for avoiding deadlock is to assign an order for aquiring resources.
The difficult attempt would be to hide the fact that multiple consumers are competing for multiple shared resources. The typical attempt would be to explicitly code the competition using some low level locking mechanism.
The "just right" attempt would be to evolve an API that describes the desired order of consumption, holding on to multiple resources (or not), and the exceptional behavior for waiting.
One thing we need are better modeling and testing frameworks for concurrency scenarios.
We can also simplify the API evolution through higher level concurrency mechanisms like tuple spaces. Tuple spaces provide a few simple operations that act as building blocks for a wide variety of scenarios. They can be applied to in-process, multi-process, and persistent or transitory scenarios.
Python just became that much more interesting for programmers not sold on it yet.
Word comes from Kevin Altis on work done by Ralph Thomas, Joerg Budischewski, and Christian Zagrodnick on "Python-UNO bridge for OO1.1", a Python integration with the Open Office API.
Great news for open source desktop software and developers.
Russell Batie is learning Python, but I wonder if he has really
Basically, I can't help thinking that Java could be made to work more like Python. I mean, there's Jython, but I don't want to talk about half-ass implementing Python on Java, I'm talking about making Java more programmer friendly like Python.
Jython is a complete Python. (Full-assed?) I would argue that Jython can also be considered a "Java made to work more like Python".
Java is established. I don't want to see the language change (much) at all. Jython is the Python way of programming with the Java class libraries. The two work together well, but one should not become too much like the other.
The distinction is beneficial and harmonious.
...and more to Henry Lieberman, himself one of the seven (or so) wonders of the software world.
A favorite from 1986's first and perhaps best OOPSLA, "Using Prototypical Objects to Implement Shared Behavior".
Another Lieberman classic not given nearly enough exposure, "There's More to Menus than Meets the Screen".
PLATO is one of the seven (or so) wonders of the software world. Not given nearly enough attention.
More than one of my favorite stories about programming comes from WyCash.
The number one item from the OSCON session by Robert Lefkowitz (r0ml) on "The Missing Open Source Projects" is...
Distributed CRON
I would look to the Erlang framework for this. Simple, distributed, robust, persistent, monitored, and integrated. I'd guess the Erlang OLTP is well above 80 percent of what is needed for an industrial strength distributed CRON.
More systems should be emulating the Erlang framework for distributed systems development. (Assuming programmers by and large are not going to adopt the Erlang language per se.)
Jon Udell is investigating Test-First (aka Test-Driven) Programming...
Test-first is quite radically different from test-later. And the most important difference I've discovered so far is that test-first... is as much a tool... exploration of the problem domain... as it is a way of protecting against regression.
You've got it Jon. I think of it this way...
Test-driven design tools are "command line interpreters" for Java, C#, and other "non-interactive" programming languages.
Programmers using Lisp, Smalltalk, APL, and other "interpreted" languages have been doing test-driven design for decades. The pattern here is to type little snippets of code for an idea, get immediate feedback, then gradually incorporate those snippets into a whole program.
Lisp has its read-eval-print loop. So does Python. Smalltalk traditionally has "workspaces" which are text editors that also evaluate highlighted code.
In either case, the end of a programming episode results in a transcript of code that is then allocated to two destinations... some of the code in the transcript are the objects or functions that go into the program itself. The rest of the code is edited into regression tests.
Looking at a test-driven incremental programming session using junit or nunit you see the very same result... the shell is the command line and xUnit is the "interpreter". You get a small idea, test it, and repeat.
The tests themselves are the "transcript" of the session, and are also the preserved regression tests.
This approach is so successful that it provides discipline for Lisp and Smalltalk programmers too. I think Kent Beck originated sunit (for Smalltalk) as a way to demonstrate to new Smalltalk programmers how to use workspaces effectively.
...goes to Kevin Altis for pushing hard for Jython as a scripting language plugin for the Eclipse IDE.
...goes to Ticketmaster for a very plainspoken description of their use and relationship with OSS software and people.
All I know is what was presented, asked, and answered in the session. That said, they appear to use OSS to their advantage, manage it well, and give back to the community including hiring good OSS developers to implement features they need and that the community at large can also benefit from.
...goes to DJ Adams and Piers Harding for their servlet written in ABAP, the programming language inside SAP R/3.
Yesterday at the Applied XML conference an involved discussion took place about complex types, specifically a Map (aka Dictionary, associative array, property list). I was thinking about the origins of the problem more than the problem itself, because it didn't seem like such a problem in the first place.
Only in languages derived from C could Map be considered a complex type. (I translate "complex" to "unusual"). The major scripting languages (Perl, Python, Ruby) being discussed this week at OSCON have this type as the bread and butter of their existence. There is nothing complex about it, and you couldn't dream of connecting processes with these languages without passing Maps around.
The Great Ancestors of these languages, Lisp and Smalltalk, were created by the Gods themselves (MCarthy, Kay, et al.) fashioned out of the true primal matter, which is not int, but association.
When Dave Winer froze XML-RPC (I don't know much of the details), it's most notable that it consists of two fundamental structuring capabilities: a list of things (called Array) and an association of things (called Struct).
No one argues over this. Every language has an XML-RPC implementation. It's funny that three or four years later the descendent, SOAP, is still wrestling with such a fundamental construct.
I think has more to do with ancestry than technology.
Attended Dana Moore's session on Python and other dynamic languages in a Java/dotnet world.
Fun demo manipulating the Microsoft clippy guy from Jython via XML-RPC to CPython manipulating the clippy guy's active X thinga-ma-thing.
All is love when it comes to dynamic languages.
November 2001 - Eclipse launch
Tools don't work well together. Tool vendors reinvent wheels. No vendor can do everything.
In Java no platform with strength of MSFT's Visual Studio.
Eclipse is a platform - extensible. Works out of the box. Companies contributed tools right away.
OSS chosen to support platform adoption.
"Tool stacks" per language type innefficient.
Eclipse is not a tool with an API. It is a platform for plug ins. Turns the picture upside down.
Small runtime + plugins. Plugins extend other plugins.
Architecture and demo (John Wiggin?)... internal team plays by same rules... plugins on small kernel... as all developers.
Team facility, repository support in OSS and commercial... (I guess this ties in to O'Relly's network collaboration talk)
Debug component... (who debugs programs?)
(Eclipse if you have not seen it is a Visual Studio look alike to my untrained eyes. Lots of panes with information here and there. People like these, I've not used them. Interesting challenge... I wonder how simple the UI could be made and still take advantage of useful plugins. How tied are the plugins to the UI look and feel? COuld you build Emacs in Eclipse?
(Talked with Kevin Altis last night... he's big on getting Jython into Eclipse as a scripting language. I've been doing a good bit of SWT programming in Jython outside of Eclipse... I think this would be a good idea and would lend toward getting an Emacs like capability into Eclipse, and could thus support a simpler interface Look and Feel for Emacs die hards at least. I'll look these guys up afterwards... this would be a good test of the plugin architecture, so maybe a few folks would like to collaborate (phrase of the day))
(Paul Buck is talking again...) COBOL development environment. Hades test framework. Eclipse modeling framework - abstract data types.
Technology PMC - further out, independent, experimental work, academics. "Coy" project (?) led by Instantiations (Portland!) doing something interesting... didn't say what. They're Smalltalk people, though and have done good tools stuff there.
New project for J2EE tools started last month looking for collaborators. See Eclipse.org
Next big step is moving beyond IDE into rich client platform. (Hmm.) SWT GUI toolkit for desktop Java applications.
(Hey - and desktop Jython applications!)
So new set of challenges... (well what are they?)
In closing... Websphere studio workbench is branded supported version from IBM. THE END
The value of Amazon, Google, etc. is the constant update via the people.
Network collaboration - Usenet is the mother.
Ad hocracy (Doctorow) - OSS is one.
Software paradigm of the future => *Collaboration* paradigm of the future.
Collabnet puts in OSS infrastructure inside organization's firewall, e.g. HP's printer drivers.
ASP.net reengineered ASP for XML - denied, backward compatibility. Six weeks time to hack it anyway. People took pieces of code here and there they liked then Gates annointed.
Network + Developers == OSS-like behavior.
"Listening to Napster" - keynote at a P2P conference. People can build a collective work as a by-product of their own self-interest.
Watching connections in Google, Amazon, elsewhere e.g. - we contribute with every link, book, etc.
Linus - essay in Open Sources - architecture of Linux and Internet supports individual contributions that add up.
Just now in throws of figuring out new business models. IBM Websphere, Mac OS X look like the Compaq business model. Selling commodity with add-in value.
Who will come along with the Dell model - "build commodity to suit." Key is the process of assembling the product, not what the product is.
Cable TV - pay per view not as successful as subscription. Aggregating larger packages of OSS.
Professional services business model not the most interesting thing.
UUNET made money with services - low margin ISP w/billions in revenue. Not by packaging UUNET software.
Network Solutions did not want DNS registration - then found the business model and did not want to give up the monopoly. Another ISP.
OSS developers need to pay attention to things not central... P2P, Rendezvous, Hydra, wireless, "social software"... all about network enabled collaboration. Or you will get behind the curve.
Increased customization - not just software. Look for hidden service business models. Collaboration beyond software.
Mapping software has not figured out use collaboration yet... location based services, individual contributors of data points into what's happening on the map.
Watch the alpha geeks - prefiguring larger movements. Screen scraping predicted web services. Rethink OSS in context of web services and network computing.
Who owns the data? License implications of data relationships. What will the bill or rights be for web services?
Kurzweil - long term thinking. Build out into the future. THE END
...so far goes to Kevin Altis for:
Note to those of you not used to the lawns west of the Rockies; there are no chiggers here, so sitting on the grass is fine :)
So true. I used to hate those damned itchy bastards. Which reminds me to stay of the grass in shorts when I go to Ohio in a couple of weeks.
Argh.
From the referenced web page...
Probably no creature on earth can cause as much torment for its size than the tiny chigger... Their bites produce small, reddish welts on the skin accompanied by intense itching as irritating as acute cases of poison ivory or poison sumac. These symptoms often are the only way of learning that an outdoor area is infested since chiggers are so small that most cannot be seen without a magnifying glass.
Wireless is working, thanks O'Reilly, et al.
Attended the first couple hours of OSCAMP this afternoon.
1:30 The Economics of Open Source (Stormy Peters) 2:00 Linux in the Enterprise - An IBM Perspective (Dan Frye) 2:30 Legal Framework for Open Source (Larry Rosen)If you're reasonably up on Linux and OSS then the first two sessions were nothing new. These sessions are mainly for people and businesses just dipping their big toe in the water.
Dan Frye was asked (by me, actually) when the vendors will smooth out their differences. I ask because he made a big point about the hardware portability of Linux, but nothing about the differences among distros, which can be a big problem as well for businesses and individuals. And can result in hefty support fees, etc. because of vendor lock-in, which is not what OSS is about, is it?
Anyway his answer is progress is being made, it gets better over time, but no commitment to a timeline from the vendors.
Larry Rosen gave an interesting talk about OSS licenses and in particular his own license, which addresses concerns he has with the several dozen others that are available.
Came out last year at OSCON, but this is new to me.
Took a walk over to the Marriott to take care of some business... now back for the last hour of OSCAMP.
I will be showing a very simple start toward an adaptive blog tool at the Applied XML conference on Thursday, as an example of using XML, Python, and XPath.
The intersection between blogs, Wikis, semi-structured data, and more structured data is extremely rich. Something like Infopath is just scratching the surface, I'm sure.
I use OS X a lot and I am pleased that Apple by default installs usefull scripting languages like Python, Ruby, and Perl by default.
I use Jython with the Java Platform. It's a nice combination since a lot of "CPython" runs in Jython too, combining the two platforms with the ease of "scripting".
It really is a combination since Jython classes can be used in Java as well as the other way around.
I'd like to see this philosophy continue with dotnet as well. The scripting languages don't seem to be coming along as quickly. At least I don't see as much attention paid there. Smalltalk is coming along slowly with three implementations I know of.
Also I'm curious about the direction of SOAP, et al. Over time I would expect easier language integration across runtime engines and less attention paid to language integration within runtime engines.
This has to be easy and inexpensive to program to be truly effective. The hardware will make it fast.
If you use blogger, check your feed. My feed was turned off the last couple of days somehow, perhaps as part of their recent upgrade.
Anyway, I had to go back to the settings and turn it on. Everything seems fine.
Ted and others, re: OSCON...
I'm still interested in Patrick Logan's "What's Next" discussion. Can we do this Tuesday or Wednesday night?
Great. I am available Tuesday around 6:30. Wednesday is not as good. It looks like 6-7 or after 9.
If Sam is still interested, looks like he's not in town until Wednesday or Thursday.
James was interested too. Maybe he'll chime in.
Some say that by 2025, water shortages will plague as much as half the world's population.
Do we have any real sense of the value of water?
Ted writes about OSCON: Should we organize a blogger's gathering?
I might be able to attend, but my time is stretched already.
Is Bush being cavalier with US troops in Iraq?
'Bring them on' is not exactly 'Let's Roll,' is it?
Sometimes I wonder if the USA would be better off with a parliamentary system. The US government (a kind of presidential system) is never really supported or forced into having truly vigorous debates.
The other thing I admire about parliamentary systems is the quickness of the elections. Bam! There's an election and Bam! it's over.
In the US we've already started the 2004 presidential campaign. Fundraising and the deliberately stilted primary firewall will take care to preserve and further polarize the two party system...
"In '84, primaries were spaced farther apart and big expensive media states came later. Now, the schedule is compressed and expensive states are holding primaries earlier, favoring establishment candidates."
No, not my birthday. Tomorrow is Independence Day in the USA.
I wish for a reasonable third party candidate.
Not a third party candidate for the far left, like Ralph Nader. Not a third party candidate for the far right, like Pat Buchanan.
Most people are middle of the road, by definition. The Democrat and Republican parties force most people to swing to the left or the right on all issues for better or worse. There is increasingly less room to be reasonable about anything. The parties don't mind dividing you in order to build a large enough coalition to get into or stay in office. They don't mind rigging election politics together to rule out strong middle of the road candidates. That's one of the few remaining issues they can agree on.
We need a third party candidate for the middle of the road. Most people are reasonable. A reasonably effective candidate with an effective (web-based?) fund raising plan should be able to pull people back to the center.
Or maybe one of the two parties will realize that the middle of the road is the best place to be.
Dave Winer embeds a reference to the simplicity of Python...
I have expressed an opinion that was rejected, that what matters is what the XML-RPC call looks like in your programming language. I still strongly believe that... It's also the reason Python is one of the more popular languages for XML-RPC apps, because it has a very flexible way of creating remote procedure calls that look much like local ones.
I have taken a liking to Python over the last several months. I used to be more of a snob. Python seemed to be a grab bag of reasonable ideas that were better expressed elsewhere. The thing about Python though is it seems to work well in practice.
Andreessen went on to call the state of browser navigation "an embarrassment."
"We had about 18 different things...in mind for the browser," he said.
Disturbing stats for the state of democracy from the Miami Herald.
A third of the American public believes U.S. forces found weapons of mass destruction in Iraq, according to a recent poll. And 22 percent said Iraq actually used chemical or biological weapons.
With amazingly misinformed statistics like this, how can the American population in general be concerned about "nuances" such as that either the CIA or the administration (or both) has "mishandled" evidence in support of the Iraq war?
What do statistics like this say about the "Information Age" or the potential contribution of weblogs to supplant the traditional press?
[The] poll's data showed that the mistaken belief that weapons of mass destruction had been found "is substantially greater among those who favored the war.''
...Before the war, the U.S. media often reported as fact the assertions by the Bush administration that Iraq possessed large stockpiles of illegal weapons. CBS News in December reported how Bush officials were "threatening war against Iraq and its weapons of mass destruction.''
Shouldn't supporters of the war be even more concerned than the detractors? Do we have to be "right" so badly, we're willing to be ignorant? How bad is it that these facts were "mishandled"? From MSNBC...
[A] senior CIA analyst said the case “is indicative of larger problems” involving the handling of intelligence about Iraq’s alleged chemical, biological and nuclear weapons programs and its links to al Qaeda, which the administration cited as justification for war. “Information not consistent with the administration agenda was discarded and information that was [consistent] was not seriously scrutinized,” the analyst said.
From the Register. They usually shoot pretty straight.
[While politicians] are a peculiar and varied breed, there are three things you can be fairly certain will not hold much sway with them:
Ideological argument. Politicians are nothing if not pragmatic. Their very survival is based on seeing which way the wind is blowing and adjusting accordingly
Little-man defence. Politicians will not risk upsetting rich and powerful people and companies unless there is a principle at stake: that principle being that the government ultimately decides. Therefore arguing a point on the basis that it will restrict or impair a powerful body is counterproductive
Criticism. Politicians do not respond well to criticism. In fact, the more they get, the more stubborn they become. Flattery is the surest route to their heart, and this means making them feel important. Wining and dining, listening, applauding their insight and then putting your point across
Danny Ayers says "Sure there will be inconveniences in a transition period, but that is often a side effect of progress."
It seems to be a poor choice of timing to start such a transition. Maybe this is progress, maybe not. Time will tell how significant the progress is relative to the chaos.
Many people are just beginning to be familiar with blogs and RSS. The RSS/Echo affair may complicate whatever confidence they otherwise would have had investing in RSS for applications they don't get free. For example, if someone is building an RSS feed for some internal source of data, do they stop and wait for Echo? You may feel there is a right answer to this question. Someone else may be uncomfortable enough to stop development.
Time cannot tell whether there would have been a better way to go about this. Kind of funny all the fuss. Fairly innocuous geek thrash sometimes has real monitary damage. We may never know some of the damage that's been done, even though the end result may appear generally to be a success.
Maybe next week will be a time to break bread so we can get on with the business of building better applications.
Weblogs are sub-optimal. RSS is sub-optimal.
The best thing to come of this recent RSS/Echo issue is that Sam Ruby has demonstrated the value of the Wiki Wiki Web.
Funny that Echo could not have been designed very well with weblogs and RSS, er, Echo.
What's the best thing about aggregators? The fact they mainly visit weblogs? No. The fact they use RSS? No.
The best thing about aggregators is that they are better user interfaces for browsing the web than Mosaic, which is really what we're still using when we use IE.
Well at least Mozilla and Safari have tabs, for crying out loud.
What do we need, another Echo? Nope. We really need better applications. What happened to that Web Services revolution anyway, that the heat generated in 2003 is about HTTP.
Agile development methods are being credited with increasing numbers of successful software projects. Can you find them mentioned in the SWEBOK? I did not read all 200+ pages. But I searched for several terms I would have expected.
I can't either. Via James' blog, Cem Kaner has some serious concerns about the implications of SWEBOK. This work is almost frozen, having been developed in parallel over the last few years alongside the agile approaches.
I would have assumed a SWEBOK-like effort would be intended to eradicate ignorance, not institutionalize it. Sponsored by the IEEE, which has published a fair bit about agile approaches, this gap should be considered a deal breaker for adoption.
I am genuinely surprised and will look a little more closely at their proposal to see what I missed just by searching.
Phil Windley presents another effort (or two or three) to take some existing functionality and express it as an XML-based standard.
XACML is the language of the Policy Decision Point, of PDP. The PDP is the chunk of code that recieves access requests, checks to see whether they should be granted, and returns an appropriate response. The PDP is not necessarily the same as the place where credentials are stored. It merely needs access to that service, ideally via SPML. The PDP could be a module running in the local system or a remote system accessed over the Internet.
Again I have to plead ignorance and plea for the principles, guidelines, and scenarios for when to use this functionality. Why is this the right thing to do? Is it ready to use? When would I choose something else? I hope I can dig into the references and find this information.
For example why are ACLs the right model? A capability-based model might be more appropriate, e.g. as provided by Waterken.
Update: John Robb's FUDeflection. Or redirection. Too soon to tell. The SOAP opera continues.
As someone with zero investment in RSS or Echo, I have enjoyed the past week or so from afar. Mostly waiting for Dave Winer to speak up, which he did, and did well. Now Jon Udell adds his take, which is not surprisingly insightful, but is surprisingly sarcastic.
He pulls it off. Here's the crux, though, in his more typically pragmatic style...
Anyway, Dave showed everybody how to use RSS. That's his crowning achievement in my book. Not the format...
Now that the dam has broken, Dave has endorsed the new effort. It must have been an incredibly hard thing to do. I have a teenage daughter and when it's time for her to leave the nest, in a couple of years, I hope I'll handle that transition as graciously as Dave is handling this one. Meanwhile, the Echo designers are -- not surprisingly -- converging on a core that looks a lot like RSS. So far they've discovered that a blog entry has a link, an author, a publication date, and one or more semantically-equivalent content items. Any day now, they'll conclude that it also has a description. There's really not much mystery about this stuff.
I did not realize what was coming with Echo when I reacted positively to Steve Gillmor's take on Microsoft and RSS a couple weeks ago. Of course when I was suggesting RSS might be supplanted over time, I did not think it would be for apparently political reasons. I certainly did not think the effort would begin any time soon.
My reaction to Echo is along the lines of many others: RSS (regardless of its many forms and politics, I mean the collective sense of "RSS") has just in the last months taken a spot in the zeitgeist. My god, it takes ages for these concepts to make their way into large corporations. And now we have to explain Echo? I'm not going to rush that one.
Henning Kagermann, CEO of SAP, says "We need to be more like the auto industry..."
Just in case you know anybody in Prague:
"Teddy Bears' Picnic" plays this Sunday, Monday and Tuesday at KINO OKO
Frantiska Krizka 15 170 00 Prague 7 Czech Republic
Judith Owen plays, with Harry Shearer on bass, Monday night at Zelezna Jazz Club
Zelezna 16 Praha 1 Czech Rep
Speaking of speaking at conferences, I will be doing that again at Chris Sell's Applied XML Conference in a couple of weeks. This time I'm using Python, which I consider a kissing cousin to the Lisp family along with Smalltalk, Ruby, and some others. Look at the code a couple messages below. You could wrap some parentheses around those statements and never blink.
Gordon Weakliem swears I turned him on to Lisp...
What led you to try Lisp?
I heard Patrick Logan speak at a conference about building web services with Scheme, which sounded interesting, so I read "The Little Schemer". Later, Paul Graham's writings, esp. "Beating the Averages", but also because I was feeling the limitations of the Java / C# family of languages.
Wow, Gordon. If only it were that easy with everyone else!
I recently started using JXPath, an XPath implementation for multiple underlying data models in Java. It works out of the box for DOM, JDOM, java.util.Map, servlet contexts, and Java Beans. Probably others.
I wanted to use XPath to query Jython objects. The really cool thing is the amount of code it takes to do so. It's so short I include it right here...
from java.lang import String
from org.apache.commons.jxpath import JXPathIntrospector
from org.apache.commons.jxpath import DynamicPropertyHandler
import jarray
class JythonPropertyHandler (DynamicPropertyHandler):
def getPropertyNames (self, py_object):
keys = py_object.__dict__.keys()
return jarray.array(keys, String)
def getProperty(self, py_object, property):
if py_object.__dict__.has_key(property):
return py_object.__dict__[property]
else:
return None
def setProperty(self, py_object, property, value):
py_object.__dict__[property] = value
def registerJythonPropertyHandler():
JXPathIntrospector.registerDynamicClass(PyInstance, JythonPropertyHandler)
And so...
>>> context = JXPathContext.newContext(some_object)
>>> context.getValue("frob[abc > 1]")
<__main__.Foo instance at 3278971>
Enterprise IT environments are a mess primarily because they've grown piecemeal by function and technology. Every business unit and indeed every project is "empowered" to make their own decisions. And so they rightly make the best decision for their purposes. Every vendor has some hook in their technology to bring you back to the trough.
Even if some Enterprise Resource Planner (ERP) met all your needs, how long before you could actually get to "All Your Base Are Belong To Us" nirvana? And so we have "Enterprise Application Integration" (EAI) and (new to me...) "Enterprise Information Integration" (EII). One approach to EII in the past has been to build a massive Enterprise Data Warehouse (EDW).
Another approach, Phil Windley writes in his blog item on virtual databases, "The biggest hurdle... is creating the... data model." and includes some useful references.
Another pragmatic source of inspiration is Ralph Kimball. First some history...
A significant contributor to the Xerox Star in the 1970s (which influenced the Mac, which influenced...), Kimball and peers at Metaphor in the 1980s pioneered data integration, iconic capsule programming, and end-user data analysis. Metaphor was sold to IBM and languished under the shadow of OS/2 politics.
In the 1990s Kimball went on to pioneer data warehousing design principles and the Red Brick OLAP database (also sold to IBM via Informix). He is now an independent consultant and popular author on data integration topics for OLAP.
His keys to an effective virtual database (or data bus architecture in his words) is conformed dimensions, smallest grain facts, etc. Most of these principles apply to the largest data warehouses or the smallest databases, and would benefit any Enterprise Information Integration effort.
Steve Gillmor on Microsoft and RSS.
Interesting ideas. But what is interesting about RSS? What is interesting about any protocol?
Maybe it's just that developers are using RSS and Microsoft likes developers. The protocol itself is nothing special, but that in itself is its advantage... witness the number of applications that implement it. It was designed by developers.
So simple protocols are good. Has RSS been through the scalability ringer yet? Does it matter? Another protocol will come along soon if necessary. The interesting questions are what to do with the protocol. That's what Steve Gillmor is getting at, perhaps.
Driving in Boston... Dave Winer has excellent advice...
That way a wrong turn, while it will still take you miles out of your way, won't waste hours of your time.
My first night in Boston (a Friday) my buddy and I spent driving all over town. Not deliberately. We were trying to find something, a specific restaurant I think, near Fenway, because we also wanted to see Fenway Park.
The next morning I looked at a map to see where we had been. Ommagod.
I learned pretty quickly to use the T.
I learned the next best tip when I met the woman who is now my wife. In particular this: get a '62 Ford Falcon and practice getting around the Fresh Pond rotary as quickly as you can.
She named hers "Buzzy".
Lots of discussion here and there and seemingly everywhere about Oracle and Peoplesoft. Of course this is just the tip of the iceberg in business software consolidations.
...they basically force users to comply to certain process and end-user has very little control to 'customize' the application.
Yes, these systems have evolved over decades. In SAP's case, R3 is a descendant of their mainframe product from the 1970s by way of their client/server R2 in the 1980s. R1 was incredibly innovative back then, and it helped SAP get to where it is today, because they had one of the first production-quality machine independent virtual machines.
Too bad the language was ABAP, aka "German COBOL". But it was the 1970s after all.
In any case the future will be interesting since the value in these systems to the vendor is their proprietariness. The value to the consumer is their automation first and their openness second.
They're all trying to open up and still maintain enough proprietary handcuffs to turn a profit. Their historic margins will fall. They're all going after the SMBs (Small and Medium size Businesses).
All the ERPs but Microsoft will probably end up with increasingly open source components and try to make their profit on services. Give IBM the odds here. But IBM will have to make some strategic purchases first to get to a higher business-level software foundation. (Anyone remember "San Francisco"? Before and After)
I posted a high level outline of a What's Next discussion. It's a Wiki page so anyone can mold to their liking. If you're interested, add and modify, but you may want to make the pages more like a "discussion in progress" before refactoring into a "finished document".
See also the What's Next home page.
To do: read the page from Bob.
From IEEE Spectrum, "The Blog of War"...
It's not exactly clear where blogs fit into the established media universe. The blogverse may be shaping up to be a kind of shadow media.
Trouble ahead
Trouble behind
And you know that notion
Just crossed my mind
The US Patent Office has so many trains running in opposite directions on the same tracks.
Switchman sleepin
Train hundred and two
Is on the wrong track and
Headed for you
Funny discussion about accents.
Here's my two cents from spending four years there 20 years ago...
I'd say you have acclimated to the language when you find your pronunciation of "Worcester" naturally rolls off the tongue as "Wuster" and "Peabody" has no logical pronounciation other than "Pea'bdy".
To be a true master you also have to be able to say with a straight face...
"Put that wicked drooring of the tree in my top draw, wudja?"
TCC is a small, fast, optimizing C compiler, linker, and loader. And the cool thing for dynamic language implementations...
With libtcc, you can use TCC as a backend for dynamic code generation.
This is very interesting. About 8 times faster than GCC. Why spend time on a virtual machine instruction set?
TCC can also automatically generate memory and bound checks while allowing all C pointers operations.
Quick thoughts before the weekend about what's next. After a web services foundation is in place, what do you set out to do with it? What metaphors guide your vision?
One metaphor is formulating: Conversations. Maybe in one sense something like Conversation for Action.
Another question, what current systems and applications most closely embody these thoughts, or your own thoughts about what's next?
Sam Ruby responds to my interest in WS-xxx...
[W]hat I most would like to explore is what is next. After Web Services.
I occasionally hear talk of an Internet Operating System. And as a group we obsess on what is the optimal design of an individual neuron.
Something nagging in me tells me that these are the wrong metaphors and that we are [on] the wrong meta-level. There is no brain operating system. The emergent behavior of a brain can't completely be understood by looking at how individual neurons operate.
The future is multi-cellular. The cell walls aren't necessarily distance, but represent trust boundaries. It will never be the case that all data will be directly addressible. We wouldn't want it to be.
I like this. For anyone inspired by this description, I'd like to organanize some conversations around this. There are all kinds of dots that can be connected.
Let me know if you'll be in Portland the second week in July (OSCON, Applied XML DevCon) and I can set up a "What's Next?" discussion if there's interest. Meanwhile I'll be thinking out loud here and I'll be looking for other responses to this query.
From Sam Ruby's comments pages, on SOAP, WS-xxx, and CORBA...
Sam writes: What I like about the WS stack is that if all you need is SOAP document literal, all you need to implement is extremely small.
Reply: Yes, a great boon for adoption.
Dave Winer writes: SOAP was created by people who develop applications, so it didn't suffer from a lack of applications to pull it through.
Reply: Yes, a great boon for adoption! 8^) You folks were not about to create a CORBA first and then build apps later.
And this is a problem, as far as I can see, with the WS-xxx stuff taking place today, which is more like CORBA than it is like XML-RPC. Shouldn't the WS-xxx folks be working with OMG on that stuff? Why isn't "Enterprise Web Services" simply the next CORBA 4.0 release with SOAP optionally (but efficiently) slipped into the stack? There are high performance, open source implementations of much of CORBA 3.0.
I can think of at least one reason why not, but it's not a good reason.
From The Institution of Electrical Engineers (IEE) Proceedings Software, "View-centric reasoning for linda and tuple space computation" (PDF)...
Abstract: In contrast to sequential computation, concurrent computation gives rise to parallel events. Efforts to translate the history of concurrent computations into sequential event traces result in the potential uncertainty of the observed order of these events. Loosely coupled dis- tributed systems complicate this uncertainty even further by introducing the element of multiple imperfect observers of these parallel events. Properties of such systems are difficult to reason about, and in some cases, attempts to prove safety or liveness lead to ambiguities. We present a survey of challenges of reasoning about properties of concurrent systems. We then propose a new approach, view-centric reasoning, that avoids the problem of translating concurrency into a sequential representation. Finally. we demonstrate the usefulness of view-centric reasoning as a framework for disambiguating the meaning of tuple space predicate operations, versions of which exist commercially in IBM's T Spaces and Sun's JavaSpaces.
From an Infoworld interview with Bob Metcalfe...
Ethernet didn’t seem to have the problems that bedeviled IBM's Token Ring and ArcNet. Did this play a role in Ethernet's success?
Yes. Ethernet was simpler than its alternatives. It didn’t, for example, rely on the circulation and maintenance of the token. And Token Ring mathematically and, I think, sometimes unrealistically had advantages over Ethernet as long as the token was humming along. But if that token ever got lost or duplicated to create a storm, then things went to hell in a hand basket pretty quickly. The simplicity also allowed the implementations of Ethernet to be simpler and cheaper and come to market sooner. I mean, Ethernet beat Token Ring to market by five years. So that’s quite a lead. That’s probably what saved Ethernet from the IBM juggernaut.
Jon Udell highlights a technology lost in the late 1980's "A.I. Winter", but which kind of hung around and is now coming back into its own. I'm a veteran of the A.I. Winter and was disappointed when very practical tools like KnowledgeCraft and GoldWorks were lost in the hype of those days. Looks like GoldWorks is still available.
Some more resources to add to Jon's list...
Phil Windley draws some good points out of the interview with Grady Booch. But, and there's always a 'but' when I read something, my philosophy is there's no point in not being a critical reader. If I end up in the worse case being wrong or mistaken, I've still learned something.
Grady Booch writes just after Phil's last quote... One of the advantages of platforms such as .NET is that they codify a lot of those hard things so that global decisions can be made intelligently, then carried out locally by the individual developers.
I think this is untrue. I don't know if Booch is trying to flatter Microsoft, or the readership of the dotNET magazine, or if he really believes this.
I wish the journalist would have pushed for more detail. Why does Grady believe this to be so? Wouldn't that answer help the readers of the interview with how they use dotNET?
For one thing, I don't believe this is true for any current toolset. I'm not singling out dotNET. There is too much complexity in software development. Yes, we're building more complex systems than in the past, but that's no excuse... we should be taking unnecessary complexity out and putting more facility in. Facile --- most software is not.
From an interview with Grady Booch in dotNET magazine...
Q: What is the future of Web services and GXA in conjunction with traditional development?
Booch: I'm pretty jazzed with the direction of Web services. We look at organizations that are already effective at building component-based systems. Meaning they know how to componentize their stuff and deploy them that way. For them the move to Web services is actually a small step. Plus it's not a difficult step, because it represents a different packaging for the things they're already exposing. But there's value in it because now it allows them to transcend a particular platform.
I'm working with a group I think I can mention publicly: MedBiquitous, a project at Johns Hopkins led by Dr. Peter Green. The essence of the project is to try to tie together the various medical research agencies and data across a variety of different specializations in medicine, so that you break down the barriers of specialization. That's a gross simplification of what they're doing but it's pretty cool stuff. The essence of their architecture is based upon Web services, which enables them to make key architectural decisions that transcend particular platforms and technologies.
How helpful is this for you? As a reader and developer, should you expect more from an interview with an industry leader?
This seems to me to be filler in between the ads. I'm disappointed.
I strongly recommend that people join the ACM and use its Digital Library and read some of the things that influenced all of us in the CSCW discipline, e.g. Turoff's early work in conferencing, Flores' work on speech acts/workflow, etc. It's never been more relevant. Now that people have realized that we need to move beyond the Web, there are tons of ideas ripe for the picking in terms of innovative architectures for interpersonal communications & cooperative work e.g. awareness & event notification architectures, real-time & replicated architectures, etc. Explore SIGGROUP papers; head down to Group '03 this fall, and blog what you hear.
This probably is obvious: I couldn't have said it better myself.
I've been a reviewer for several major conferences over the years. The striking reaction I get over and over is how few connections people make to the work that has taken place in our community. Software is forever changing on the surface, but when you get more than skin deep, there are so many common themes, sources of inspiration, and even words of caution.
In an earlier posting, I characterized one axis of the debate as robustness versus agility, and wondered how we can have our cake and eat it too. Sam Ruby pointed to WS-Transaction, to which Patrick Logan replied "I think we need a rethinking of databases, messages, and coordination." I'm sure that's true. Meanwhile, what to do?
Exactly the right question to ask. Here is the kernel of my response.
Something further. Consider passing documents using the following grammar in an XML namespace as a header to the exchanged document.
Peter Nolan writes about Metaphor Computer Systems from the listserv at datawarehousing.com. If you have information about this company or its products you can add that to a wiki page at MetaphorComputingSystems. Endorsements for simple systems like this should be an inspiration to developers. I'm not sure if Meta5 is all or a subset of the original product.
If I said M3 it was a typo...Metaphor Computer Systems (M4) was founded in the early 80s (might have been 1982) and released a product called Data Interpretation System (DIS) in 1984 if my memory serves correctly. Ralph Kimball was one of the co-founders.
I'm not sure there are many places where 'the history of Metaphor' is documented. I wish there was, it was quite a company. In 1997 I got the opportunity to personally say thanks to Ralph for his part in M4 because it changed the direction I was heading in.
In 1991 I had one of those 'ah-ha' moments when I saw DIS demonstrated to a customer of mine. As I watched it took about 5 minutes to realise that what I was seeing was the way end user computing was 'meant to be'. I was completely 'sold' on DIS as 'the way' data analysis/analytical applications would be built in the future. So was the customer. They bought the product.
In another one of those industry 'if-onlys'. If only IBM knew what they had it could have been the office desktop we all use today. (IBM bought Metaphor in 1988. So in 1988 IBM owned an 'office desktop' far superior to MS Office which would not exist for a few years yet. Instead of pushing DIS they pushed Office Vision, which died.)
The list of features in DIS was endless. The folks at M4 broke so much new ground. They had some 400+ customers by 1993 and their customers were household names.
I wish there were some demos or screen shots still around to explain to people what it could do.
The most important thing about DIS was that the IT staff were no longer required to develop analytical applications. The biggest benefit of this was that the business users did not need to 'externalise' or 'communicate' their requirements to anyone. Working on the DIS desktop they could try out their ideas and if they turned out to be good they could be 'packaged' into an analytical app. Yes, I am talking 1986 here. And, as per my previous comment, the 'intellectual capital' of the analyst to who created the application was captured with the application to a very significant extent because any other business analyst could read it. They barely needed any training to be able to read even a quite complex application.
One time an actuary customer of mine borrowed the manuals and from scratch, with no training and no help from anyone else, wrote a 30 year death experience analysis application in 3 weeks. It was that easy and that good to use DIS.
DIS was 'so cool' you didn't even need a keyboard. We used to put out keyboards on top of the screens and they would stay there for weeks on end. Try writing an analytical app today without a keyboard!!!!
Unfortunately, at the time IBM bought Metaphor the future of the world was PS/2, OS/2, MicroChannel, 8514A graphics adapters and Token Ring (at least according to IBM). When moving the software from proprietary to IBM hardware, IBM specified ONLY IBM hardware. There were a lot of other reasons why Metaphor experienced trouble operating inside IBM. (They were not the only ones, who remembers 'Rolm' telephones today?)
DIS was all 32 bit and it was the first fully 32 bit app that was released on OS/2, but OS/2 was 'doomed' and by the time windows 95 came out the opportunity to get DIS out into the marketplace had pretty much gone away and MS Office had a stranglehold on the windows 3.1 desktop.
Eventually the product was stabilised and then finally withdrawn from marketing. I think that was around 1997/8.
But there are many of us out there who look at what we could do then and what we can do today and wonder how it can be that there is so much that is still so hard to do now that was so easy then. Call me nostaligic!!! ;-)
From Jon Udell's item on J2EE/EJB...
You need your business logic available to multiple applications. What if those other applications aren't Java-based?
EJB is designed for CORBA clients.
The problems include, though, firewalls and interop. Unfortunately just as CORBA was rounding third and heading toward home on those issues as well as the price/performance issue, SOAP became a monkeywrench. Too bad really that CORBA could not have been the foundation of an "Enterprise SOAP" that evolved toward some of the flavor of XML messaging.
Also, CORBA 3.0 incorporates its own "Component Model", an improved EJB model that is language neutral. Maybe too little, too late.
I just stumbled upon these WS usage scenarios. I've not seen them before, and have read through only a couple of the discussion messages. (Someone probably pointed me to this list some time ago. I "stumble upon" things this way now and again.)
Apropos to my interests, the latest message in the discussion is "REST, uniformity and semantics". Actually REST shows up about every 10-20 messages. When I am awake tomorrow I'll wonder if the conversation ever goes anywhere, and what else is discussed.
From the thoughts of Monty Widenius (MySQL)... What I am looking forward to is diskless computers, a little similar to PDAs today, but with much better capacity. Hard disks will be used more as very large backup devices for things that you don't need regularly.
Gemstone's largest customers usually had their entire OODB running on very large systems with the entire database in RAM via copy-on-write shared pages.
Battery-backed RAM would be an incredible boost to performance and simplification to implementing ACID transactions. The other big win for large memory databases is to distinguish read-only data, where you could get rid of most semaphores as well. That's not done enough today.
For habit's sake we insist on running OLAP from OLTP systems designed 20-30 years ago. Newer designs can fit far more RO data in RAM too.
(This is a good time to be a computer scientist. Lots of change over the next five years.)
Dave Winer believes...
[U]nless I'm mistaken, [Wikis] don't have a concept of user identity...
Some do. Some don't. Sometimes it's an admin option.
One of the masters of simplicity in software, Graham Glass, writes...
another awesome bit of software technology is Linda, the tuple spaces architecture by David Gelernter. like Lisp, it provides a simple set of primitives with great expressive power. but i don't think that the Linda approach scales well. the remove() primitive requires some degree of locking that is not suited for distributed environments.
Voyager itself was a simple and awesome software technology. Congratulations to Graham for that as well as Glue and the upcoming Gaia. I'd be interested in his thoughts on Linda-like systems for the Internet.
The most significant adjustment in scaling Linda to the Internet that comes to my mind is to redefine blocking operations to be non-blocking. So 'in' (i.e. remove) would not block until a match is found. Maybe there would be a timeout, but the window would be fairly short and so may just be meaningless at Internet scale.
For these non-blocking polling operations, some rationale has to be assigned to an ethernet-like (but larger distance and time scale) backoff policy. Not unlike the RSS situation with polling. But the surprise with Ethernet is that the pipes continue to get faster and conflicts are not the problem people envisioned.
The alternative is to use a cloud-like mechanism for scalable trigger/notification. Eric Hanson has been designing these for relational databases at UFL.
Another aspect of this is the number of simultaneous users of a single tuple space. Scaling out a tuple space is fairly simple... create more spaces. Work has been done to replicate spaces, but in general I'd look for opportunities to simply partition scenarios and participants across distinct spaces. That must be the 80 percent or greater situation at least.
Reliability of messaging would have to take into account that the connection itself does not (and probably should not) implement guaranteed delivery of just one copy of the message. This is where some wisdom has to go into message design and higher-level domain-specific protocols. Less of an issue as the Internet evolves into its next incarnation, but this is the simplest approach for the next N years.
You can add your thoughts to the TupleSpaceScalability wiki page.
Sam Ruby writes, referring to the original Smalltalk refactoring browser...
[The] key question in my mind is not when such things converge in the laboratory, but when will such things converge in the mainstream?
I know it's a relatively small market, but Lisp and Smalltalk have been out of the lab for years. IBM's direction before Sun's introduction of Java was clearly aimed at Smalltalk and they were having a good deal of success with it.
There is no doubt that the Smalltalk refactoring browser was first. (Reading Martin Fowler's book will back the claim.)
But when the RB came out, it was aimed at, used, and ultimately made the de facto choice for commercial Smalltalk development.
A great site for Lisp programmers and other sorts. Not just Lisp-specific wisdom, from Chris Riesbeck's programming notes, via Kevin Rosenberg's blog, via Lemonodor.
While Smalltalk doesn't have the macro system Lisp has, generics are a non-issue in ST, as is boxing/unboxing. Ditto the "simplification" things. One could summarize this whole thing as adding complexity to a language to make up for the glaring flaws.
While Smalltalk doesn't have syntax macros like Lisp, Smalltalk *does* have simpler block syntax and keyword arguments.
The effect is that new keyword messages can take block closures, which essentially delay evaluation until the method behind the message decides to evaluate them, and the message send looks an awful lot like new syntax, very clean.
Many uses of macros in Lisp, frankly, are simply created to hide the appearance of the lambda keyword. Of course there are more "legitimate" uses of macros, but these are less common.
So Smalltalk and Lisp are fairly evenly weighted in the syntax category in my book.
Ruby is pretty close, too, but has some wierd quirks where they didn't get closures quite right and very bad silent mistakes can be made. Python is further back in this category.
A strongly typed language merely creates an environment so that the type-checker can automatically check the type constraints for you at the cost of restricting some genuinely useful things you might want to do.
One thing you want to do that is easier with dynamically type checking is testing. Only time spent developing significant systems in dynamic languages will bear this out. Illustrations don't capture the reality.
People see that static types can catch things early. They don't see that those things aren't important since they get caught early in dynamic tests anyway. Yes, you have to write good tests. Can anyone tell me when that's not the case?
Neither is it apparent on paper that refactoring large systems, or just experimenting with large systems, goes much more quickly when you have to change less code to get a small test to run. You trust that the complete set of tests will catch everything else when the experiment is ready to be integrated back into a complete working system.
But during spike experiments you want to ignore the irrelevent, create mock objects, even entire "mock databases", and play what if on isolated bits of code, even within large currently running systems. Doesn't happen easily in Java-like languages. Compilers that have no clue of what you really care about in the moment. They make you dot that 'i' over there and cross this 't' over here before you can even get to the bits of interest.
However, I think that it makes the student's choice crystal clear: become a computer scientist, not just a programmer, because if the IT locomotive does decide next year that some new thing is better, you'd better be as adaptable or you'll get left in the dust.
You want to learn computer science, or anything really, from people with advice like this. You may end up even contributing to the next new thing.
Stefan Tilkov writes about me...
Patrick Logan has a blog. So what?
Exactly.
Oh, he continues...
Apart from some very interesting posts, I somehow recall the name, and have positive assocations with it ... digging ... I found a patricklogan@gemstone.com
Well, thanks. Gemstone went through an upheaval at the tail end of the dot com fiasco. I left before the implosion...
"In less than a year, a 20-year-old [sic] company, with revenues and profits, (though not brilliant, it was a going concern), has been destroyed by another company that is itself only a few years old. That is sad."
So I am wondering how much should be put into specifications and what should be left for emergence?
I have had bad experiences participating in the market-driven rush to unproven and premature standardization. So I lean toward the minimal necessary and look for patterns and principles to emerge from experience.
Giulio Piancastelli is very kind and also on the money speculating...
I quoted Patrick's words because I think they are the most original and interesting from the whole bunch. I see Prolog and tuple centers in them, and I am glad for what I see.
Nice connection and thanks for the references to these projects. Indeed I think the future is bright for logic/constraint languages and coordination through blackboard/tuplespace architectures.
There is nothing like a controversial statement to draw attention to an issue, or at least traffic to a little-known blog.
Apparently, Patrick took a peek at WS-Transaction, didn't get any further than the author list and decided it wasn't any good. I agree that two phase commit is traditional... I hold out more hope for compensating transactions via asynchronous messages.
I did read further than the list of authors. But nothing like a controversial statement to get people interested in a topic.
I do think the compensating approach is better than the atomic approach at the distributed business level of "transaction". But I am not sure either should be a part of the connection architecture. Compensation "meta-data" if you will should be a part of the documents exchanged among business partners, no matter how those documents are exchanged.
A distributed system across trust boundaries is where I believe we are collectively heading. The internet shows us the beginnings of what is possible... for the subset of things that are generally always online and publically accessible. Expanding this to mobile and access controlled is the next big thing.
I love the NeuroTransmitters story. But Sean McGrath illustrates the problems that emerge when you overload your connection architecture over time.
The network is not the computer. My computer is over here and yours is over there. All we need is a simple way to exchange documents.
The documents are the messages. The computers are the cells. (Fortresses in Roger Session's metaphor.)
The connections should be as simple as possible and get out of the way.
Sam Ruby points to WS-Transaction. But look at the list of authors. The problem is IBM and Microsoft have a lot to preserve by maintaining more or less traditional databases and transaction protocols.
Jon Udell wonders about the LAMP vs. J2EE/dotNET inflection point. But LAMP is made in the same image. This architecture goes back thirty years or more.
I've written an essay on what I think the next database architectures should look like. If you read through my blogs you'll know it has something to do with tuple spaces and star schemas. But Jon goes on to ask, "How do you preserve the fluidity that the agile enterprise requires?" There is a little bit more to say, since enterprises are not nearly as agile as they need to be.
WS-Transaction is intended to preserve the status quo rather than improve agility. I'll publish more on this in the near future.
Lambda the Ultimate has this piece on a Scheme program that analyzes Excel spreadsheets.
What is most notable about this? The essence of this system represents the future of software development and the need for more dynamic analysis than "compilers" traditionally give.
Note:
This represents the convergence of dynamic model checking and infered static type checking. The future is getting more dynamic and so "type checkers" will become more sophisticated (and background) theorem provers than they are now.
Additional features will include symbolic execution including concurrency model checking and semi-symbolic partial evaluation.
Over the last 10-15 years electronics design has taken more of a software design flavor. Over the next 10-15 years software design will take on more of a traditional hardware simulation and model checking flavor.
A quote from FDR via Mark Johnson's weblog...
For out of this modern civilization economic royalists carved new dynasties. New kingdoms were built upon concentration of control over material things.
From the Vistorian Age to the present it could be argued that dynasties were necessary to build the steel mills, shipping, the railroads, the telecommunications systems, and so on. Perhaps the benefits for society outweigh the cost of establishing the industrial dynasties.
But now we're in an age where extreme decentralization is at hand. It will be more of a challenge to get dynastical forces out of the way of progress than it will be to actually establish a decentralized age itself. Are dynasties necessary for societies to decentralize in the way they were necessary to centralize in the first place? I don't think so.
Dylan told the senators and congressmen not to stand in the doorways or block up the halls. The times are changing. Will the dynasties allow it? Will the people know enough to demand it?
This from Matt Gerrans ties in with the posts on structure and interpretation of computer programs I wrote about this week (and almost every week it seems).
OK. Another blogger to follow.
BTW when I was writing electronic design automation software way back when Matt's approach was the popular (and correct) technique. Scheme was the scripting language of choice for DA tools.
Jon Udell points out Bob Martin, Ward, and Guido van Rossum have entered the blog world. I'll pay particular attention to Ward's, he has a singular style and an uncommonly sensible approach to software.
Moreover two notable people in distributed systems have blogs as well: Ken Arnold and Jim Waldo.
Both have been instrumental with JINI and JavaSpaces, the two best satellites in the Java universe.
The blogsphere has achieved another level of benefit for software developers with the addition of this new handful. I'll have to check out the others in their sidebars.
Objective-C has advantages of simplicity and optional dynamic types, neither of which is an attribute of C++. A lot of people don't realize that Objective-C is part of the GCC. So the compiler and library are available for Linux, Windows, and other Unix in addition to Mac OS X.
The language also has a reflection interface in pure C, so integrating scripting languages into Objective-C applications is a snap compared to C++ or even C. You don't have to generate stubs per API. Just call the reflection API dynamically.
First, I am thrilled to have come across Bob Martin's weblog. His first book is still required reading as far as I am concerned, it is not a C++ book, it is a *design* book. His second is right up there as well, having won a 2002 Jolt award. He's co-authored, edited, etc. many others too.
Second, this weblog topic asks, are dynamic languages replacing static languages? He goes on to confirm what dynamic language programmers have been confirming to themselves for forty years: dynamic languages and their iterative, incremental approach to design obviates the need for static type checking.
The next interesting question addresses the future of type systems and will a more formal yet expressive static type system be more productive than either dynamic languages or the more primitive type systems of Java and C#?
My take on it is this having done a lot of dynamic language programming and a little modern functional language programming...
There is a convergence out there, maybe ten years out on the road to The Hundred Year Language, where better (less intrusive, more expressive) formal type systems and dynamic programming meet. After all, incrementally building a dynamic system of objects is not unlike incrementally building an expressive system of typed combinators!
Essentially type systems are theorem provers. The more expressive they become, the close they are to the problem domain, just as the more expressive dynamic languages allow us to speak more about the problem domain than the "compiling domain". In the future I expect to be able to dynamically build semi-formal systems and then have that system tell me things, i.e. prove theorems about itself. From there I can make adjustments not just through more tests and code, but through direct manipulation of the "theorems" I have stumbled upon.
Talk about refactoring! Organizations with interacting systems will be able to refactor the "theorems" of how they do business. It's one thing to share tests and dynamically update them, but it's another thing to share theorems and dynamically update those.
Phil Windley now has a great quote from Paul Graham's "The Hundred Year Language"... (The permalink to the message is broken for April 30 at this point.)
[Paul] Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
[Phil] The phrase accrete programs as a series of patches is so deliciously visual that it makes me smile.
So many juicy bits in Paul's keynote. I guess that's what makes a good keynote.
Since Phil will be sending some traffic my way, this is a chance to redirect you to a piece from OOPSLA 2002 related to the above quote...
Noble and Biddle's Notes on Postmodern Programming.
Paul Graham, in his by now famous "The Hundred Year Language" keynote at Pycon 2003, questions the future of parallel computing. I am a little more optimistic than he is, see if you agree...
I expect that, as with the stupendous speed of the underlying hardware, parallelism will be something that is available if you ask for it explicitly, but ordinarily not used.
In a hundred years I expect languages to express opportunities for parallelism better than they do today. I expect language compilers to plan for parallelism more than programmers using those languages.
I would use pH as an example of where this could go more maintstream.
This implies that the kind of parallelism we have in a hundred years will not, except in special applications, be massive parallelism. I expect for ordinary programmers it will be more like being able to fork off processes that all end up running in parallel.
Except in special kinds of applications, parallelism won't pervade the programs that are written in a hundred years. It would be premature optimization if it did.
On the contrary I think we'll be accustomed to parallel and concurrent computing through the use of simpler mechanisms that we have today, by and large.
So there will be much more parallel computing than we have today, but it will be simpler and mostly implicit. I think Paul Graham's OLTP/Workflow orientation is blinding him to the amount of analysis that takes place in the business world, and how much more can be automated in the next hundred years.
This video taped lecture demonstrates the benefits of computer science for non-majors, just people who want to improve their ability to think.
But, as I have pointed out: Computer Science is not a science, and its ultimate significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. I will defend this viewpoint with examples and demonstrations. -Gerald Sussman
If you are interested in computing and live near Salt Lake or Provo then Phil Windley will teach you how to think in this course that by all appearances is excellent.
I was fortunate to have a similar course with an emphasis on interpretation. Too many comparative courses are presented as a survey of disparate landscapes as opposed to a grounding in the fundamentals.
If you not in Utah, then look for similar courses near you. Indiana, MIT, Northeastern, Brown, and many others will have them.
If you are too far away then there are several on-line resources, e.g. on-line texts, Ars Digita University and some video taped courses like these from Berkeley that include Structure and Interpretation of Computer Programs.
