Coming out of the woodwork

Another prediction...

10. Microsoft will increasingly play the patent card when competing with Linux. Although company officials have downplayed the extent to which Microsoft is threatening customers and partners with the risk of patent-infringement lawsuits if they go with Linux, we hear this is an increasingly key piece of Microsoft's competitive strategy. With Microsoft vowing to file 3,000 patent applications during fiscal 2005 alone, we expect the company to rattle the patent sabers even more in 2005.

Some background...

Microsoft has been slowly but surely deemphasizing its Passport digital-identity service for more than a year. But Passport increasingly is being pigeon-holed as a service for Microsoft properties only.

Another definition of the term "long tail"?

More Predictions

From Bill de hOra, tongue in cheek he says. We'll see...

java.util.concurrent will be a talking point and will produce a rash of articles and guidance as developers weep like children in the face of Doug Lea's 3rd edition of CPIJ.

Doug Lea's collection and concurrent packages have been one of my favorite features of Java for years. This would be a great prediction to come true.

Microsoft will try to hire Doug Lea.

I'd be surprised if this has not happened already. Does dotnet have anything like his concurrent package?

Everyone gets bored talking about AOP.

On the other hand, what if everyone realizes AOP is a nightmare from another era and moves to more simpler and expressive programming languages?

[Rich Internet Application] hacking hits the offline/online sweet spot as developers get fed up waiting for browsers, virtual machines and UI toolkits to evolve in response to Web Sites Which Are APIs... 2005 witnesses a revolution in how most developers are prepared to use obscure languages in production scenarios... The terms process-oriented, crash-first, concurrent message passing, and little language enter mainstream developer lingo. By the summer everyone gets closures and they replace IDE support as the popular distinguishing factor between languages. People start fooling with Erlang after they realise EJabberd is written in it and Herb Sutter's Fear and Loathing in Concurrency article scares the beejesus out of everyone.

Great predictions.

IM becomes a viable alternative to the heavier Grid and P2P technologies for integrators and data crunchers working at federation and Internet scales, but will initially be frowned on as a simplistic and inadequate for 'real work' - the debate will initially look like a rerun of WS-* v HTTP/XML

Nice. No tongue in cheek needed.

Finally...

Patrick Logan and Ehud Lamm become superstars.

Hmm. Tongue must be partially in cheek. Ehud certainly deserves credit and publicity for Lambda.

On the other hand, I don't look good in Spandex and I don't have much of a stage presence.

Recovery

Really just one hope comes to mind at the top of my list for 2005. That's a recovery to some new definition of peace and normalcy for the people affected by the tsunamis.

There are two local (to me) really great agencies involved in the recovery. They are Northwest Medical Teams and Mercy Corps, both here in Portland.

There are many agencies ready to take donations and hard at work on the recovery. If you're unsure of which agencies would be effective, these two have a long reputation of doing good work efficiently.

Beyond that effort, the rest of my list would be filled with hopes for more freedom, kindness, understanding, and generosity. Less war. Less terrorism. Less fear.

More health.

How's the Blogosphere?

A creative lyrical satire on blogging. I was concerned about the dialog portion going off on blogging in general as "saying nothing". I find "traditional" channels saying nothing lately. I'd rather page through a large number of individual(istic) blogs to keep up with my interests than a limited number of sanctioned channels.

David writes in the comments to this post...

It's not so much that I think blogging in general says nothing -- I read lots of blogs and gain a lot from them. The "random nothingness" stuff is a takeoff on the large number of blogs I've come across (mostly in the Java developer space) that have... disingenuously self-deprecating descriptions for people who certainly do have something to say...

So go for it, bloggers.

A (More?) Positive Outlook?

I consider myself kind of a critic. I think we need a lot more criticism in the industry as well as in society as a whole. I try to be constructive even though I miss that mark and have no editor to question me before I hit "Publish Post".

Given the New Year around the bend (as I write this, I'm about 11 hours away from 2005), I am going to post something positive about the mainstream of the industry. Shock!

Here's to a 2005 where we can learn more about Microsoft's Bigtop...

Bigtop consists of three components, all written in C#, according developers who said they were briefed by Microsoft. These are:

Highwire

Highwire is a technology designed to automate the development of highly parallel applications that distribute work over distributed resources, the aforementioned sources said. Highwire is a programming language/model that will aim to make the testing and compiling of such parallel programs much simpler and more reliable.

Bigparts

Bigparts is code designed to turn inexpensive PC devices into special-purpose servers, according to the sources. Bigparts will enable real-time, device-specific software to be moved off a PC, and instead be managed centrally via some Web-services-like model.

Bigwin

According to sources close to Microsoft, Bigwin sounds like the ultimate manifestation of Microsoft's "software as a service" mantra. In a Bigwin world, applications are just collections of OS services that adhere to certain "behavioral contracts." These OS services can be provided directly by the core OS or even obtained from libraries outside of the core OS.

These are terrific goals. Market forces can detract from goals like this. Perhaps better markets can emerge from staying on track; the benefits could be huge.

More Agility in 2005?

Why didn't they teach us in math that integers can "overflow"...

The most serious of the three vulnerabilities involves the Windows LoadImage API Function.

That bug was described as an integer overflow that could be exploited via browsers or e-mail client software. Users who open an HTML message or Web page bearing the image could face security risks.

Here's to a New Year where more programmers use agile languages where integers behave more like you learned in math class.

*Experience* Music Project

This week I went to the Experience Music Project for the first time. Our family joined for the year because (1) it was about the same cost as general admission considering the Bob Dylan T-Shirt they throw in with the membership; and (2) we are in Seattle a lot and (try to, some of us) play various instruments.

One thing I should not is that I am not a fan of the exterior of the building (or of Frank Gehry's architecture generally), but the interior of the building seems to work pretty well for moving a lot of people through a lot of content in a small amount of square footage. Some of the doorways and passages were inexplicably narrow.

The content is what really matters. I'd like to see a wider emphasis than rock and roll, but if you look around a bit you'll find broader content. I'd like to get back up there for Jazz in January.

The best thing about the "museum" is the experiential opportunities. The sound lab is a great place to learn how to make music on various instruments or just to play around. A number of sound-proof booths and rooms have keyboards, guitars, drums, sound equipment, etc. with guided software for absolute beginners or just for free form fun.

Dang if I wasn't embarrassed as a software developer though. In the few hours I was in the sound lab my family and I experienced a handful of frozen computers and handheld devices. More than once "rebooting the computer" was the recovery method.

These are embedded systems and when they break down they spoil the experience even more than a typicalhome computer problem. There's no reason I can see these systems could not fail fast and recover quickly without falling back to the main screen most of the time.

We need to make great new strides in this as programmers beginning in 2005.

Languages and Data Integration

Years of endless debates about static type annotations regurgitating the same information over again have led me to shy awayfrom them in recent years. I've done pretty well, yet here I am in the gravity field of another one. I'm not sure how long this will last but for this day, I am somewhat interested in continuing.

PJE writes in a comment...

Um, just because a given use case can be accomplished without a given tool, doesn't mean the tool is useless, or isn't useful for that use case. If that were true, we'd never use anything but machine code.

I have not found any useful scenarios where I want static type annotations. There's not much more to say than that. I'd like to hear of scenarios others have found useful so I can compare them to my own.

Meanwhile, I notice you haven't responded to the point that solid integration with statically typed languages often requires type annotation; e.g. jythonc's use of special patterns in docstrings. Integration with other languages, documentation, and runtime introspection/adaptation are my use cases for type annotation.

I'm not sure what you mean by "solid" integration. I have done production-quality integration between "agile" languages like Lisp, Smalltalk, and Python with "rigid" languages like Pascal, C, C++.

There are situations where the more rigid languages have required, say, a 32-bit integer or a specifically formatted sequence of values (i.e. "struct" or "record"). "Agile" languages tend to provide integers that are not limited by the word size of the underlying hardware. In scenarios like this then, on the agile side of the integration a check is necessary that the integer will fit in the rigid size of 32-bits and so on. Likewise a conversion is necessary to actually format the scalar data and structured data into the kind expected on the rigid side.

I would not call these expressions "static type annotations" in the agile language though. Rather they are hoops I'd not have to jump through as much if the rigid language were more agile. The language systems I have used that I can recall have tended to allow me a way to express these in the agile language itself rather than in a comment or doc string, but that's a minor point.

Languages like Java and C# are less rigid and given their capabilities for reflection, integration with more agile languages tend to be more automatic. And so Jython and Python.Net among others tend to do most of the conversion automatically without special annotations or coding.

Corner cases require more programmer attention but that's also a minor point. They could agree on a common model for data exchange such as is done in CORBA and it's descendent WS-xxx. Doing integration via CORBA using Smalltalk is so easy I believe had more programmers been working this way the WS-xxx fiasco would never have been. Rather improvements to CORBA's relationship with HTTP would have been getting all the intention. These are market force issues, not software.

Another source of feedback on this is the Inter-Language Unification work done at Xerox. Related to CORBA but more focused on integration aspects and RPC, where CORBA was beginning to branch out into a variety of distributed programming models.

I don't see how type inference helps with either documentation or introspection, either. If it's pure "duck typing", how is the system going to infer that I want an IAtomicStream, say, versus an IRawStream, if the two have the same methods? Duck typing isn't sufficient to distinguish different *semantics* of a type/interface, only its method signature -- and that is not sufficient for documentation!

If you need an IAtomicStream on the rigid side then there is probably enough information to infer that from the code on the agile side. If the rigid specification is ambiguous (well, then it's not really a "specification" is it?)... then, yes, you need to have some kind of an expression on the agile side to disambiguate.

The point is, this is a burden rather than a feature. Why would I *want* to work at this level of detail?

A good bit of information on the power of inference for agile languages can be found in the implementation of the Stalin Scheme compiler, see "Flow-Directed Lightweight Closure Conversion" by Jeffrey Mark Siskind.

Documentation needs to present the semantics of the interface, so that if you are implementing that interface yourself, you know what semantics to implement.

The documentation I want to see is (1) executable examples or (2) technical memos that augment executable examples. Period.

Likewise, for introspection, I don't see how an implicit signature helps. Let's say I want to create an XML schema for a document format that can contain messages that get converted to method calls on some object. If each of those methods uses a different set of methods on their arguments, I'm going to end up defining new types for each method, which might be okay for the computer to process, but for a human being it's going to be a mess to understand.

I am not sure what this example is about. I agree there are integration scenarios where something like an XML Scheme is required to specify the kinds of messages that can be exchanged between language-independent processes. That does not in any way imply that static type annotations are a benefit to the languages I use to implement the independent processes.

Type inference, IMO, is just type checking. It doesn't seem to me to be useful for anything else -- and like you, I'm not interested in type checking! (I suppose it could be used for optimization in some cases, but only if you can statically prove a concrete type - not just an operation signature.)

Type inference is better than type annotation. The real benefit I see is in getting even more capable agile modeling and inferencing tools by extrapolating from recent work in model checking. Simple, even compound, type checks are uninteresting. We do need a lot of help with concurrent state machines however. Tools that can tell me more about *real* behavior problems rather than simple type checks should be getting all this attention.

Now, perhaps I could be wrong, and there is some other way to accomplish these use cases that's just as clean. If so, I'd sure like to see them. I personally don't see that any of my uses for type annotation *can* be satisfied by inference; there's just not enough information. Heck, I don't see how a *human* could do the inference in the absence of added documentation, let alone a computer. It would be little more than blind guessing.

I think I see one use case here... how to integrate languages that have different data models. I agree system integration requires some kind of agreement on specifying data integration. I'm not sure what else I am seeing here.

OK. I am getting tired of writing about type checking. I think we're in agreement on this use case of language-independent data integration.

Prediction of Hope

Don Box has some predictions for 2005. I like reading people's ideas, but I only have hopes, not predicitions. One of Don's predictions leads to a hope of mine...

The term SOA will have been beaten to death and the software industry will invent or recycle some equally vague term to replace it. The term has zero differentiation value at this point and marketing teams across the globe are looking to coin a replacement that will give them something more interesting to say about their middleware than "we move messages around really well." If "Business Agents" become the buzzword de l'année, I expect Mary Jo Foley to hunt me down and kill me.

Perhaps more end users in 2005 will demand that their programmers find better ways to move messages around really well and dispense with the buzz words.

Another interesting set of predictions from Carlos Perez' Managability blog. Especially those on Rich Internet Applications, Grid Architecture and REST, and Scripting Languages.

Dynamic Types and Naked Objects

PJE writes in a comment...

There *are* other uses for type declarations besides type checking. For example, the Naked Objects framework in Java uses method signatures to figure out what actions might apply when one object is dragged-and-dropped onto another object in a GUI.

Jayson Vantuyl responds in another comment...

In response to the above comment, I would point out that there are other (better) ways to do what the Naked Objects Framework (NOF) is doing in Python.

I wrote and demonstrated a Naked Objects framework in Jython at the 2003 XML DevCon. One reviewer...

14:46 - Patrick Logan - "Point & Click XML Applications" - an interesting discussion and demonstration (using Jython) of point and click application development... to me one of the most interesting points was that at the end of his presentation he pointed out that most of these concepts are extensions of things started 15+ years ago such as Lotus Notes, Agenda, Naked Objects, Tuple Spaces, etc.

I didn't allocate as much time as I'd hoped, and I wasn't so happy with the result. Nevertheless, the system did not require type annotations in the Python. Rather the end user is able to define their own data types in the GUI itself (including "Any").

If I were to continue with that work, I'd consider making these "end user annoations" optional and provide inference as well as modifying the inferred type dynamically as users create more objects. (With some kind of confirmation of the user's intentions.) But I would not think language extensions to Python would be worthwhile.

Back to PJE...

Documentation, of course, is an even more immediately useful use case. A good syntax would be more precise and more brief than docstring explanations.

I think there are more useful kinds of documentation to write other than type annotations. I'd like the system to infer types and tell me what it determines the current types might be for some method. Moreover, I'd like the inferencing mechanism to consider the test code and data as well as the application code.

Given those inferences I could correct my code, add new tests or test data, or have the system keep the inferences around as automatically generated documentation if so desired.

The documentation I write myself would be more useful in the form of technical memos (see the complete Episodes pattern language).

Is there a danger of over-declaration by newbies? Sure. I'd probably find it really annoying to use code with excessive declarations, if those declarations actually restricted anything. However, if they were *just annotations* (or were adaptation specifiers per PEP 246), then I could still pass their code any darn thing I pleased, and we could all continue to be happy.

Yikes! What would be worse, type annotations that *are* enforced or type annotations that are *not* enforced?

Smalltalk Keeps Going

Here's how Michael Lucas-Smith keeps his Smalltalk servers humming with new capabilities.

The ROI of Optional Type Annotations

From comments below...

How is the argument from reliability of Lisp and Erlang systems an argument against optional static type declarations?

The real question is, should optional type annotations be added to Python? I'd say no, the return on investment is not nearly as great as investing in several other implementation features.

In the Lisp world, you program with dynamic typing initially until the program stabilizes and the hot spots are known. You then type annotate just the hot spots to improve code generation of those hot spots (Lisp code is generally compiled), with the option to go to C to improve the hottest of the hot spots.

Optional type annotations were added to Common Lisp in the early 1980's. Compiler strategies have improved a lot since then, as have machine capabilities. I think a better return would come from investing in the implementation of the current Python language rather than changing the Python language itself.

Basically, type annotations in Lisp (and, one presumes, Python) are an upside option that you can but don't have to use. Writing Python code (or Lisp code) from scratch with type annotations would be pretty silly. (Or, to put this another way, in Lisp type annotation is a performance, not a reliability feature).

I think the downside of having every Python programmer have to understand the best practices of optional type annotations would be far worse than the upside of having them. To repeat myself, the investment should be made "under the hood" of the current Python language.

Sadness and Grief

Everytime a take a look at the news, the death toll has risen another thousand or so people. The number as I write this is around 22,000 deaths. That also implies so many tens of thousands of injuries.

How can these numbers be comprehended? Almost nothing I can recall, related to one single event compares. The map of impact includes Sri Lanka, the entire eastern seaboard of India, as well as Thailand, Indonesia, Malaysia.

Incomprehensible sadness and grief.

Ways to help.

About Myself

Anonymous (Sam?) wonders...

So the world wants to know...

Actually I doubt very few in the world want to know this.

...have you ever shipped a real commercial product ever (even better a scalable one) or are you just a play with esoteric languages complaining whiner?

The last few years I've just been playing with *agile* (not so esoteric) languages and been a complaining whiner. I've actually taken a new position where most of my time will be spent developing again, so for your benefit I may not have as much time to simply complain and whine!

But I have been developing software professionally for 20+ years, beginning when I was an undergrad CS major developing a payroll and materials management system in BASIC (not the visual kind) on an IBM 5100. I've also developed software for electronics design and simulation using PL/1, C, C++, Pascal, Mainsail (a Pascal-like language with garbage collection, etc.), and Lisp. I've developed factory automation systems in C, C++, and Lisp. I've developed conferencing systems in C++ and Smalltalk; business and web systems in Smalltalk and Java; and systems programming in C, Smalltalk, and Java. I developed a mechanism in Smalltalk that doubled the number of concurrent users for Gemstone Smalltalk systems using HTML and applet front-ends. One of the applications for this was a dispatching system developed at Florida Power and Light where the Gemstone portion of the system outlasted the IBM mainframe portion in a real production scenario. (When IBM patched their mainframe's TPC/IP stack, the Gemstone portion was reliably processing what it could, and then picked back up to full speed as usual.) I did not work on the end application, but designed and implemented the underlying mechanism.

Hardware these have run on include the aforementioned IBM 5100, IBM PC's, Macintosh, Lisp machines (Texas Instruments and Symbolics), various Unix systems (DEC, Sun, VAX, IBM, HP, perhaps others I've forgotten), the Tektronix 4406 Smalltalk workstation (which I am surprised there is not much on the web), Apollo workstations, Data General Eclipse, and something else which I probably can't mention to this day.

Have you ever shipped products that people have used or are you a washed up academic?

I have shipped many products and have never been an academic, although I may in fact be washed up. Fair questions.

Even More on Reliability and Static Types

I answer some recent comments on static type annotations and reliability...

"Great programmers produce great programs."

I agree this is the number one factor. But they're better off using better tools.

"Surely you mean static type annotations"

Yes. As for languages like Haskell and ML that infer types, I only have experience writing a few very small programs. I think this approach has potential, but would like to see evidence of large, evolving, dynamic systems built this way.

"It seemed smug in its assumptions, assumptions which I don't think are certain in any way."

Fair enough, I can be fairly smug. 8^)

I agree with you in terms of absolute certainty. All we have are stories, but I think they are worth telling if for no other reason than to root out contrary stories (which I have not see).

"This post seems much better"

Thanks for getting me to write it.

"Live updating is a powerful feature, one that is possible in python but easy in smalltalk, and a point to be argued in this debate."

I think the language and runtime have to (and should be designed to) deliberately support this. I'd rather see the Python community focus on this than on optional static typing.

"I don't yet understand erlang's concurrency, or whatever other language features it has that support reliability, but it's something I've been meaning to study in detail. I will try to read the thesis you referenced; the abstract is interesting."

That's great, if I can get others to try new ideas. The basic idea is that Erlang is designed to be a simple, concurrency-oriented language. You might want to begin with Joe Armstrong's invited talk at Lightweight Languages 2 (http://ll2.ai.mit.edu), the slides and the video (morning session).

"I admit that I played devil's advocate"

I appreciate that.

"Erlang systems are reliable because the language does not have static-type-checking; or because the language is a single-assignment functional language designed around process-isolation?"

Erlang systems are reliable for a variety of reasons. The original argument in this thread was that static type annotations are not necessary for reliability, and could very well be at a disadvantage compared to languages like Erlang, Smalltalk, Lisp, and Python that do not have statictype annotations. This is an argument against adding optional static type annotations to Python, a "feature" which is currently under investigation in the Python community.

"How about Smalltalk? I've seen superb Smalltalk systems and dreadful ones."

Yes, see the quote above about great programmers.

"How about Orbitz? Hmmm iirc a large part of their system is built around Jini..."

I'm sure Orbitz is a very large post-modern system with a variety of moving parts. I would note that Jini's coordination mechanism (JavaSpaces) is asynchronous and dynamically typed (content-based, pattern-matched, addressing). If I were to build a significant system in Java, I would put this consideration high on my list.

The basic coordination mechanism in Erlang also is asynchronous, dynamically typed, and based on pattern matching. I don't consider this a coincidence.

More on Reliability and Agile vs. Rigid Languages

The author of a previous quote comments...

It is logically flawed to say that because one lightweight language system has been running very reliably, that static typing doesn't help with reliability.

If you read through Joe Armstrong's thesis, he describes several large and small systems built using Erlang. More about the software itself and other conference reports are at the Erlang open source site.

If the Erlang examples are not enough, let's consider other languages.

How about Smalltalk? Read on James Robertson's blog how he's able to debug and update live servers. Read Jay Almarode's articles on Gemstone Smalltalk (index to PDF's), how it provides multiple users a distributed, persistent, versioned dynamic system that's kept applications running in finance, insurance, medical, manufacturing, etc. Read about JP Morgan's use of Smalltalk in their financial management system which won a 2004 Computerworld award.

Maybe you'd like to know about Lisp and how it's used by Orbitz for travel planning. There are many similar successes with Lisp.

The list goes on.

I want dynamic languages to succeed in this scenario too (I'm a python fan), but I don't see any evidence, other than partisan flag waving, which demonstrates the superiority of either methodology in creating reliable systems.

There is sufficient evidence that dynamic languages succeed in creating reliable systems. I have not seen a reasonably supported hypothesis for static languages in these situations. That is, I have seen claims that they will catch more errors, or catch them sooner, or reduce testing, but I have never seen substantial evidence in support of these claims.

If you have any such evidence, please let me know. My own experience includes building significant systems in several agile and rigid languages over twenty-four years. Based on that experience I would only choose a dynamic, agile language.

Do you have any actual evidence as to why dynamic languages are better for creating very reliable systems than are statically-typed languages, or just that one anecdote?

Read about the systems above. These languages are *agile* in that they support flexibility and evolution of dynamic systems. Static type checking tends to be *rigid* which, in the small without a test-driven approach, provides the illusion of security. As systems get larger, statically specified information become even less important and even more of a hindrance to change.

Our initial intuition is that reliable systems must be specified up front, and since static type information is easy to specify up front, then this must be the foundation of reliable systems. Almost the opposite is the case. We do need up front specifications, but they should be simple expressions of small parts of the ultimate system. Those specifications should be in the form of tests and dynamic (and concurrent) models, and simple solutions that fail fast.

Read about the systems above. The wisdom is not entirely intuitive relative to many of today's popular programming languages and tools. But the history of computing is inevitably moving in this direction.

A Simple One

Sam Gentile asks a simple question...

So some people are always bemoaning why no one pays attention to their technologies. Why is it that Microsoft can command such loyalty that when a new CTP of Whidbey comes out they'll drop everything and install it even on Xmas Eve (besides being a hapless geek)?

A picture paints a thousand words...

Happy New Year! Where do you want to go today?

Concurrency Oriented Programming

The Marquee de Sells writes...

We'll have to have much better language-level support for concurrent programming. What we have now sucks.

And concurrently, Tim Bray writes...

Almost by definition, the slow media-centric apps should be able to deploy parallelism to good effect. But this deployment work is not for the faint of heart, because thread-aware programming is, well, hard...

If we’re going to empower application programmers to get the most out of the high-TLP chips, we need big advances in development and debugging technology...

Once we figure out some design patterns, there are grounds for hope that we can do some tooling around it.

Agreed then. We need better languages and runtimes (example1, example2), better tools (example1, example2, example3), and better patterns (example1, example2, example3).