Now that I’m back from vacation, I’ll answer the implicit question Adam asked in his post about less powerful languages:

Perhaps that is what Curtis is really aiming at: a powerful language that enough people can be good at.

That’s close. I don’t want a less powerful language, but I do want one without a steep learning curve, and in fact, one where you can ignore the more abstract parts unless you really need them. There’s more to it than that, though: each language makes some things easy and some things hard. I want a language where the things that our developers need to do often are easy, and the hard things are things they rarely need to do.

When mutual funds and such issue a prospectus, they typically have a phrase like “past results should not be taken as a guarantee of future returns,” and something similar should probably be said about projecting future demand for mainframe capacity. But as long as we’re trying to predict the future, the past provides most of what little actual data we have to go on.

Continue reading →

The first browser I used was NCSA Mosaic, but I soon moved to Netscape Navigator. I switched to Firefox nearly as soon as it became available, and it’s been my primary browser ever since. (I’ve always had as many browsers as would work installed on my Mac to test things.) Lately, however, I’ve noticed that Firefox starts to get really slow after a week or so of use, and I’ve found myself stopping and restarting it periodically to get better performance.

I tried switching to Safari when Safari 4 first came out, but a couple of things moved me back: the “awesome bar”, which searched titles and the interior of URLs, and the NoSquint plugin, which remembers how much I’ve increased the font size on sites. (I also consider Flashblock an essential, but WebKit has the equivalent ClickToFlash.) When I saw that Safari 5 had similar functionality to the awesome bar, I decided to try switching again. That was Tuesday, and so far it’s going well. Or rather, it was until I started writing this post: ironically, the first time I tried to add the link to NoSquint, Safari crashed.

I haven’t found an equivalent for NoSquint, but the Reader feature has been working pretty well for me. Some people (like Ars Technica) have complained that this feature breaks the business model for most commercial sites, but all I have to say is, if you don’t want people to use the feature, make your site readable to start with.

BIG IRON: The Mainframe Story (so far)

It’s long (just over half an hour) and includes a lot of marketing/propaganda, and by the end I was really, really tired of the background music, but you might find some of the history and perspectives interesting.

(I find it curious that CA is doing as much if not more to push mainframe computing than IBM. I guess the people who took over after all the crooks were sent to jail decided that was a good way to mend fences with their customers.)

Adam wonders what I mean by a language “optimized for business programming,” and I can’t really blame him because I’m not sure myself. However, my thinking isn’t really going the direction he guessed.

It may be nothing more than “a language that feels familiar to programmers coming from COBOL or Natural.” Languages like Java and PHP have gotten a lot of leverage out of having a “familiar, C-like syntax” (even if I always thought that was like saying, “familiar, IRS-like customer service”) and there is probably some value in providing this kind of familiarity. My main motivation in suggesting a Natural-like language that integrates with the JVM or CLR was as a migration path for legacy Natural programs.

I have a feeling, though, that mere familiarity is only part of it. Most programming languages are developed by people with relatively strong mathematical backgrounds, and I have the impression that they are in some sense “too mathematical” for people with a strong business focus.

I don’t know if this would actually work, but here are some ideas about a “business-optimized” language:

• Give variables value semantics. While you can often ignore the issue, I suspect that variables with reference semantics cause problems for lots of people.
• Include tolerance for redundancy. Programmers are usually lazy (and in fact I think unwillingness to do extra work helps make for better programming) so in Natural we usually write “READ EMPLOYEES BY PERSONNEL-ID”, but we can write “READ ALL RECORDS IN FILE EMPLOYEES IN LOGICAL SEQUENCE BY PERSONNEL-ID”. Human languages have lots of redundancy for good reasons, and if we allowed more in programming languages it might help, at least in reading comprehension.
• Segregate higher-level abstractions from basic capabilities. We want a language with coroutines, functions as objects, etc., but it should be easy to write simple programs without dealing with them.

I realize that these ideas might actually make things worse, but who knows.

(In response to Ross’s comment, I would like to develop an Adabas library for Python at some point. I’m just not sure if that’s really best.)

Yesterday Adam wrote a post about learning new languages, which prompts me to write a few thoughts I’ve had about the programming languages we use at the University.

As much as I like Python and Ruby, they don’t come from the “data processing” tradition and these languages aren’t really optimized for business processing. About four years ago I suggested to Software AG that they develop a new language, like Natural but with a more modern foundation, and design it to run on the Java VM and Microsoft’s CLR, with hooks to call out to routines written in the other languages available on those platforms. Software AG hasn’t done anything with my suggestion (not that I expected them to) but I sometimes wonder what it would be like if they did.

(Sometimes I toy with the idea of writing such a language myself, but then I return to sanity.)

RAS is an acronym IBM likes to use a lot; it stands for “Reliability, Availability, Serviceability.” In general, it’s about how much you can count on a system to be up and running when you need it.

While we’d always prefer systems that were perfectly reliable and always available, getting there costs a lot of money. Part of designing a system involves trading off RAS characteristics against cost: if it’s OK for a service to be down for hours at a time, why spend the extra money for highly reliable hardware and software?

IBM’s z Series hardware and the z/OS operating system are designed for very high RAS, which is one of the reasons for their high prices. I think that we have many services on our mainframe that need this level of reliability, but there are lots of other services that are there because they have integration points with the mission-critical services. It would be really good if the business leaders of the University would try to categorize the various services provided by the mainframe according to how critical they are. Then, if we could solve some of the integration problems I mentioned in my last post, we could start running the less critical applications on less costly platforms.

This would also help us more immediately during registration and other times of peak capacity. Since we don’t have a big enough mainframe to meet the demand at these times, our only way of getting through is to stop some of the services. (By the way, why does last summer’s “mainframe efficiency initiative” keep getting touted as a success? We only made it through August registration because Jon turned off the Trim monitor on Adabas, which means we now have no way to diagnose database performance problems, and in January we did have to turn off services.) As systems administrators, we can’t really evaluate the relative priorities of different applications, so during crunch times we don’t know what to stop and what to try to keep running. In January we picked services that were timing out anyway (it seems safe to turn something off if it’s not working) but if that isn’t enough we really shouldn’t be the ones trying to decide.

(As long as I’m talking about RAS, I should mention that one of the problems we had with the migration assessment plan is that the hardware recommended is from a lower reliability class than the current mainframe. Multiple hardware vendors had provided specifications for candidate systems, but the one that made it into the report was the one that didn’t meet what we felt were minimum reliability criteria. Also, the other high-reliability systems didn’t cost that much less than a z Series machine.)

For administrative computing at the University, integration is one of our greatest strengths, but it also may be our greatest weakness.

Integration is a strength, because when different applications need to work together they do so easily.

Integration is a weakness, because when an application needs to change those changes must be coordinated with the other applications it works with. This is greatly highlighted when we consider possible projects like the proposed mainframe migration.

When I first started working here, integration usually happened at the Adabas file level. If application A needed access to application B’s data, application A was given appropriate database permissions. But now if application B wanted to change their file layout, it had to be coordinated with application A. Also, there are clearly security implications for this.

So we invented secured modules. This has helped with the security issues, but I don’t think it has decoupled applications as much as we might want.

Is there a next step, something to replace secured modules to decouple our applications more? Some way for applications to communicate more flexibly, so different areas can move in different directions more easily? Doing more with Broker might be one way, but at a significant cost in performance. Where one application is moving off the mainframe, Adabas Replicator might be a useful tool. Any other ideas?

In an earlier post I mentioned Nicholas Carr’s book Does IT Matter? and the argument that information technology has become a commodity, and therefore an organization like the University should buy off-the-shelf systems to meet IT needs. I think anyone who wants to engage in the “buy vs. build” argument should read this book in order to understand the reasoning, even if in the end you don’t agree with it.

In this book, Carr reviews how earlier technology advances, like the development of railroads and the harnessing of electricity, played out in business. At first, businesses that embraced the new technology had a strategic advantage over those that didn’t. After a while, though, all businesses were using it (or had gone out of business) so there was no strategic advantage to the technology, it had just become a part of the cost of doing business. Instead of devising a “railroad strategy” or an “electricity strategy,” businesses located near a rail line or hooked up to an electric utility and purchased standard equipment to use the technology. Carr argues that information technology has reached this same stage.

Carr applies his argument to both hardware and software. Now, I’m mostly a software guy, so my discussion will focus on that side. Software is rather unique from an economic point of view: it costs a lot to create a program, but once it’s been written it costs very close to nothing to copy and distribute it. This drives software toward commodity pricing: the more copies of the program you sell, the smaller a percentage of the fixed costs of software development each customer will have to pay.

On the other hand, a big part of commoditization is standardization. I can treat electricity as a commodity because every device plugs into a few standard outlets: rather than having to purchase the same kind of, say, toaster, as my last one because it has a proprietary way to get power from the electrical lines, I can buy any brand. If I have a Ford car, I can replace it with a Chevy without changing the route I drive to work. With software we do not yet have nearly this degree of standardization. As Brian Cantrill said in The Economics of Software :

The problem is that for all of the rhetoric about software becoming a “commodity”, most software is still very much not a commodity: one software product is rarely completely interchangeable with another. The lack of interchangeability isn’t as much of an issue for a project that is still being specified (one can design around the specific intricacies of a specific piece of software), but it’s very much an issue after a project has deployed: deployed systems are rife with implicit dependencies among the different software components. These dependencies — and thus the cost to replace a given software component — tend to increase over time. That is, your demand becomes more and more price inelastic as time goes on, until you reach a point of complete price inelasticity. Perhaps this is the point when you have so much layered on top of the decision, that a change is economically impossible. Or perhaps it’s the point when the technical talent that would retool your infrastructure around a different product has gone on to do something else — or perhaps they’re no longer with the company. Whatever the reason, it’s the point after which the software has become so baked into your infrastructure, the decision cannot be revisited.

This is another article you should definitely read if you are interested in this issue. If you do, you’ll see that his analysis has influenced mine. Cantrill’s conclusion is that the peculiar economics of software mean that in the long run open source provides the greatest benefits for both software producers and consumers.

So how does this apply to the University? We are definitely in a “vendor lock-in” situation, and the vendors that have us locked in are not just IBM (as some seem to be framing the issue) but also Software AG and, well, ourselves, with the software we’ve developed in-house. Any change is going to be costly, but also any change will most likely result in being locked in to a new set of vendors. Perhaps Cantrill is right, and we should be looking more closely at open source software if we want to have more flexibility in the future.

W3C Launches Audio Incubator Group

I’m guessing this is motivated by the controversy over HTML5 codecs.