"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Thursday, August 23, 2007

US News and World Report

A good essay by Mort Zuckerman...

No one knows the true value of all that residential real estate at the base of the pyramid in which mortgages back up the collateral debt obligations that in turn back up the short-term loans that many banks and hedge funds have made to finance these CDOs. A recent review of would-be homeowners is hardly encouraging. Almost all exaggerated their incomes to win approval, and almost 60 percent inflated their incomes by more than 50 percent. Too many home loans did not require any down payment, principal repayment, or documentation...

With home prices falling rather than rising, refinancing is impossible for borrowers who fall behind. Defaults have accelerated. As one pioneer in the bundling of mortgages into marketable securities put it, "We're not really sure what the guy's income is, and...we're not sure what the house is worth."...

Many pension funds, insurance companies, hedge funds, and banks hold swaps and subprime derivatives but have not yet reported their losses, or at least not all of their losses, making it difficult to understand how big their exposure is. They are having difficulties determining the value of assets, making them impossible to sell, i.e., illiquid. The danger is that a liquidity crisis will drive financial institutions into insolvency, which could have a major impact on the economy.

The central banks have seen the threat. The European Central Bank has put up $212 billion "to assure orderly conditions in the euro money market." It's an amount so staggering that it perversely led the markets to fear that the ECB knows something that would indicate the situation is worse than it seems. The Federal Reserve similarly stated that it would provide "reserves as necessary." The concern is that the market has such anxiety about all debts, up and down the food chain, that no one will wish to buy them. Put it the other way: Fewer and fewer lenders are ready to lend. Many were going to sell high-yield bonds to finance their growth; they have had to withdraw them. In July, the issuance of these bonds dropped about 90 percent from June to a mere $2.4 billion. Even high-quality investment-grade bond offerings from companies with excellent credit fell from $109 billion in June to only $30 billion in July.

Wednesday, August 22, 2007

JSON Security

Interesting posts and comments on json and security in browsers: robubu and resig. Boils down to: "browser security pretty much sucks no matter what" and "if your json parser relies on eval(), you are a fool, no matter how fast it is".

As Patrick Mueller commented...

Approach 2 and 3 should, simply, NEVER, EVER, EVER be used. There are plenty of libraries available today to parse JSON data structures, and none of them will EVER, EVER be able to read the whacked out Approach 2 and 3 styles. EVER.

Data, baby, data!

JSON is data. There is no way any bit of it should ever be treated as code. Some day browsers will become real platforms for applications and we will laugh at all this.

That seems a long way off.

What a difference a day makes

On August 16...

William Poole, president of the St. Louis Federal Reserve Bank, told Bloomberg News in an interview that the subprime mortgage rout doesn't threaten U.S. economic growth, and only a "calamity" would justify an interest-rate cut now.
And the next day...
The Fed just issued a strange press release and a special announcement lowering the discount window borrowing rate by 50bp, to 5.75%. The more widely followed Federal Funds rate is unchanged at 5.25%...

This would be a reversal of policy from just 10 days ago.

The special announcement is the bigger news. Not only did they cut the rate, but they've increased the borrowing time to 30 days and have increased what they will accept as collateral. All importantly, they are accepting home mortgages and related assets.

Nothing to see over here. Just go on about your day. Move along.

This is fascinating stuff. Poor Ben Bernanke following in Greenspan's shoes. This from Greenspan back a few years...

Alan Greenspan was a study in contradiction. On Monday, he extolled the virtues of the levered-up homeowner to a credit union conference. The next day, in a speech to the Senate Banking Committee, he was singing a different tune altogether. Fannie Mae and Freddie Mac, the giant providers of mortgage capital, he warned, "are expanding at a pace beyond that consistent with systemic safety," and that "preventative actions are required sooner, rather than later."

For a Federal Reserve chairman who has demonstrated that he couldn't identify reckless behavior if it ran him over, it was rather surprising to hear him chide Fannie and Freddie for their recklessness.

Greenspan's latest comments reminded me of a speech he gave on March 6, 2000, which I have dubbed "An Ode to Technology." In the speech, he waxed on about the wonders of technology and how it had brought us a new era and all that other stuff. Folks may not remember that date, but it was four days before the Nasdaq Composite hit its all-time high of 5,048.62. Despite the recovery over the past year ago, the composite is still down nearly 60% from the March 2000 peak.

One-a-days

Via Steve Dekorte, mortgage lenders in August so far are failing at an average of one per day...

Again the question is raised, who will be refinancing the trillion dollars of mortgage resets over the next year?
Also...
...approximately $500 billion of adjustable rate mortgages are scheduled to reset skyward in 2007 by an average of over 200 basis points. 2008 holds even more surprises with nearly $700 billion ARMS subject to reset, nearly 3/4 of which are subprimes.
Ah, it'll blow over. ;-/

Pushy And Stuff

Dan Creswell has a nicely done discussion on that whole push/pull thing.

Rather than focus solely on either approach in isolation, I think the best solution is to use a combination. This has a couple of advantages:

  1. Clients can potentially use whichever method is more appropriate for them.
  2. It provides significant opportunity for fine tuning.
  3. It provides a nice simple recovery model.
  4. Responsibility is balanced throughout the system keeping complexity down.
For some kinds of information, just providing "pull" could be sufficient. For others, "push" may be preferred, but as Dan (and Bill, previously) explained, having that available to be pulled as well pays off.

Tuesday, August 21, 2007

Polling and/or Pushing

Dan Creswell writes in his bookmark notes (so what do I link to?)...

Polling is indeed nice and simple but it also has it's problems - how often to poll, resource consumption etc all of which the average enterprise finds offensive - probably why they'd rather do push even though it adds complexity.
Which is why I'm glad all those smart people worked on http and atom (links to the usual suspects omitted). For most cases, maybe it comes down to starting like this (related posts: Bill, Mike)...
  • Follow those specs (http, atom format, atompub) as far as they take you, i.e. when the customer can afford to obey the rules of polling, aggregating, etc.
  • When the customer has a need to know more immediately, or has a need to know many intermittent things without always knowing whom to poll, then use atom entries over xmpp.
Straying from that only under exeptional conditions.

The "Ease" Argument Again?

Dan Diephouse argues...

Making an RPC application is much easier. This is one of the killer features of SOAP/WSDL. I can take my business service and build a web service out of it with very little effort (I assert that there are non-evil ways to do this, but thats another story). I can then be interoperating with a .NET application in just a minute or two. Or I can take a WSDL, generate a set of objects, and just write some glue code between my internal objects and the web service objects.
Sigh. Again with the "ease" argument. There're enough counterarguments to the false sense of security provided by "easy tooling". Heck, I don't even see the dotnet people making that case any longer. (Admittedly, since I work with zero dotnet programmers these days, I don't have to watch those lists.)

Designing with HTTP and related standards is something everyone should be studying right now, even if they're not taking it into production. This will get easier, even with Java, and the results will pay dividends way beyond what the current IDE "tooling" provides for "easy RPC".

If not, I still may have that Word document an SAP consultant sent me, telling me how to hand-edit a WSDL to get SAP's SOAP to interoperate with other SOAPs in Java and dotnet. That may make things *easier* for you.

...and I'm done.

Monday, August 20, 2007

Our Viking Blogger

For some reason he thought he could quietly blog away in some other corner of the internets, but fuzzy found him. Our co-worker Erik has a blog. He's been working with some folks on using Flex and Rails.

Friday, August 17, 2007

Secret Sauce

Sam Ruby writes...

The “secret sauce” is pattern matching. Things like “if these conditions are met, this code fires, with the following variables set”. With Erlang, this metaphor is everywhere. Function calls are an exercise in pattern matching. Database queries are an exercise in pattern matching. Message passing is... oh, you get the idea.
I would suggest pattern matching is 1/3 of the secret sauce. The other two parts being...
  • Implicit mailbox per process with pattern-based rather than solely chronological reception.
  • Fail fast without failure coding. Function and case patterns and guards define the *success* cases. Failures to match by default result in failing the process.
I'll expand on these at some point. They are significant features not found in most popular languages, and all three combine to reinforce each other.

Shoot for Five

Sam Ruby on the future of "messaging"...

Ten years from now, we will be using SMS text messages to change the channel on the televison...

Remember all of those incompatible protocols I mentioned above? You know what happened to them?

Well, somebody had a bright idea to define an inter-networking protocol (they called it “internet” for short) that could be used as a gateway between these local area networks. Eventually, people stopped using the often proprietary LAN protocols in favor of directly connecting into the internet protocol itself.

Ain’t it funny how that worked out?

Enterprisey Edits On Wikipedia

Went to wikipedia to view the page on "Enterprisey". Got redirected to the page on "Enterprise software". Huh?

Looked at the change log for "Enterprisey". Damn. A couple of back and forths, and the current result appears to me to be rather, well, "Enterprisey". Here's what's on *that* page. At the top...

Enterprise Software is software that solves an enterprise problem (rather than a departmental problem) and usually enterprise software is written using Enterprise Software Architecture. Due to the cost of building what is often proprietary software only large organizations attempt to build software that models the entire business enterprise and is the core system of governing the enterprise and the core of business communications within the enterprise.
I'm not sure why the term "solves" is not in quotes there.

And at the bottom...

Some enterprise software vendors using the latter definition develop highly complex products that are often overkill for smaller organizations, and the application of these can be a very frustrating task. Thus, sometimes "enterprise" might be used sarcastically to mean overly complex software. The adjective "enterprisey"[citation needed] is sometimes used to make such sarcasm explicit.
Relegating the wonderful term "Enterprisey" to the bottom of a rather staid page like "Enterprise software" is just not right. But claiming that "enterprisey" merely implies "overkill" is blasphemy.

Forever, the term "Enterprisey" will mean this... (animation). As in, "It's enterprisey!"

I took a pass at editing the explanation of "enterprisey" on the "Enterprise software" page. Please take it and run with it.

I wonder who's been editing these pages. Back to the logs and do some searching.

Thursday, August 16, 2007

Dunno

Brit Butler left a good comment in a recent post...

I've watched this video and also read the slides from Sweeney's POPL presentation. Sweeney basically comes out on the side of Transaction Memory without saying much about the message passing model (though he later goes in to detail on LtU). I think TM is ugly, regardless of what Simon Peyton-Jones or Sweeney says. They're smart people but it seems like an ugly hack of a system. It is the maintenance of a style that is begging for deprecation. I'd kind of hate to see us save it. All the same, their intelligence makes me wonder if message-passing really can't scale to Sweeney's needs. What are your thoughts on where some shared state is necessary? Is that handled well in Erlang? Do Sweeney and Peyton-Jones arguments really hold weight? Is it just a "right tool for the job" kind of thing?
The best anyone can say about STM is the jury is still out. All I can say for sure is it is not my cup of tea for the systems I've been involved with over the last 25+ years, which are actually fairly wide ranging.

SPJ, et al. are *extremely* smart and capable people, far more than I am, so I have to give them some leaway, and perhaps I will be swayed toward STM for some reason currently beyond my line of sight. I admire nearly everything else about Haskell and GHC other than STM.

An irony for me, as for the "right tool for the job" argument is this:

I can see someone making the argument in some domain I don't usually work in that shared memory threads are better than shared nothing message passing for performance reasons. Some hard-real time scenario (I think I was real tired when I wrote that. Must have been thinking back to the days when I'd get into "Is automatic garbage collection practical?" debates. Nobody has those anymore, do they? Because I've got some real good arguments for GC.), some huge number crunching scenario, etc. where every byte and every cycle has to count in the extreme. But the irony then is that STM seems far more suited to a language like Haskell, which is also unlikely to be suited for these performance scenarios.

My only fear is that for the masses including myself, we need *simple* mechanisms, and the fewer of those, the better. Shared nothing messages seem to scale up, out, and down. STM seems more complicated, and an incomplete solution, and only a solution for shared memory. No thanks, at least until bigger brains than my own can show me why I should change my mind. They seem sidetracked on this one.

Good To Be The King(s)

Steve Dekorte's been tracking the credit fiasco with a number of good articles. And notes on the multi-billions of bailouts so far...

AFAICS, the net result is a transfer of wealth from the people who's dollars are devalued by the creation of money from such purchases to the lenders in the banking industry whose greed induced them to make poor decisions. The Fed was created and is run by bankers, so it shouldn't come as a surprise that it's principle purpose it to serve their interests at the expense of all others.

Andre Pang Video On Concurrent Programming And Games, Etc.

A nice video of Andre Pang on games, multi-cores, and, wait for it... erlang...

The more your computing environment resembles a game, the more cores/nodes/concurrency/networks you will need just to feed your little (shared) corner of the world.

Wednesday, August 15, 2007

The Well

From today's NYT Business Day. The papers by and large are worried about toys from China, and, oh, there is that war in the Middle East. But the most interesting story (assuming Bush is not going to call an end the war) is the credit crunch...

Turmoil in the subprime mortgage market spread again yesterday — this time to a type of short-term security held by money market mutual funds. These funds have become the investment of choice for many people seeking a safe haven...

The amount of commercial paper in the United States has grown to $2.2 trillion, according to Lehman Brothers, with about $1.2 trillion backed by residential mortgages, credit card receivables, car loans and other bonds. The major buyers include pension funds, insurance companies, hedge funds and short-term money market funds...

Until recently, the crisis in the credit markets has been limited to problems related to subprime mortgages, those given to borrowers with questionable credit histories. But as these troubles seep into other parts of the securities markets, fears of losses are rising in unexpected places...

“If the stigma of mortgage-related extendable-asset-backed commercial paper spreads to asset-backed commercial paper as a whole, you could see bailout events,” said Peter G. Crane, president of Crane Data, the publisher of a newsletter about money market mutual funds. But he added: “The stuff that the money funds are invested in are the highest quality, so it’s the last thing to have trouble.”

However, the investment strategies that once were considered conservative no longer are.

This could get a bit messier. "Bailout events".

Elsewhere in the same paper...

In a weary voice, Mr. Fanlo noted that executives from Kohlberg Kravis Roberts, including Henry Kravis and George Roberts, had been working closely with him to get through the “unprecedented” conditions the company faced.

He said he had been through numerous financial crises “and this is the most disturbing liquidity crisis, with real impact throughout the economy if it does not rectify.”...

Countrywide and most other mortgage lenders rely heavily on borrowing from banks, brokerage firms and bond investors to make loans that they quickly turn around and sell to investors through mortgage securities. In his report, Mr. Bruce said he had previously underestimated the risks to Countrywide.

“If enough financial pressure is placed on CFC or if the market loses confidence in its ability to function properly then the model can break, leading to an effective insolvency,” Mr. Bruce said in his note, referring to the company by its stock ticker symbol. “If liquidations do occur in a weak market, then it is possible for CFC to go bankrupt.”...

One analyst suggested that the market would not recover until more funds and banks detailed their exposures to mortgage securities and other debt acquired during the recent credit boom.

“The more funds that come to confession the better it is,” said Douglas M. Peta, chief market strategist at J. W. Seligman & Company. “Once all this stuff is out, all the analysts and the people with the sharp pencils can figure out how bad it is and they can put prices to it.”

Oh, right: people rushing to announce their rating is bad. We see that all the time.

Winterp

After EZDraw, another cool (weird?) GUI programming tool in the early 1990s was Winterp, an xlisp-based toolkit. Lots of weird stuff back then...

WINTERP uses a small, fast, object-oriented mini-Lisp interpreter based on XLISP-PLUS (David Betz, Tom Almy, Luke Tierney, et al), and has an object oriented interface to the OSF/Motif widget class hierarchy, and a combination of high-level object and functional interfaces to the Xtoolkit, Xlib, and underlying Unix system libraries. This environment significantly simplifies the construction of GUI-based applications, and makes these applications easier to modify and extend throughout the software life-cycle. It allows for the development of extensible applications in a safe execution environment -- errors in a new module won't destroy the whole system.

Don't Fidget With Widgets, Draw!

The best thing I came across, between MCV in the 1980s and the web in the 1990s was Joel Bartlett's Scheme library (for his fantastic Scheme->C system, oh, that was something) called EZDraw...

This report describes a graphics server, ezd, that sits between an application program and the X server and allows both existing and new programs easy access to structured graphics. Programs may draw, edit, and sense user events in terms of application-defined graphical objects. When run on workstations with 10 MIPS or faster processors, interactive response is excellent, indicating that ezd’s simple structured graphics drawing model can be widely applied. The enthusiastic response of ezd’s initial users and the variety of uses to which they have put it to suggest that there is a tremendous pent-up urge to draw with programs and that ezd has lowered the barriers to doing so.
Here's an image of an application using EZDraw to draw map graphics and display weather information from the location clicked on the map. A "mashup" in its day, I suppose...

5.3. Weather Forecasts

National Weather Service forecasts for the United States are sometimes available for network access. The ezd application shown in Figure 6 was constructed to fetch such forecasts for the contiguous 48 states. The mouse-sensitive diamonds on the map identify cities that issue forecasts. When the mouse is positioned over a diamond, text describing the region covered by the forecast is displayed. When the mouse is clicked on a diamond, the forecast is obtained via the network and displayed in the text area at the bottom of the window. The text is scrolled using the scroll bar on the left of the text. The mouse can be used to select areas of text for copying into other X applications. The radio buttons DISC, ZONE, WARN, and EXTEND select the type of forecast, the HELP push button replaces the forecast text with help text, and the QUIT push button terminates the application.

Every graphical element of this application, a 300 line Scheme program running entirely in the ezd server, is constructed using ezd. The text area, slider, check buttons, and push buttons are drawn with a library of interactors that use the basic ezd drawing capabilities. A simple ezdbased drawing tool was used to collect the 133 line segments and 50 city locations defining the the map by tracing a newspaper weather map (copied onto a transparency and taped over the display) and then positioning the cities on it.

The application graphics are automatically positioned based upon the size of the window. This is done by grouping the graphics into three drawings: one containing the map, one containing the buttons, and one containing the text area and slider. When the window is initially created or resized, the drawings are overlayed onto the window by centering the map at the top of the window, attaching the buttons to the right side of the window, and using the rest of the window below the buttons for the text area. Even though ezd does no automatic window layout, explicit layout requires only 5 ezd commands, generated by a 22 line Scheme procedure.

"National Weather Service forecasts for the United States are sometimes available for network access." How about that!

Weird Patterns

James Robertson relays someone's notion that MVC may have held back Smalltalk adoption early on. That's taking a modern perspective on a problem that did not exist back in the day.

I don't remember anyone complaining about MVC programming in Smalltalk in my circles in the mid-to-late 1980s. That was just how to program Smalltalk, and it was better than most of the other graphics libraries we had at hand on workstations. And MVC was no more weird than Flavors on Lisp Machines.

I do remember a paper by Ward Cuningham we got a hold of, marked "draft, do not circulate" (but we did, a lot). I've never found a published version of it. I've got the hard copy somewhere -- I should scan it in. Maybe Ward's got the original.

That paper explained the MVC objects with a simple, little wire list drawing application. Hmm... it's in one of two file cabinets, I'm sure.

Aaaaaanyway... the point is back then there were few if any preconceptions about anything, and not a lot of choice: mostly you built everything yourself. Only Smalltalk and Lisp had much to offer, prebuilt.

And programming in Smalltalk or Lisp was just heaven compared to when we had to drop down and do anything else. There were not many things to compare MVC *to*, in order to have any perspective that it may be "weird" or "too complicated". It just wasn't, and is still preferable to 87 percent of everything else.

Weird Jobs

Dominique Boucher on programming jobs in Montreal, but I would suppose the same is true in a handful of North American cities...

Great programmers are not looking for jobs. They already have one. And they don't want to switch from one Java job to another, unless they are dissatisfied with other aspects of their job. But a fraction of them would easily consider another job if it involved Scheme, Lisp or Erlang programming (or other non-mainstream languages like OCaml, Prolog, Haskell, etc.).

So I claim that it is easier to recruit Scheme, Lisp, or Erlang programmers, even in Montreal, than Java/C# programmers.

Programming Collective Intelligence

This new book on Programming Collective Intelligence looks really interesting. I missed the author's session at OSCON few weeks back. Here's the presentation in pdf.

Anyway...

Toby Segaran's new book, Programming Collective Intelligence, teaches algorithms and techniques for extracting meaning from data, including user data. This is the programmer's toolbox for Web 2.0. It's no longer enough to know how to build a database-backed web site. If you want to succeed, you need to know how to mine the data that users are adding, both explicitly and as a side-effect of their activity on your site.

There's been a lot written about Web 2.0 since we first coined the term in 2004, but in many ways, Toby's book is the first practical guide to programming Web 2.0 applications.

Get your map/reduce going. ;-/

Tuesday, August 14, 2007

Weird Computing in Portland

Portland, Oregon has an interesting (and forgotten?) history in concurrent computing. Remember these companies/products?

Not to mention Sequent or Intel's work here on the i432 and the more practical i960.

These were all "weird" for one reason or another back in a time when almost anything new in hardware or software could be considered weird, and almost everything *was* new. I didn't work in any of these companies (well, Intel, later) but I knew at least one person in each of them.

People used to get together at the (weird) Oregon Graduate Center or the Cedar Hills McMenamins or wherever and talk about all these things, not as being weird, just as being the things that were happening around the west side of Portland and Beaverton. The "Silicon Forest".

"Weird" stuff went on in software too. See "The Gem–Stone data management system". I worked with five of the eight authors a decade ago (almost a decade after this paper, which itself was almost a decade after the start of the company, which included several of those authors), and the really interesting thing is, I think all five are still with (one of them "back at") Gemstone.

Now *that* is weird.

ATW

True or false? The 1980s (and earlier) were far more innovative than the 2000s for computer engineering and software development.

Anyone remember the Atari Transputer Workstation?

I'm not sure if the 1980s were more innovative. But it sure seems like there were fewer "rules" back then. That only makes sense.

Funny and Informative

(via Steve Loughran)

This XML Security presentation (pdf) is funny *and* educational.

Weirdnesses

Ironic. Tim Bray chose to offer "Erlang itself? It’s too weird"...

...the same day he chose to offer...

The Methodphitamine

That’s the name of Jay Phillips’ metaprogramming model and his write-up of it... As an example of the apparently infinite richness lurking under Ruby’s hood, it’s mind-boggling and awe-inspiring.

I’m not sure I actually like it.

So is Ruby "too weird"?

I've got nothing against Ruby weirdness. Weirdness has its place. I learned several "weird" languages before I *ever* learned a "normal" curly-braced language.

Luckily. =8-D

The Amazing Gloppita Gloppita Machine

As seen in a comment on Sam Ruby's blog...

There’s still plenty of life and value in SOAP and SOA

Agreed! See, for instance, OASIS forms six committees to simplify SOA. You just don’t see that kind of forward-thinking committee-making from the REST advocates.

:-D

Maybe these six committees can come up with "A Busy Developer's Guide to At Least One Permutation of the WS-I that All Vendors Can Nearly Agree Upon, Given Three More Revs of Their Software".

Flinging It

An anonymous commentator disparages...

Why go on about shared memory? Amdahl's law is the key. Most Erlang nuthuggers haven't even heard of it, let alone understood the consequences.
I'd be interested in reading more about such erlang nuthuggers. References?

Monday, August 13, 2007

Dater

Bill de hÓra:

I think that increased data volumes will impact day to day programing work far more than multicore will. A constant theme in the work I've done in the last few years has been dealing with larger and larger datasets...

Good luck explaining to data professionals and system architects that centralised relational databases are not the right place to start anymore.

Another reason not to care so much where the "core" is as long as you got enough of them, the data close enough at hand, and a programming language to use them easily.

The Multicore Wall

An anonymous comment to my most recent thingy mentioning Erlang says...

Not everyone is buying the Erlang hype.
And the comment links to Steve Dekorte's recent post on "the multi-core wall".

Fair cautions about "Erlang hype" aside, I don't get the point. Erlang does not present a shared-memory programming model. Although Erlang can take advantage of multi-core chips, the model for using Erlang on a multi-core node is no different than for using Erlang on a *multi-node* environment with single-core, dual-core, or multi-core nodes.

Also Steve's note about tight coupling of data and code "aka object-orientation" also applies to Erlang -- an Erlang process is essentially such a coupling, and the interface to that process is the message protocol.

I think Steve's argument is right in line with Erlang. His argument goes more against the systems that have one model for intra-process and another for inter-process computing. C and pthreads, Java and its threads, even Haskell and its Software Transactional Memory fall into the category the will suffer according to Steve's argument.

In any case before a "multi-core" chip gets up to 80 cores the on-chip cache and the memory/bus architecture will have to change to something "less shared" anyway. A lot of those transistors will be taking more of a "multi-system-on-a-chip" flavor. All of which will work in Erlang's favor, or at least won't work against Erlang.

Contrary to the original article linked from Steve's, this doesn't, shouldn't, and won't be a NUMA (Non-Uniform Memory Access) architecture, at least not in the way I understand that term. NUMA defines non-uniform access to a *shared* memory, i.e. all the cores can access all the memory as if it were a single, "uniform" memory. Under the covers some memory is closer to one node than to another. Wrong model!

The "multi-system-on-a-chip" architecture will have independent caches, buses, and memories, but not present this as one shared memory. That would be ludicrous. At least to this barely-hardware-literate programmer.

Freescale, nee Motorola, is heading in that direction with multi-core Power chips with per-core backside caches and Power-based system-on-a-chip-like products with a CPU, a graphics processor, and another "media processor".

Not So Far Off Bets

Sam Ruby's "long bets" don't seem so far off considering how quickly changes are happening on the internets....

So, without further ado, here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field.

By the way, have you seen the erlang "slave" and "pool" libraries? These might not do entirely what you want. Good news: applicable as-is. Even better: they can be (re-)implemented in not-so-much erlang to do entirely what you want.

Maybe its time really has come.

More Gushing

From Erlang Overview

Mnesia is a nice example of the power of Erlang: in how many languages could you write a fully-featured industrial-strength distributed DBMS in less than 20,000 lines of code?

Sunday, August 12, 2007

Bits of Wisdom: HOPL III's History of Erlang

Lots of interesting bits in Joe Armstrong's HOPL III paper on the History of Erlang. The paper is available as a PDF for ACM members or others wanting to purchase just that paper. Not available outside the walled garden of the ACM, that I know of.

Anyway on to just some of the bits I appreciated.

In 1985, when I joined the Lab, SPOTS had finished and DOTS was starting. I asked my boss Bjarne D¨acker what I should do. He just said “solve Ericsson’s software problem.” This seemed to me at the time a quite reasonable request...

We were... lucky in being the first group of people in the company to get our hands on a UNIX operating system, which we ran on the VAX. What we were supposed to do was “to find better ways of programming telephony” (a laudable aim for the members of the computer science lab of a telecommunications company). This we interpreted rather liberally as “program basic telephony in every language that will run on our Unix system and compare the results.” This gave us ample opportunities to a) learn new programming languages, b) play with Unix and c) make the phones ring...

“small languages” were thought desirable:

“Large languages present many problems (in implementation, training etc) and if a small language can describe the application succinctly it will be preferable.”...

My own contribution to LOTS was to program POTS. This I did first in Smalltalk and then in Prolog. This was fairly sensible at the time, since I liberally interpreted Bjarne’s directive to “solve all of Ericsson’s software problems” as “program POTS in Smalltalk.”

(Aside: POTS is Plain Old Telephony System. LOTS is a system supporting Lots of pOTS. On to more bits...)
Erlang began to change rapidly. We now had two people working on the implementation (Robert and myself) and a large user community (three people). We would add features to the language and then try them out on our users. If the users or implementors liked the changes, they stayed in. If the users disliked the changes or if the implementation was ugly, the changes were removed. Amazingly, the fact that the language was changing under their feet almost every day didn’t particularly bother our users. We met our Bollmora users once or twice a week for about six months. We taught them programming, they taught us telephony and both sides learned a lot...

I always considered the morning coffee break to be the key forum where the brilliant ideas you had on the way to work were trashed and where all the real work was done. It was in these daily brainstormings that many a good idea was created. It’s also why nobody can quite remember who thought of what, since everybody involved in the discussions seems to remember that it was they who had the key idea...

In designing Erlang, we wanted to abstract all hardware as reactive objects. Objects should have “process semantics;” in other words, as far as the software was concerned, the only way to interact with hardware was through message passing. When you send a message to a process, there should be no way of knowing if the process was really some hardware device or just another software process. The reason for this was that in order to simplify our programming model, we wanted to model everything as processes and we wanted to communicate with all processes in a uniform manner. From this point of view we wanted software errors to be handled in exactly the same manner as hardware errors. So, for example, if a process died because of a divide by zero it would propagate an {’EXIT’,Pid,divideByZero} signal to all the processes in its link set. If it died because of a hardware error it might propagate an {’EXIT’,Pid,machineFailure} signal to its neighbors. From a programmer’s point of view, there would no difference in how these signals were handled.

The average increase in productivity was a factor of 8. This factor and the conclusion of the report were highly controversial and many theories were advanced to explain away the results. It seemed at the time that people disliked the idea that the effect could be due to having a better programming language, preferring to believe that it was due to some “smart programmer effect.” Eventually we downgraded the factor to a mere 3 because is sounded more credible than 8. The factor 3 was totally arbitrary, chosen to be sufficiently high to be impressive and sufficiently low to be believable. In any case, it was significantly greater than one, no matter how you measured and no matter how you explained the facts away...

1989 also provided us with one of our first opportunities to present Erlang to the world outside Ericsson. This was when we presented a paper at the SETSS conference in Bournemouth. This conference was interesting not so much for the paper but for the discussions we had in the meetings and for the contacts we made with people from Bellcore. It was during this conference that we realised that the work we were doing on Erlang was very different from a lot of mainstream work in telecommunications programming. Our major concern at the time was with detecting and recovering from errors. I remember Mike, Robert and I having great fun asking the same question over and over again: “what happens if it fails?”— the answer we got was almost always a variant on “our model assumes no failures.”We seemed to be the only people in the world designing a system that could recover from software failures...

I started writing the emulator myself in C but soon Mike interfered and started making rude comments about my code. I hadn’t written much C before and my idea of writing C was to close my eyes and pretend it was FORTRAN. Mike soon took over the emulator, threw away all my code and started again. Now the Erlang implementor group had expanded to three, Mike, Robert and myself. Mike wrote the inner loop of the emulator very carefully, since he cared about the efficiency of the critical opcodes used for concurrent operations. He would compile the emulator, then stare at the generated assembler code, then change the code compile again, and stare at the code until he was happy. I remember him working for several days to get message sending just right. When the generated code got down to six instructions he gave up...

The AXD301 was a spectacular success. As of 2001, it had 1.13 million lines of Erlang code contained in 2248 modules. If we conservatively estimate that one line of Erlang would correspond to say five lines of C, this corresponds to a C system with over six million lines of code. As regards reliability, the AXD301 has an observed nine-nines reliability —and a four-fold increase in productivity was observed for the development process...

Just when we thought everything was going well, in 1998, Erlang was banned within Ericsson Radio AB (ERA) for new product development. This ban was the second most significant event in the history of Erlang: It led indirectly to Open Source Erlang and was the main reason why Erlang started spreading outside Ericsson...

...projects that were already using Erlang were allowed to continue but had to make a plan as to how dependence upon Erlang could be eliminated. Although the ban was only within ERA, the damage was done. The ban was supported by the Ericsson technical directorate and flying the Erlang flag was thereafter not favored by middle management...

Since we had spent the last ten years designing and building fault-tolerant telecoms devices, we turned our attention to Internet devices, and our first product was a fault-tolerant e-mail server called the mail robustifier. Architecturally this device has all the characteristics of a switching system: large numbers of connections, fault-tolerant service, ability to remove and add nodes with no loss of service. Given that the Bluetail system was programmed by most of the people who had designed and implemented the Erlang and OTP systems, the project was rapidly completed and had sold its first system within six months of the formation of the company...

The plans within Ericsson to wean existing projects off Erlang did not materialise and Erlang is slowly winning ground due to a form of software Darwinism. Erlang projects are being delivered on time and within budget, and the managers of the Erlang projects are reluctant to make any changes to functioning and tested software.

The usual survival strategy within Ericsson during this time period was to call Erlang something else. Erlang had been banned but OTP hadn’t. So for a while no new projects using Erlang were started, but it was OK to use OTP. Then questions about OTP were asked: “Isn’t OTP just a load of Erlang libraries?”—and so it became “Engine,” and so on.

After 2002 some of the surviving Bluetail members who moved to Nortel left and started a number of 2nd-generation companies, including Tail-F, Kreditor and Synapse. All are based in the Stockholm region and are thriving.

Outside Sweden the spread of Erlang has been equally exciting. In the UK, an ex-student of mine started Erlang Consulting, which hires out Erlang consultants to industry. In France, Processone makes web stress-testing equipment and instant-messaging solutions. In South Africa, Erlang Financial Systems makes banking software. All these external developments were spontaneous. Interested users had discovered Erlang, installed the open-source release and started programming. Most of this community is held together by the Erlang mailing list, which has thousands of members and is very active. There is a yearly conference in Stockholm that is always well attended.

Recently, Erlang servers have begun to find their way into highvolume Internet applications. Jabber.org has adopted the ejabberd instant messaging server, which is written in Erlang and supported by Process-one.

The ban within Ericsson ERA was apparently a power struggle, with the side in favor of the ban promoting popular languages like C++ and Java, and "off the shelf" components. The results are speaking for themselves now, with Joe Armstrong back at Ericsson, and Erlang thriving in more of their products.

Luke Gorrie wrote of this a couple months ago in LtU...

I'm not an Ericsson insider but I can tell you that this is old history from when C++/Java/UML were hyped towards executives. Today Erlang is bigger than ever within Ericsson and they're shipping major new products on it. They even managed to hire Joe Armstrong back.
Joe Armstrong wrote of this about a year ago on the erlang list...
In 2004 I rejoined Ericsson, after 6 years, working in start-ups and research.

Had things changed? - Yes

Had the ban (which caused us to leave) worked? - No.

"Was Erlang still banned?" - I asked, "Don't ask, just use it", they said...

Ericsson has no corporate policy, regarding Erlang.

Corporate policy is way more abstract than talking about individual technologies - nobody in above middle management knows how a phone works...

We (Ericsson) have a number of products written in Erlang - these earn stuff called MONEY...

We (and this includes me) are developing "secret-project-number-1" and "secret-project-number-2" etc. these we hope will one day earn MONEY

Why Ask Why?

From http://www.dailysouthtown.com

What if you or I could secretly commit crimes against our fellow citizens, bury the evidence of the crime by stamping it "TOP SECRET," refuse to answer questions when we are accused of committing the crime, and then, before we can be prosecuted for the crime, we can make a law that says the crime we committed is no longer a crime. And then call ourselves heroes.

Welcome to the New America...

There will be no examining of the individuals being spied upon, to decide if the surveillance is reasonable. Director of National Intelligence Mike McConnell called it "modernizing" FISA, and graciously submitted to post-surveillance "reviews."

McConnell assures us the new law's targets will be foreigners, not Americans.

So, relax. You can trust the Administration of the Freely Reigning Executive never to abuse or stretch the limits of its power. Or, you can stay off the phone with your friends overseas.

An anonymous commenter wonders what I have to worry about, if I've done nothing wrong. Why, they probably don't want to listen to my phone calls anyway. The point of the comment is allocating new cell numbers, etc. happens faster than FISA warrants can be granted.

Well, there have long been scenarios where an eves dropping had to occur more quickly than a FISA warrant could be obtained. And so, predating even Bush's presidency, FISA warrants have been granted ex post facto.

An investigation is allowed to occur and then the FISA review is performed as a check-and-balance on the executive branch. This is *critical* to a democracy, and not just to me making calls to my Aunt Trudy.

RTGGC

Recently see at LtU...

We have developed a fully incremental, real-time generational collector based on a tri-partite nursery, which partitions the nursery into regions that are being allocated, collected, and promoted. Nursery collections are incremental, and can occur within any phase of a mature collection.

We present the design, mathematical model, and implementation of our collector in IBM's production Real-time Java virtual machine, and show both analytically and experimentally that the collector achieves real-time bounds comparable to a non-generational Metronome-style collector, while cutting memory consumption and total execution times by as much as 44% and 24% respectively.

Saturday, August 11, 2007

On Pattern Matching

An aspect of Erlang that is often mentioned but seldom highlighted, and fairly unrecognized for its contribution is pattern matching. Languages implementors that wish to achieve Erlang-like concurrency in their own language's runtime will also have to come to terms with Erlang's simple message selection mechanism based on pattern matching.

Again this is where an implementation like Termite, based on Lisp (Scheme) can work as well as Erlang. Other languages not so much, but some creative use of syntax and meta-programming in Smalltalk, Python, and Ruby might do the job.

Other languages not so much. Especially those modern curly braced ones, which will likely have pattern matching piled-on in their next set of features, this time to seem more Erlang-like. Either Java or C# will add this first, then the other language implementors will be compelled to meet or exceed the first.

Either way, they've all got a long way to go. I'd bet on several Lisps and on Smalltalk to keep up most easily.

On Sequential Languages and Concurrency

Ralph Johnson wrote about Erlang this week, taking multiple angles worth reading, "Erlang, the next Java". One of them being how difficult it may be to update other sequential languages to Erlang's level of support for concurrency and distribution. Another being the relative importance (or not) of Erlang's sequential constructs being mostly functional.

Joe makes too much of functional programming because he says that lack of mutable state implies no locks. However, it is really lack of SHARED state that implies no locks. You could write processes in Basic, perl, or C. I'm sure that lots of people will look at Erlang and say "we can add that to our language". In my opinion, it is the concurrent programming aspects of Erlang that make it special, along with its mature implementation and powerful library designed for concurrency and reliability.

I do not believe that other languages can catch up with Erlang anytime soon. It will be easy for them to add language features to be like Erlang. It will take a long time for them to build such a high-quality VM and the mature libraries for concurrency and reliability. So, Erlang is poised for success. If you want to build a multicore application in the next few years, you should look at Erlang.

The best candidate runtime in my opinion is Gambit Scheme. Gambit's already been used to achieve Erlang-like levels of concurrent threads, it's been used to implement an Erlang compiler, and it's been used to implement Termite a mostly-functional Scheme-like language with many Erlang-like concurrency features. (A point I've written about several times.)

At one point I wrote "parsers" for very small subset of Ruby and of Javascript. So small I need to use quotes. The parse trees were simply lists in Scheme ("s-expressions") and then some simple macros and functions to turn those trees into executable Scheme s-expressions. Since Gambit generates native code by way of compiling to C and it's runtime is compiled efficiently to native code, this approach essentially results in, for example, a Ruby-to-Gambit-to-C-to-Native code compiler.

I am convinced this approach would work well for "real" development, allowing the various language translators to run interpreted and compiled, just as Gambit itself is. Moreover, the translators could support sequential, shared-nothing implementations of various languages, relying on Gambit's threads and mailboxes to implement concurrent Erlang-like processes with asynchronous message passing among multiple languages running in the same Gambit OS process.

But then there's the rub. Ralph writes, "it is the concurrent programming aspects of Erlang that make it special".

This does make it special, but it's the simple, mostly-functional sequential aspects of Erlang that make it work so well. As soon as the sequential language is one with assignment and mutable memory, several unnecessary "issues" have to be dealt with. Even though the language is defining a shared-nothing, single-threaded process, these new issues overtake the simplicity of the concurrent message passing.

For example, what about "identity"? What about mutable lists, not to mention mutable, large object graphs? Erlang can play some tricks under the covers when "passing" immutable data among lightweight processes in the same OS process, potentially even in shared-memory among nodes on the same "physical" memory.

So a mutable sequential language gums up the concepts for the application programmer and gums up the mechanisms for the systems programmer. Javaspaces handles this fairly well for Java by keeping the mechanisms simple, yet the rules and the mechanisms (and copying) are significantly more complex and in the way of application developers. (Also pattern matching in Java is just cumbersome and not so nice to look at.)

These more "traditional" imperative languages (with or without "objects") were not designed for Erlang-like concurrency and are simply not as good a fit. Termite recognizes this and so provides a simpler, more-functional Scheme than Scheme R5RS.

Joe Armstrong writes in his HOPL III presentation (pdf):

Robert and I were convinced that one day we would have to add destructive operations to the language, but that we would wait until a problem that could not be solved with pure operations turned up.

This never happened.

Erlang is special because its combination of sequential and concurrent features combine so well. Most languages have piled sequential feature on sequential feature. As Ralph Johnson notes:
Unlike Java or Smalltalk, where you only write threads/processes when you want concurrency, Erlang programmers use processes for modularity, reliability, and reuse. Then they get concurrency for free.

San Francisco "Erlang Lounge" at Thoughtworks Office

Ryan Tecco posted the following to the erlang mail list...

The San Francisco Bay Area ErlLounge will be held on Wednesday, August 15th at 7:00 at the Thoughtworks office (410 Townsend St.) in downtown San Francisco. Thoughtworks is less than block away from the 4th and King Caltrain station for those who might be coming up from the South Bay.

Pizza and beer will be provided as well as wi-fi and whiteboards, so bring your laptop if you are so inclined.

RSVP with me off-list so that I can get a rough head count.

Cool.

Erlang at History of Programming Languages III

Here is the PDF from Joe Armstrong's talk (n.b. it's a PDF) at the recent ACM History of Programming Languages III event.

What is Erlang?

  • Concurrent (processes belong to Language – NOT OS)
  • Very light-weight concurrency (lighter than threads)
  • “Share nothing” process semantics
  • Pure asynchronous message passing
  • Core language is a simple dynamically typed FPL
  • Non-pure extensions (ets) for implementing databases.
  • Mechanisms for in-service code upgrade
  • Large set of libraries (OTP)(Unix <-> C <==> OTP <-> Erlang)

What Rails (and the Web) Did

Expanding on a reply I just wrote to a comment on last night's Erlang post...

What Ruby and especially Rails did, though, is break IT free of the curly braces sociology. Used to be languages that did not resemble C would get skewed looks. When they'd receive attention they would be cast as odd-ball curiosities, far from viable in the mainstream.

Just think of all those Lisp and Smalltalk pieces in Dr. Dobbs and Byte over the years.

More generally than Ruby and Rails, I guess, is that the *web* did this. The web, being a large, dynamic system, demanded more than the traditional mainstream could supply, having been designed primarily for small, single-user systems that don't actually do all that much.

Friday, August 10, 2007

Categories and Systems

Probably early humans benefited more from thinking in terms of categories than in terms of systems. "Is that food, or not?" and "Is that my friend, or not?" being two important categorizations.

And so we still seem to define categories and compartmentalize more than we make connections and think about systems, let alone "systems of systems".

The "interesting" events in the financial world are an example of categorizing more than systematizing. Many institutions have been playing the game of "subprime" lending for years. The way these games are presented is in terms of "markets" where a market is treated more as a category than as what it really is: a system. And the relationships *between* markets is repeatedly overlooked. The Japanese financial crisis of a decade ago or so hit Portland, Oregon somewhat hard, but only after the local business analysts declared the result would be otherwise because Japan is "over there" and Portland is "over here".

For quite a while now the headlines have been presenting the problems with subprime loans and defaults on them. The subprime market (category) was in trouble. "No problem. So what if some low-wage earners can't pay their debts and some lower-tier lenders take a bath? I'm not in that category."

Recently the problems secondary effects on other markets have been presented as problems of "confidence". That's probably true, since all markets are ultimately based on confidence. But that's not the real problem, since all markets are ultimately related, and in many cases far more closely related than the institutions would want investors to believe.

"Our current system of levered finance and its related structures may be critically flawed..." Uh-huh. From the International Herald Tribune...

The result has been a freezing up of markets for many securities that, it turns out, were critical to the free flowing of credit in recent years.

"Our current system of levered finance and its related structures may be critically flawed," said Bill Gross, the chief investment officer of Pimco, a mutual fund company. "Nothing within it allows for the hedging of liquidity risk, and that is the problem at the moment."

The basis of the system has been a belief that securities backed by bad credits could be very safe - so long as there were other securities that would suffer the first losses that came from defaults in pools of subprime mortgages, or of loans to highly leveraged companies.

Even the people playing the system are finding out they've been playing a misconception of the true system. The true crisis of confidence is now about finding out what the true system is, and how it works, in order to find some solid ground for building up confidence. No confidence: no credit. No credit: no business.

One of the bases of confidence has been the credit rating system. That turns out to be based on a system that does not truly exist. Or at least not in the form used to establish the bases.

"The complete evaporation of liquidity in certain market segments of the U.S. securitization market has made it impossible to value certain assets fairly, regardless of their quality or credit rating," the French bank said.

Added to the problem is that the questionable securities now are widely owned, and sometimes have been repackaged to form the basis of other securities.

Gross compared the problem confronting investors to a game of " 'Where's Waldo' - Waldo being the bad loans and defaulting subprime paper."

Suddenly, some fear Waldo is everywhere. European banks and funds own paper tied to subprime mortgages, and it is not clear who else does, or how investors will react.

"You have to believe that in the hedge fund and mutual fund complexes, there is a decision that is building that says, 'I want to hold some Treasuries to have a cushion if I see redemptions,' " said Robert Barbera, chief economist of ITG.

We need better tools and more awareness of the systems we live in. This crisis is a problem due to lack of systems thinking. We've enjoyed the credit ride fueling the economy for the last seven years or so, flying high, smooth sailing.

Meanwhile, hold on. Monday could get a bit bumpy, and there could be a fair bit of turbulence ahead during the search for solid ground. And we may be running out of gas.

If the current panic is just that - unreasoning fear - then... cash infusions may be able to let the new financial system weather the storm. Money can be lent to those owning the dubious securities, obviating the need for them to sell them. As they eventually turn out to be good, the loans can be repaid and all will be happy.

On the other hand, if many of those securities turn out to be as bad as people now fear, some of those loans will not be good, and there may be more financial failures.

But the central banks still confront significant challenges. The new financial system, with its credit expansion through securitization, made it possible for questionable borrowers to keep borrowing at very low rates even as the Fed was tightening.

Now, the combination of market reaction and new regulations on mortgage lending have drastically tightened credit on many borrowers...

The new financial system is not the one the Fed was created to deal with, but it is the one it must try to handle.

Dive Into Erlang?!

Wow. Are things hopping in the world of Erlang, or what? Several high-profile people have blogged about recent explorations. Also just strolling through del.icio.us turns up all kinds of interesting bits. Like this from Dive Into Erlang ("A Rubyist dabbles in today's most exciting programming language"!)...

I felt naturally comfortable with the Erlang way of doing things. This is how I've been writing programs all along. It's feels so nice to finally find a language that abstracts away all the complex behaviors of concurrent network processing. Furthermore, distributed Erlang and the OTP framework are beyond my wildest dreams in terms of what you can build once the underlying problems are all abstracted away.

Now I can finally stop trying to build an ad hoc, informally-specified, bug-ridden framework, and start focusing on what I've actually cared about all along: the function.

I would qualify that "underlying problems are all abstracted away" by pointing out the problems are still there, and you still have to deal with them. But OTP provides convenient ways to deal with them more easily, and the Erlang literature explains the problems and the solutions well.

But what's happening? In the last six months or so HTTP overthrows WS-Deathstar far more rapidly than at least I imagined and now Erlang is basking in far more sunshine than I imagined would appear over the next several years.

Friday, August 03, 2007

X

Fri, 5 Feb 88 on NeWS-makers@brillig.umd.edu...

The astonishing baroqueness of X is the greatest threat to the general success of UNIX to have come along since System V hit the streets.

Thursday, August 02, 2007

Speckers

Peter Saint-Andre knows...

Perhaps we should force spec writers to either write code or deploy services.
Oh and Peter also gave a helluva session at OSCON on security and jabber/xmpp.

Wednesday, August 01, 2007

Not To Mention

An underlying, unintentional, yet pervasive message at OSCON this year is this: while the web server is a proven platform for building applications, the web *browser* is a horrible platform for building applications. Browsers have a tough row to hoe to get where they need to be. The huge advantage they have is cultural: programming applications by default are assumed to be best done on a browser, especially "cross browser", no matter what pain is involved.

Please don't hurt the web! Use a productive client.

Two things are going to push browsers (maybe kicking and screaming) into the 21st century web: Flex, (which *is* open and so could show up in Firefox someday) and AtomPub.

The combination of those could be significant.

Coding Faster, Pussycat!

I could not agree more with Dan Creswell when he writes...

Every decent software engineer knows that actually you want less code.
Yet I've seen this get turned into a desire for tools that implement systems "without coding". Unfortunately those tools often ignore the benefits of text-based code such as testability, maintainability, flexible automation for deployment, and so on.

So I definitely want less code, while still wanting "code". :-)

Tuesday, July 31, 2007

Fallout

Joe Gregario on the N = 1 problem...

While not everybody needs BigTable today, more and more people will over time. The sooner we start building a common understanding of how to program against such a model the better off we'll be.
Joe also gave a helluva good presentation on AtomPub at OSCON last week.

Routing

Tim Bray wisely instructs...

Even if you’re living on one computer right now, it might be smart to write your integration pretending that you’re not, so that when the load cranks up, you can scale out.
I saw Atanu Ghosh talk about the XORP router project at OSCON last week. This is exactly the approach they've taken, and have been able to move components out to multiple machines. Not exactly intuitive for a router architecture, but a wise choice generally as Tim says.

AtomPub

Bill de hÓra writes...

Atom Protocol. Is nearly done. Even though I'm a co-editor, and hence have some bias, this one will be fun to watch. AtomPub sits in a very strange place, as it has the potential to disrupt half a dozen or more industry sectors, such as, Enterprise Content Management, Blogging, Digital/Desktop Publishing and Archiving, Mobile Web, EAI/WS-* messaging, Social Networks, Online Productivity tools. As interesting as the adoption rates, will be people and sectors finding reasons not use it to protect distribution channels and data lockins with more complicated solutions. Any kind of data garden is fair game for AtomPub to rationalize.
Congratulations. Way back several years ago as a shooting-from-the-hip off-to-the side observer I thought the Atom effort would just add confusion to the "syndication" domain at a time that RSS, feeds, blogs, etc. were gaining some visibility in the enterprise. This was a great effort, and a great vision, and I think I kind of "get it" now!

Sunday, July 29, 2007

Swing and a Miss

I'm watching the Godfather and just came across a huge blooper. Sonny beats up his sister's husband in response to the husband beating the sister. A few swings into the beating though, Sonny clearly swings and misses but the brother-in-law flings his head as if contact was made.

Wild. I played Tivo back and forth in freeze frame to make sure of what I saw fly by the first time. Sure enough, this is a known blooper.

Now I don't know how I missed that so many times before.

Saturday, July 28, 2007

Erlang Style

Joe Armstrong's Programming Erlang book was featured at the Pragmatic Bookshelf booth at OSCON last week. The banner covering the back of the booth was simply the cover of the book itself. They said the book has been selling very well.

I hosted a BOF on Monday evening. The slot was assigned, and not the best, I thought, since that was the first tutorial night. As it turned out about 20 people showed up, so I wonder how many may have been there on a Tuesday or even better, a Wednesday.

A handful of the attendees had tried Erlang to some extent. Everyone had an inkling of what it is about, and wanted to find out more. So we turned the hour into a quick tour of what I consider the features people should see first if they're coming from the more common languages at OSCON (i.e. the "scripting" languages, Java, C++, C).

I had Emacs up on the screen with "erl", the Erlang expression evaluator, and a few interesting source files. I also had Firefox with some tabs browsing the extensive Erlang/OTP documentation. Here's how it went down:

Roughly 30 minutes on the sequential aspects of Erlang. Really just a few essentials:

  • Some data types: numbers, symbols, strings, lists, and tuples. (Distinguishing the last two had a bump -- I'd not really thought about explaining that!) I did not bother to explain records. Although they're simple in Erlang, they do need a good bit more explanation. (I'd hoped to avoid the point that strings are just lists of characters, but that came up in a question. And I certainly did not mention "binaries".)
  • Variables begin with a capital letter (latin1) and are "single assignment". (That took a few minutes to demo and respond to clarifying questions.)
  • Variables are bound through pattern matching. A simple assignment statement is actually just the simplest form of binding through pattern matching. (Code some examples into the evaluator. Then I made a mistake: I demo'd the evaluator's f() command to forget one or all current bindings -- this has nothing to do with Erlang and so I had to unwind a bit.)
  • Functions are defined by one or more clauses, and pattern matching is used to select a clause when the function is applied to arguments.
  • Recursion (and tail recursion), as there are no mutable variables and so no "loops" per se.
That was it, and my 30 minutes for sequential Erlang were up. I made it clear there's a lot more to sequential Erlang than that. The timing worked out pretty well though. I had not intended on explaining more about sequential Erlang. This was enough to read my code for concurrent Erlang.

The last half of the hour was spent on concurrent processes, message sending, and message receiving (again, via pattern matching clauses). No supervisors, no linking, no nothing but the simplest examples of spawn, send, and receive.

The first concurrent example was an rpc because people know it, and programming it in Erlang is trivial, *but* coding it in Erlang highlights that it *has* to be coded. Erlang messages are asynchronous, fire-and-forget, and the code for rpc makes that explicit.

Finally I demo'd loading updated code into a running process. This is easy to show and I thought people using languages that do not define such a thing or that define such a thing using horribly complex mechanisms would be impressed. Seemed so.

Given the response to the BOF, I suggested on the Erlang list that someone should provide a half-day tutorial next year.

Wiki Style

Ward Cunningham, being interviewed in last last Friday's Oregonian (the daily Portland paper)...

I think the word "wiki" has become a term that describes a style of working, not a particular technology, and I think that's fantastic, because we've been waiting for that style of work for a long time.

Friday, July 20, 2007

Simplicity

Joe Armstrong in a DDJ interview...

Some pretty fast-moving startups in the financial world have latched onto Erlang; for example, the Swedish www.kreditor.se. Erlang gives them a great commercial advantage over their competitors.

Thursday, July 19, 2007

Scalable, fault-tolerant, upgradable: Pick three

Joe Armstrong on scalable, fault-tolerant, and upgradable...

A system that is fault-tolerant can easily be made scalable and easily made so that we can do in-service upgrade.

http://www.random.org/

http://www.random.org/

Wednesday, July 18, 2007

Best Places

Money Magazine has Sherwood, Oregon, in its Top 20 Best Places to Live. Sherwood is a bedroom community about ten miles outside Portland.

Sherwood seems kind of the typical suburb to me. What makes Sherwood nicer than most is being in Oregon and being near Portland. Why not just put Portland on the list? Or if suburbs are their ideal, make Sherwood's #18 slot a list of Portland suburbs.

Oh, Money has the numbers that show how they put Sherwood on their list.

Speaking of numbers, I heard a good one recently, it goes something like this: the average person in Sherwood, Oregon, has one testicle.

Friday, July 13, 2007

Fresh Air

Fuzzy's take on AIR -- see my previous post on collaboration. I think AIR will play a *big* role in this.

Collaborative Systems

Tim O'Reilly re: an upcoming OSCON session...

I've been thinking lately just how much software developers take the existence of version control for granted, and how... web 2.0 applications don't offer much in the way of version control functionality...

The future we face is one of massive collaborative systems. How we design those systems, and how we build critical freedoms into them, shaping their architecture to support either participation or centralized control, is one of the great challenges facing the technology community today.

I worked on conferencing software for a couple two, three years in the early 1990s. There was a lot of expectation then that collaboration would find its way into every "single-user application" on the desktop. Then the web hit the scene and eventually evolved its own ideas about collaboration, or at least participation.

Other than a few notable examples there is still surprisingly little really good collaboration on the web. I'm not even sure what that is. Maybe it does exist and I could collaborate with you to find that out.

Wikis for me remain a great example, but still real collaboration is hard. Wikis have a way of devolving into conversation-like- and ownership-like-models for pages.

I expect by Web 2.5 or Web 3.0 we'll see collaborative systems more like where we were heading in the early 1990s but with a heavy dose of "the web" guiding everything for an even better multiplying effect.

Thursday, July 12, 2007

Wii: At It Again

Nintendo keeps moving forward. No big red buttons. Mario Kart for the Wii will almost certainly be my new favorite.

The Big Bopper

Wednesday, July 11, 2007

Exploratory Coding

In a dynamic language I can modify a small bit of code and run just enough tests to try those changes. Then I can progressively run more tests and fix those that are broken because of my changes.

Is there a way in Haskell, or Scala for that matter, or OCaml, to "suspend" checking on things that are "already typed" in order to do something similar?

Another way of looking at this is it is "exploratory programming" -- I may break all kinds of things I don't care about as long as I can fix them incrementally as my explorations settle out.

i.e. I don't want to tell the type checker something should be typed ∀α.α. I just want the type checker to allow me to work on one small things even though I may have broken type checking for a lot of code I am not worried about at the moment.

Push The Big Red Button. Yes, *That* One.

From the Seattle Post-Intelligencer...

Microsoft Corp. is turning to an oversized red button in its latest bid to broaden the appeal of its Xbox 360 video-game console.

The company announced plans Tuesday to introduce an alternative Xbox 360 controller, featuring a large button in the style of a game-show buzzer, meant to be less intimidating to new gamers...

"It's super-easy to use," said Shane Kim, the corporate vice president in charge of Microsoft Game Studios...

The controller, dubbed the "Big Button Pad," won't be sold on its own initially, and it's not expected to supplant the regular Xbox 360 controller. But Microsoft hopes more game developers will make use of it. The company showed versions with large buttons in different colors, not just red...

"We're certainly not feeling any pressure to react to anything that Sony has done," Kim said.

Tuesday, July 10, 2007

Elementary

Some things the primary public education system in the U.S. hardly addresses but should, not to mention graduate and undergraduate business schools:

And some others I'll think of later. Oh, and memory tricks.

Seaside

Well I went to the beach for a few days, but that's not what this is about. Here's what this is about: Cincom is going to be emphasizing, supporting, contributing to, etc. Seaside for their Smalltalk. That's a great move, and right down the middle of how open source works.

Cycle Time, Value Streams, and Organizational Whitespace

I taught and coached agile software development a lot over the last many years. A common question was "What about metrics? I need an agile that supports metrics. Our organization does metrics. Or will." Often the people asking the question had little if any understanding of "metrics". Often they thought that "metrics" (the kind in "quotes") must be really complicated, and so this agile thing where you cheat and cut corners certainly must not "do metrics".

Often the people asking the question were asking because *their* managers, QA team, whoever were telling *them* or asking *them* about "metrics". Often neither group of people had much of an idea of what "metrics" are, not to mention which are valuable or how to collect them. But since the term is spelled "metrics" (the kind in "quotes") they must be really complicated, and so "important".

My response (after asking them what kind of "metrics" they are currently gathering, how do they use them, and have they seen improvement from that effort, *and* after finding out, no, there is little they collect, less they use, and zero improvement), my response after all that is that an "agile" approach to "metrics" is like an "agile" approach to *everything* -- try to make consious decisions, try to have an idea of what to expect, and try to do it in small, measurable(!) steps so as to have a hope of making any sense of it.

Elaborating, I would explain that "cycle time" to "get business value into production" is a really good measurement for an organization, but that cycle time is *the* most difficult to improve in any significant way. (Here is where we would spend less than an hour doing a *really* simple, quick-and-dirty "value stream map" in order to start thinking about how to measure cycle time.)

Beyond, or even before, measuring cycle time in any detailed manner, just thinking for an hour about your "value stream" and roughly where time goes, and whether that time should be counted as "waste" or "value" is exceedingly useful for a team. In fact the activity can help a team understand who is (or should be, or could be) "on" the team, what changes are within the power of the currently defined team to make, what changes will be more difficult because they go beyond the purview of "the team" per se, and so on.

The other challenge is that measuring cycle time assumes the value being added is the highest-priority value (or as close to that as possible) for the organization. Before spending a lot of time measuring cycle time, or anything else for that matter, a useful excercise is to get a quick survey across the people and organizations in the value stream as to their awareness and consensus on value priorities and decisions. If these people and organizations are not "aligned" (and they typically are not) there will be mixed priorities, misunderstandings, and so delays and failures.

How do these organitions make decisions? If they actually do make decisions together, are they accountable (metrics?) in any way to uphold those decisions?

Surprisingly (or not if you've been around as long as I have in several organizations of various sizes), organizations are emphatically *not* designed for effectiveness if the measurement (!) is getting prioritized business value into production as soon as possible (and keep it there correctly). How is your organization "designed" if that term could be used at all?

I've participated in some significant "re-orgs" and I can say with certainty they are rarely "designed" for or from any such measurements. Based on the reasoning(?) and politic'ing I've seen in "re-org" meetings and smoke-filled back rooms and hallways, an argument could be made that the opposite is true: organizations are typically designed to *impede* progress.

Sorry, that's the way it is. If you're organization has figured out how to "manage the whitespace in the organization chart" you have a *keeper*. Organizations are "systems" and attention has to be paid to what are the goals of the organization and whether the organization is "aligned" to those goals and whether the "system" is designed to effectively address those goals and whether they have the fairly simple-yet-seemingly-impossible-to-apply tools (like simple "metrics") to continuously improve toward those goals.

It's a system. Apply the universal laws of systems or ignore them at your peril. I'm done.

Incremental Development

Bill Venner's asks...

Do you think type inference will change the dynamics of the static versus dynamic typing debate?
For some people, yes. But not (yet?) for me.

I do not see dynamic languages as only "saving key strokes". Dynamic languages for me also save the cycle time from a small idea to its incarnation as running code.

The languages like Scala and Haskell that I have tried, to the extent I have tried them, do save me key strokes. I have not crossed over the hurdle to where they save me cycle time to running code, for a few reasons:

  • Running small snippets of code, especially code that I have changed out of a larger body, is easier for me in dynamic languages. Those type inferencers still want to infer everything and seem to have low tolerance for incomplete thoughts.
  • Scenarios that are fairly easy for me to envision in a dynamic language, functional or imperative, tend to involve various type theories that I know little about. The literature is still not very good for programmers new to the modern type inferencing languages and modern type theory. My sense is picking this up by pairing with someone already imbued with "type-first" programming would be fairly easy, much easier than picking it up solo with the available beginner's books and web resources.
  • Test-first programming has been done for a long time in dynamic language cultures. This pre-dates Kent Beck's Smalltalk sunit library by a couple of decades. The Lisp read-eval-print loop and the Smalltalk workspace have been the instruments for hypothesizing how some code should work, and then working it for a long time. xunit tools, Fit, etc. are somewhat more formal frameworks for the dynamic way or programming - writing a bit of code with a test, capturing the transcript, and repeating that every so often. Good testing is necessary to be successful with any programming language, and I can go fairly quickly with a simple language that stays out of my way, and a reasonable test framework for capturing and repeating many small theories of how the code should work.
If I had to make a prediction, I would not see type inference have much significance in programming over the next five years. Beyond that I think better analysis tools and more formal methods will have a greater influence over programming, but I am not the one to predict whether the current static inference tools will play much of a role in that evolution.

If anything I predict the current static inferencing tools to drive more programmers to dynamic languages *because* they want the simplicity of better languages than the Java-like ones but they suffer too much from type inferencing and various type theories for languages like Scala and Haskell.

Mono-a-Mono

(My creative titling really is suspect this time.)

Anyway, here's a quote from the Bonjour (Zeroconf) email list regarding the Mono Zeroconf libraries and the "official" dotnet...

I've seen the Mono Zeroconf implementation but since I'm not using mono, I'm using full-on .NET, I don't think licensing would allow me to mix and match that stuff without getting into trouble.
Huh? There is something in the "official" dotnet product license that prohibits the use of software developed for Mono???

If this is true, then how sad. If this is not true, then MSFT really goofed with their FUD to the point of causing this confusion. I suspect the former.

I'm not sure which is the more sad scenario!

Thursday, July 05, 2007

The Multicast Internets

Ian Cartwright has a post on rest, in particular http, not being the answer to all your problems. He touches on some alternatives (no, not WS-*!), but another post from April is interesting along the same lines: he wonders about reviving multicast on the internet, not just on a subnet.

Which led to an interesting comment by Nat Pryce, that there are various internet multicast protocols, but anyway here's the interesting bits with some links included...

Also, it turns out that it is easier to implement internet scale publish/subscribe event dissemination using an overlay network of reliable unicast links between routers and only use link-level multicast for the last hop, if at all. Have a look at Elvin, Avis and Siena, for example.
Update: Good comments, and Nat provided the Avis link.

Wednesday, July 04, 2007

Beaver Now Bosox

Two of my favorite teams: the OSU Beavers and the Boston Red Sox now have someone in common: Jacoby Ellsbury. He was called up from Pawtucket to cover for an injury. He may be difficult to send back down.

Watch him score from second on a wild pitch (video on this page).

What was that?

That was quite likely the fastest player every to wear a Red Sox uniform. The Sox have clocked him going from home to first in 3.9 seconds, the kind of time usually associated with speeding bullets like Ichiro Suzuki.

Before last night’s Red Sox win over Texas, Ellsbury spoke matter-of-factly about his eye-popping speed.

“It gets me on base,” he said. “Infielders have a tendency to rush their throws.”

Making his third start last night, subbing for the injured Coco Crisp, Ellsbury again electrified Fenway.

He notched his second major-league hit, similar to his first, in the third inning. Hitting a chopper between the mound and first, Ellsbury sped toward first as second baseman Desi Relaford and pitcher Brandon McCarthy converged, fully aware of who was running and the need to get the ball to first as quickly as possible.

It didn’t matter as Ellsbury reached safely.

After another single to right in the fourth, his first out of the infield, Ellsbury put on his purest display of speed yet. He stole second for another major-league first, then broke from the bag when McCarthy skipped a wild pitch past catcher Gerald Laird.

When Ellsbury saw that the ball had rolled toward the visitors’ dugout, he never slowed as he approached third and seemed to find another gear as he sprinted for home. He finished with an artful hook slide, ultimately unnecessary, as Laird’s throw to McCarthy wasn’t close to being on time.

The crowd of 36,778 stood as one and roared its approval.

Until last week he had the most career hits at OSU. Darwin Barney took that record in the last game of the CWS.

Ellsbury is fast and he also brings that OSU energy to Boston, including his base running, forcing the other team to panic. If he does go back down, it won't be for long, with his speed at least as good as Ichiro's and his skills right up there as well.

"I told him today that I haven't seen it in the big leagues," said Red Sox veteran Eric Hinske. "I don't remember it in the Minor Leagues either. Man, he's fast."
He had a double, an RBI, and scored a run today in the Bosox 7-5 win over Tampa Bay. Keep him!

Sunday, July 01, 2007

Who's going to build this new Web?

What "new" web?

Scoble is talking about flash, apollo, silverspoon, sun's whatever-it's-called, etc...

It's too early to say who will win.
Sure there is... the one that is most "on the web". Right now the winner among the list above looks like apollo. But these will inspire Firefox and Safari.

There are two clear losers on "the client side": anything Microsoft and anything Java (e.g. Sun's whatever-it's-called).

On to the irony. By way of introducing himself, he writes...

In my day job, I create videos about the technology industry for Podtech.net.
I never read Scoble much when he was writing. Now he is video'ing. Which is kind of ironic. There are very few complaints about how difficult it is to link into a spot in a video. That may explain why he's now writing a column for Fast Company.

Friday, June 29, 2007

On AIR

From Cringely...

Describing why Adobe bought Macromedia (it was to get Flash) an Adobe employee said, "We tried everything, but we couldn't get Acrobat small enough to work on a cell phone. You can do a Flash interface that's a fraction of the file size."...

Think about anywhere you see a graphical user interface that isn't attached to a PC -- kiosks, high-end TV remote controls, touchscreens, ATMs, cell phones, digital cameras, VCRs, DVRs, GPS systems, set-top boxes, computer monitors, televisions, elevators, the Toyota Prius, medical equipment, Point of Sale systems, the "cash registers" at McDonalds -- everywhere, really.

Thursday, June 28, 2007

Not My Type, Or: Tests As Hypotheses

From the Scala discussion list...

I bet 90% of the type system goes over my head.
Me too. I think I gave Scala a fair shake for a few days. I have programmed a fair bit more than that in Haskell seven years ago.

I "get" functional programming when it comes to lists, recursion, higher-order functions, lazy evaluation, even monads at the "pragmatic" level of state, I/O, etc. in Haskell.

What I don't "get" is thinking in the various type systems. Maybe this could be called "type-first programming" as opposed to "test-first programming".

For this reason I believe, and the discussion thread, with the few posts it has, starts to confirm, that Scala has a tough row to hoe to become significantly more popular. A book is in the works, and perhaps the momentum Scala has gained so far will promote more in the "how to think in Scala" category.

As it stands I am ready to put Scala alongside Haskell, on my shelf for programming languages: interesting, not my cup of tea, nothing I will invest in at this point, but I am willing to be convinced if others do the leg work that makes the case for taking it back off the shelf.

I remain a dynamic language fanatic, especially a test-driven one, where small, incrementally developed tests are my program's hypotheses, as opposed to various type systems.

I would like to see other languages follow Scala's lead in finding fairly simple ways to become significantly more concurrent within a JVM. Either that or abandon the thing for a better platform.

Reliability

We have Greenspun's Tenth Law. We have Zawinski's law of software envelopment.

Another related truth is that all sufficiently large applications begin to resemble an operating system. And so if you are developing a wiki, a blog server, or anything with the term "server" in it, and you find yourself adding "plugin"-like capabilities, you could do worse than to understand Minix 3, especially with respect to reliability. Well, and Erlang, etc.

Actually, what should be on the reading list? One of the first I had to read was on the THE operating system.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.