Beyond Java: A little Dabble?

From the article "Moving Past Java" an interview with the author of "Beyond Java"...

Bruce Tate: Keep in mind that I'm suggesting Java will be dead like COBOL, not dead like Elvis...

Madhu Siddalingaiah:I agree with you that innovations are beginning to appear outside of Java.

Don't worry. Madhu will kind of correct himself in just a few paragraphs...

Madhu Siddalingaiah: Ruby is a dynamic language, but there are many others, such as LISP and Smalltalk. Are there lessons we can learn from the one of oldest and one of the most innovative of languages?

Bruce Tate: Sure. Ruby is actually a nice fusion of Smalltalk and Lisp. I think the biggest lesson is that you need a catalyst. Ruby has Rails. None of the other dynamic languages got a catalyst.

Maybe a little Dabble do ya as a catalyst for Smalltalk, building on Seaside.

Then Bruce nails the essence of the problem...

Bruce Tate: Java just doesn't express data well. Other languages make it easy to put data into a hash map. Not so with Java, so we just drop down into XML.

They wrap it up like this...

Madhu Siddalingaiah: Do other leaders in the open source community share your opinions about Java?

Bruce Tate: You can see people ramping up on Ruby on Rails in a big way. David Geary, JSF expert group member, and one of the greatest Java authors, is writing a Ruby on Rails book with me. James Duncan Davidson, inventor of Tomcat and Ant, is now working with Rails. There are many, many others.

Beyond Java

From the Java community, looking beyond Java. High praise for so called dynamic languages and how they have resulted in more productivity with Seaside (Smalltalk) and Rails (Ruby), etc.

Oh Dear

Questions about the Video iPod...

Uncertainty surrounding the level of demand for the product, the sources for compelling content, and its possible use to view pornography seems to leave more question marks than exclamation points...

Brian Milburn, president of Solid Oak Software in Santa Barbara, Calif., which sells software that filters out objectionable content on the Internet, says he's certain video iPods will quickly become a favorite tool to download and view pornography.

By Christmas, he predicts, the ability to download pornography "will be one of the main attractions for getting a video iPod.... These kind of technological advances can have a lot of unintended consequences...

Yes, we've certainly done the job of keeping porn off of computers. Now on to the iPod I guess. Since when has video technology *not* been driven by the porn industry? (I think there may be a lesson, or two, there.)

Of course I live in a fairly relaxed climate for such things. Here's a description of my fair city (link may not be safe for work)...

With more strip clubs per capita than anywhere else in the United States, Portland, Oregon had become known as a hot bed for erotic dancing. Add to that an extremely accepting public, a growing sex worker movement and a liberal constitution that protects the right to dance nude, and you will find a city where an oft-marginalized subculture has gained a degree of acceptance almost unknown anywhere else in North America.

Termite

No, I don't know what's up with Termite. I like the idea of Scheme being an UNCOL.

But what I really want is an Erlang environment up and running for me. So I decided not to wait for Termite to mature or to rewrite Termite using Gambit's new mailbox mechanism.

We are now in the postmodern, dare I say, Web 2.0, era. I'm back to using Erlang after several years and loving it. It has so much good stuff packed in, from Mnesia to simple distibuted messages. It's not my favorite sequential language, but it seems like my favorite concurrent language.

WS-Interop-In-The-Small

I left a comment on James Robertson's blog re: his item on CORBA and WS. I agree with his point about port 80. (Although CORBA was addressing that just as the SOAP community accelerated.)

Still, as far as port 80 and people working hard on the basic interop capabilities go... the result I think is still essentially that SOAP and WS-* interop is about at the level XML-RPC was five years ago. Is it really much beyond that today?

The data passed via SOAP is arguably more expressive, or at least more widely recognizable as XML, than the XML-RPC syntax. Once you get off of port 80 though and stop using HTTP as a transport, then WS-* seems to quickly devolve into the same old proprietary vendor race to lock in customers.

JBI is an attempt to avoid this but has little momentum that I know of. The ESB is still promoted as the key to deep success of integration within the enterprise. We had this five years ago in proprietary form. Today we are no further from the vendor lock-in that it takes to move in this direction. Outside the enterprise there's still no advantage over REST in sight.

This is still interop-in-the-small... I think even CORBA was beyond this point five years ago.

The Cathedral is the Bizarre (Too)

Jon Udell points out that the cathedral and the bazaar have much in common, perhaps most of all would be their respective ongoing evolution. They are equally bizarre.

To the point about Sed and Awk... I am not sure the cathedral or today's bazaar is more coherent. I am not sure they need to be. We've been postmodern for some time and we should not expect that to change. Embracing the chaos is almost the goal itself.

Innovation implies chaos. Sometimes the cathedral can be too limiting for innovation, or at least timely innovation. Look at the back and forth on schedules and dependencies among the new work coming out of Microsoft's dotnet and longhorn team. When was WinFS avalable again? What platforms? How does that line up with the LINQ query capability again?

In the bazaar there is much less control over the chaos. I'm fine with that because generally people find or make ways to get from one place to another within the bazaar. Here's some postmodern glue I have been working with lately...

I wanted to use Erlang with the Berekeley XML database as well as with the Clips rules engine. After a little consideration of my options for integration, for my purposes the easy answer was Python. Running SWIG for Python on Erlang's C-based erl_interface creates the glue that gets me into Python from Erlang (with all the desired Erlang node management capabilities). From there Python already has Berkeley XML DB integration and the PyClips interface to Clips. Plus I can send Python code from Erlang over the distributed process connection and have it executed dynamically in those Python "agents". On the front end, Erlang sends JavaScript, XML, JSON, and CSS to the browser. These combinations make Sed, Awk, and various shells look downright homogenous.

Bizarre combinations gathered from the bazaar. But when you begin to piece together all the different MSFT components you get something equally as bizarre.

Innovation or Standard: Choose One

On BPEL standardization...

the market is fairly immature as to what is the right way to take something like that. What it also shows then is you're getting a lot of innovation in the standards body. Innovations in standards bodies typically aren't good things.

Comments on Processes, Etc.

Le Roux Bodenstein writes in email...

Some comments on some of your recent posts: You were talking a lot about scaling to more processors, app servers becoming the new operating systems, etc.

Aren't app servers just big processes that manage large amounts of threads? Don't multiple processes scale more easily because of "share nothing"? What's wrong with operating systems? They are basically (among a few other things) very efficient process schedulers. (modern unixes, at least)

"Shared nothing" is important. If the multiplexor does not enforce shared nothing then convention should. The new multiplexor (e.g. the web/app server) is lighterweight than the older OS multiplexor. Shared nothing lightweight processes are the best of both worlds.

I think if anything we should work on making inter-process communication easier. Processes should be tied closer into languages and inter-process communication should be abstracted. Even more than some newer languages did with threads.

I agree. But we need to lose the distinction between local and remote processes. e.g. Erlang processes us the same simple communication abstraction whether they are co-located or remote. So do HTTP processes of course, and XMPP, and... Perhaps the OS is the last bastion of the local/remote distinction? (The now defunct Apollo Domain OS being one of the rare exceptions.)

I think "lightweight processes and threads" will lose popularity. Multiple cores and processors effectively make the "heavy-weight overhead of processes" a mute point. There's a lot less context switching when things run on their own processors and once a process is started (which is as far as I know quite expensive compared to starting a thread, but I am not an expert) it can just keep running until it is needed.

I agree heavyweight processes will perform better, but lightweight processes will perform that much better. The OS process approach can and I am sure will be improved but making improvements there is probably a longer road than taking the Erlang approach in a specific web/app server or language runtime implementation.

Anyway... my argument is I don't think app servers will help much on operating systems with decent kernels. In fact - they will just be in the way. Or an extra layer. Or what little use they have can be added to the os.

I think this is a fine way to approach the problem but as I said I think it is a longer road. Hopefully the OS designers will move in this direction, having taken some best practices from the web/app server and language runtime designers. (For that matter hopefully the web/app server and language runtime designers will take some best practices from their peers.)

I don't think we need new programming languages either. I think Python, Ruby, etc. can probably just be "fixed" to make multiple-process development a lot easier...

We continue to be in agreement.

The New Ribbon

I have not tried the new MSFT Office Ribbon, so I will withhold judgement for now. Others are noting the amount of real estate the ribbon requires.

The only thing I want to point out here is we have gone full circle from ribbons to menus and back. The first GUI applications I developed were CAD tools. Back in the day, those tools were expensive and ran on expensive hardware. One had to go to a special (usually dimly lit) room to use the CAD systems.

Those systems had very expensive, and large, screens. The GUI was essentially an area to present as much of the schematic as possible surrounded by, yes, ribbons. We developers had ongoing discussions to determine how to minimize the ribbon space and maximize the capabilities offered in the ribbons. CAD designers did not want to waste time clicking through all kinds of icons to get to the right function.

Soon after the Mac caught on, then X and Motif. Menus and dialog boxes became the thing. Ask me sometime how this specific transition almost brought down one of the top 3 CAD vendors.

Language Wars

What do language wars mean in the age of services and post-modern software development?

YURLs

Tyler Close has been contributing some useful exposition in a series of messages on capability-based URLs to implement authority in the REST Yahoo group.

More on the Future of Multiprocessing

ACM Queue has good explanations of where hardware is going and how to scale software into the multiprocessing era.

The introduction of CMP systems represents a significant opportunity to scale systems in a new dimension. The most significant impact of CMP systems is that the degree of scaling is being increased by an order of magnitude: what was a low-end one- to two-processor entry-level system should now be viewed as a 16- to 32-way system, and soon even midrange systems will be scaling to several hundred ways.

Software Education

Phil Windley writes about software education...

I've determined that I'm no longer convinced that software engineering, at least as it's commonly discussed and taught, is what I want to prepare students to do. I try to focus them on being innovative, entrepreneurial, and working with dynamic languages on networked applications.

The New Application Architecture

Phil Windley looks at new hardware architectures and their forces on future software systems...

Application servers (like jBoss or Weblogic) support a development model in which programmers develop threadless code and the app server manages the threads. That simplifies the point too much, perhaps, but I think having that much parallel processing power on a single chip might make app servers much more important for developing applications. There are continuing debates about whether app servers add more complexity than their worth, but that might be because we haven't met many problems large enough to require them–yet. In the early 60's programmers scoffed at the idea of operating systems as being "needlessly complex;" that idea is ludicrous today.

I think application servers are the new operating system. (Ten years ago they were the new transaction monitor, but now we know we all need one. We all need more than one.) We need to be able to write smaller "applications" and have them interact more easily. Look at the advice for programming web applications, web services, EJB's, as well as applications in Erlang. They are all very similar. Erlang applications tend to be more simple than the rest because the available framework takes this point to the extreme.

Those other systems are built by and large on heavy-weight process technology. Maybe Erlang is the new Lisp. We need a Lisp for lighter-weight process interaction, as Jon Udell pointed out.

I should point out that I equate "web server" and "app server". That there is a distinction is an artifact rather than an inherent reason. An application server is inherently a "process monitor" with various drivers. HTTP drivers, SMTP drivers, XMPP drivers, etc. I don't think the new "superplatform" belongs to Microsoft, IBM, or BEA. The superplatform is one based on the standard application protocols. The best of these platforms will combine support for these application protocols (and more... IMAP? WebDAV?) and abstract the complexity. Most of us should be writing sequential code, rule-based code, constraint-based declarative code, etc. But we'll have to plug into these protocols.

Phil continues...

It's tough to see how you'll use that much parallelism on the desktop. I just counted the number of processes running on my Powerbook: 76... there are things we've hardly been able to imagine.

This is the result of the languages we have been using to think with. As Phil points out, these new hardware architectures will give us more reasons to think differently.

CORBA Redux

Roger Sessions is a bit of a character. Witness his back-and-forth with Terry Coatta in ACM Queue around CORBA and Web Services. Sessions continues to point out that CORBA worked when CORBA was on both ends of the wire. Well, what else would you expect? Does HTTP work when HTTP is not on both ends? For some reason Sessions seems to believe that WS-* does not require WS-* on both ends.

For years now Sessions has promoted DCOM and now he promotes WS-*. A continuing theme of these promotions is that CORBA has failed. Certainly DCOM failed worse than CORBA. Moreover, as Coatta points out...

It looks to me like CORBA is more of a success than Web services.

The CORBA community learned many lessons and would have been even more of a success had that organization incorporated the web sooner and more naturally. WS-* usurped CORBA on the premise that the result would be simpler and better, yet years later both claims remain suspect.

Later in the exchange Sessions says something incredible. Upon admitting the WS-* specs are *more* complex than CORBA's, Sessions suggests that is OK...

I agree that the Web services standards are harder to understand than most of the CORBA specifications, but there’s one fundamental difference between these specifications and the CORBA ones. The CORBA specifications had to be understood by developers. The Web services standards don’t. Nobody needs to understand the Web services standards except for Microsoft and IBM because these standards are about how Microsoft and IBM are going to talk together, not about how the developer is going to do anything... These standards have no relevance to Joe or Jane Developer, none whatsoever.

This is ironic since a few minutes previously Sessions complained that these vendors are in danger of making WS-* too transparent...

In some sense, the transparent ability to make something a Web service is not really a good thing, because making an effective Web service requires a much more in-depth understanding of what it means to be a Web service.

Coatta catches this apparent contradiction...

It sounds like what you’re saying is that the tools that automatically supply Web services interfaces are, in fact, absolutely necessary because they’re that insulation between the developers and the underlying protocols. At the same time, they’re the downfall that’s making it possible to generate poorly architected systems. Two-edged sword?

Sessions has little to defend himself with other than to suggest that although these tools don't prevent bad architectures, just think how bad the architectures would be without those tools.

I'd give Coatta the victory in this debate. Too much confusion from Sessions who has not made up his mind whether tools, protocols, or APIs are good or bad...

The big difference between Web services and CORBA is that the Web services people said right from the beginning: there is no API.

So there is no API, because those are bad. But the protocols are damn near impossible to understand. But that is good, because we only need two vendors and they can provide tools. Well, as long as they don't provide APIs, 'cause that would be bad.

The only thing more confusing than the mess of WS-* specs is the explanation Sessions is trying to proffer.

Spiral Staircase: Going Up or Down?

Jon Udell asks a great question...

In the realm of service-oriented design and business-process modeling, what are the modern counterparts to Lisp and Smalltalk?

First, who says Lisp and Smalltalk are not "modern"?

Second, I don't know the answer. Neither Lisp nor Smalltalk offer more than any other tools for these purposes. I don't think we have much in these spaces yet.

An argument could be made that for service-oriented design the counterpart seems to be HTTP. Whether or not HTTP is the best we can do is moot. Lisp and Smalltalk were allowed to evolve in elite laboratories for a decade or more before widespread adoption. HTTP is simple with demonstrated success, but I'm not sure a successor will emerge from an MIT or a PARC anytime soon.

As for process modeling... we are in worse shape. I developed electronic design and manufacturing software (e-CAD, CAM) for many years, 1983-1993. This work included developing schematic editors as well as software that consumed schematic data. In those days there were few standards for this kind of software, interchange formats, or protocols.

I see several parallels to todays BPM software. Standards like BPEL are a start, but there is a long way to go on the front and back ends for these systems.

Back to services... I think we have a long way to go here as well. Most services I am aware of (whether they are REST or WS-*) are built on languages that emphasize the "inward view" of the system (e.g. the arrangement of code and data within the process) rather than the "outward view" (e.g. the service interface and contract). Sure there are "declarative metadata" schemes in various languages for denoting some function should be a web service, etc. But these schemes are bolted on to previous generation languages. Accessing semi-formal data from multiple sources and "mashing" these together appear to be another capability in demand.

What other capabilities should such a language provide? What about features for security? Availability? Distribution?

Comments are gone

I have republished the blog without comments. There will be no more comments until I can prevent the spam attacks. I have been all but unaffected until now. The losers lose for us all.

Feel free to send email directly to me in lieu of comments on any topic.

Threads, Processes (and Shared Memory)

James Robertson quotes from several interesting pieces on threads, processes, and programming models. I am squarely in the multi-process camp too. I remember my absolute shock about a decade ago when I learned Java (at that time aimed at being a simple web programming language) had a shared-memory with monitors concurrency model.

The key phrase there is "shared-memory". Threads in and of themselves are not the problem. The shared-memory model is the real problem.

With a shared-nothing model then threads take on much more of a "process" feel. Languages like Erlang and Termite implement lightweight shared-nothing processes above the level of the OS. The benefits of sharing lightweight processes within a single address space provide a "best of both worlds" model. Sharing can take place under the abstraction of the language... the runtime benefits of sharing but the developer-time benefits of isolation. Whether an associated process is local, or in another OS process, or on another node, is irrelevant in many respects. Performance, reliability, etc. are still concerns so the distribution problem is not completely abstracted away.

Smalltalk Leading the Way

David Buck writes about an enticing upcoming meeting of the Ottawa Smalltalk User Group...

Smalltalk and Smalltalk developers have led the way to the modern techniques and practices that [David] teaches in Simberon's courses... even now, the future of software development is being led by Smalltalk whether or not the rest of the world cares to notice.

Happy Goldfish in a Bowl

Having dabbled on the edge of AI for a number of years, I enjoy the technology as well as the philosophy that surrounds the subject. Jon Udell writes of the so-called Singularity...

That's us: just goldfish to the post-human super-intelligences... True machine intelligence was what the advocates of strong AI wanted to hear about, not the amplification of human intelligence by networked computing. The problem, of course, is that we've always lacked the theoretical foundation on which to build machine intelligence. Ray Kurzweil thinks that doesn't matter, because in a decade or two we'll be able to scan brain activity with sufficient fidelity to port it by sheer brute force, without explicitly modeling the algorithms.

Now's time for this goldfish (me) to refresh himself with a healthy dose of Terry Winograd and Fernando Flores. I don't consider myself religious in the least. However I think that neither "intelligence" nor "emotions" are in any way mechanical (i.e. transferable to a machine). I do think they are *biological abstractions*. They are the names we give to our interpretation of biological (and so, chemical, and so, physical) processes.

Back to Jon on the current understanding of human vision...

We are, however, starting to sort out the higher-level architecture of these cortical columns. And it's fascinating. At each layer, signals propagate up the stack, but there's also a return path for feedback. Focusing on the structure that's connected directly to the 14x14 retinal patch, Olshausen pointed out that the amount of data fed to that structure by the retina, and passed up the column to the next layer, is dwarfed by the amount of feedback coming down from that next layer. In other words, your primary visual processor is receiving the vast majority of its input from the brain, not from the world.

We can manipulate biological and psychological processes. We can mimic them mechacinally to increasing degrees. But we cannot "make them" out of parts and we cannot "tansfer" them to such a machine. What would that mean? The simulation of the hurricane is not and never will be the hurricane even if the simulation actually destroys the city. Something destroys the city, but it is not a hurricane.

A machine that has some representation of my "brain" may continue to develop a further simulation of what my brain would be like had it undergone similar stimula. But in no way is that machine now "my brain" and in no way does that machine "feel" things in the way my "real brain" feels things. Those feelings are interpretations of abstractions of biological processes. The machine is merely a simulation of such things. If you care about me and then observe further simulations of such a machine you may further interpret your observations to be "happy" or "sad" and you may even interpret that machine to be "happy" or "sad". But that machine is in fact not happy or sad in any biological or psychological sense.

Let's face it, even my dog "loves" me because I feed it, and when it comes down to it my kids do too. We are abstract interpreters of biological processes. One interpretation of that may be "loneliness" but so? Here is where I note that my dog gets as excited to go out and pee as it does to see me come home from a week on the road. Fortunately my kids have a finer scale of excitement.

Back to Jon for more about augmentation rather than "strong" AI...

I had the rare privilege of meeting Doug Engelbart. I'd listened to his talk at the 2004 version of this conference, by way of ITConversations.com, and was deeply inspired by it. I knew he'd invented the mouse, and had helped bring GUIs and hypertext into the world, but I didn't fully appreciate the vision behind all that: networked collaboration as our first, last, and perhaps only line of defense against the perils that threaten our survival. While we're waiting around for the singularity, learning how to collaborate at planetary scale -- as Doug Engelbart saw long ago, and as I believe we are now starting to get the hang of -- seems like a really good idea.

Seems like a really good idea. "Strong" AI is fascinating, but "augmentation" is useful.