Morse Codes in Erlang

The portland erlang group is considering some of the ruby quizzes to dive into erlang. If you're not used to programming recursively, you'll probably want to start with simpler problems like implementing the member function, factorial, or count to determine the number of occurrences of some element in a list. When those are comfortable, then the ruby quizzes might be a good challenge.

Here's a sequential, recursive solution in erlang to ruby quiz #121: morse code. It's not *tail* recursive so it could maybe blow out some stack given a really long morse code word. (I assume morse code is translated one word at a time, with spaces between words.)

A tail recursive implementation... hmm... would be a bit more complicated. The two "stacks" are the dots and dashes yet to be decoded and the codes to be considered with each undecoded substring. So one way would be to manage the stacks explicitly in one recursive "loop". Another way would be to use continuation passing style.

Here's (I think) a fairly straight-forward recursive style, morse.erl...

-module(morse).
-export([codes/0, decode/1]).

-import(lists, [prefix/2, reverse/1]).
-import(string, [len/1, substr/2]).

%% http://www.rubyquiz.com/quiz121.html
%%
%% decode/1 when given a string of dots and dashes returns a list of
%% all possible decodings using morse code.
%%
%% Examples:
%%
%% morse:decode(".-").
%% ["ET","A"]
%%
%% lists:member("SOFIA", morse:decode("...---..-....-")).
%% true
%%
%% lists:member("SOPHIA", morse:decode("...---..-....-")).
%% false
%%
%% lists:member("EUGENIA", morse:decode("...---..-....-")).
%% true
%%
%% length(morse:decode("...---..-....-")).
%% 5104

codes() -> 
  [{$A, ".-"},   {$B, "-..."}, {$C, "-.-."}, {$D, "-.."},  {$E, "."}, 
   {$F, "..-."}, {$G, "--."},  {$H, "...."}, {$I, ".."},   {$J, ".---"}, 
   {$K, "-.-"},  {$L, ".-.."}, {$M, "--"},   {$N, "-."},   {$O, "---"}, 
   {$P, ".--."}, {$Q, "--.-"}, {$R, ".-."},  {$S, "..."},  {$T, "-"}, 
   {$U, "..-"},  {$V, "...-"}, {$W, ".--"},  {$X, "-..-"}, {$Y, "-.--"}, 
   {$Z, "--.."}].

decode("") ->
  [];
decode(String) when is_list(String) ->
  decode(String, "", [], codes()).

decode("", "", Results, _Codes) ->
  Results;
decode("", PartialDecoding, Results, _Codes) ->
  [reverse(PartialDecoding) | Results];
decode(_String, _PartialDecoding, Results, []) ->
  Results;
decode(String, PartialDecoding, Results, [{Char, Code} | Rest]) ->
  MoreResults =
    case prefix(Code, String) of
      true ->
        decode(substr(String, 1 + len(Code)), [Char | PartialDecoding], Results, codes());
      false ->
        Results
    end,
  decode(String, PartialDecoding, MoreResults, Rest).

Secure Enterprise-grade Persistent Group Chat

Also from Todd Bishop... Microsoft buys MindAlign...

MindAlign is a secure enterprise-grade persistent group chat solution.

Oh, dear. Is there any reason a large organization would not want to base its future messaging capabilities on XMPP?

But I had similar thoughts about email, and yet there's Exchange. One difference may be, though, with email and Exchange, Microsoft got in before email could become much of a platform for messaging applications. I would imagine over the last 10 years there's been little venture money for email-based platforms.

The same is probably not true for "instant messaging". What do you think? Am I just being ignorant in my recollection and/or prognostications?

Just a Router

Via Todd Bishop on Microsoft's Seattle-area buses running Linux-based wi-fi...

"Obviously this could be a sensitive issue for an operating system company like Microsoft," Polson said of the Linux issue, "but it's just a router, and that happens to be the operating system."

Just a router. Problem is for an operating system company like Microsoft, the operating system is disappearing as quick as it can. No one cares, nor should they.

Before long no one will care about Word, SQL-Server, or SharePoint. Excel may last a bit longer, but most people will realize they don't need 3/4 of what's in that, and there are better ways of getting at the 1/4 they do care about.

Microsoft has shown few signs of being a successful "design shop" in an age of increasingly boutique long tails running on increasingly simple, open, common foundations that have little to do with any specific piece of hardware sitting right in front of you.

I know, I know. They've got a lot of money, past success, patents, and Silverspoon. There's hope for them yet.

And they are a sponsor of the Open Router Platform project.

Parallel Jars of Formaldehyde

Phil Windley observing Parallels in action...

One of the cool features of Parallels is something they call “Smart Select.” With Smart Select you can specify which file types are handled by which application and in which OS. So for example, you can specify that Word docs are always opened in Office 2007 in Windows, regardless of which OS you click on the document. Or that clicking on a URL, regardless of which OS you’re using always opens the page in Safari on the Mac.

Little jars of formaldehyde to preserve the remains of yesterday's mammoth operating systems.

(Re)New Web

"Air will set the World on Fire."

The current browser is a terrible platform for the web. Whatever you think about Adobe's Air, per se, it will ultimately change "the browser" for the betterment of the web generally.

Naming and Synchronization in a Decentralized Computer System

This is David Reed's dissertation from 1978. Croquet, developed in Squeak Smalltalk, is based on this mechanism.

It's Simply Different

Sam Ruby gushes...

With many frameworks and languages, I get the feeling that I’m dealing with a metal cabinet covered by layers of marine paint; one where scratches tend to reveal sharp edges. With Erlang, I get the feeling of a Victorian mahogany armoire; one where scratches in the wood simply reveal more rich wood.

Reading erlang can be fun. Here's Sam's atom2json.erl.

When combining this kind of concurrency with an imperative language, there's typically a bit of code explosion implementing loops and iterators. The tendency also is to write long stretches of code that update variables and structures in place, even when concurrency and first class functions exist.

Erlang, being a Lisp-like language (really), instead traverses lists recursively.

Erlang, being influence by Prolog (somewhat), combines recursion with (a simpler form of) pattern matching.

List recursion, pattern matching, and simple concurrency mechanisms interact into a code implosion. Not weird at all to this Lisp programmer.

It's Already On

To Bob Warfield's point on the multicore crisis upon us already: yes, even on the desktop.

Here's an exercise -- think of your favorite or your most frustrating desktop applications. Maybe a browser, a mail reader, presentation or drawing apps. No matter which specific application comes to mind, that application almost certainly consists of long stretches of sequential code. Almost certainly a good bit of that code could be concurrent not in the sense of a parallel algorithm, but in the sense of there being no logical reason for C to follow B to follow A other than the languages used reinforce that style.

Anytime time you see an hour glass, you see an opportunity for concurrency.

I've been trying out Yahoo's beta email application. It's fine, but really cries out to be developed in a truly concurrent system. Moving more applications into an environment worse than modern desktops, let alone far from securely concurrent, is just a shame. Modern browsers are horrible platforms. We need a new browser model that is concurrent and secure. We need a new desktop that is concurrent and connected.

Both the desktop and the browser are poorly suited for upcoming many-core laptops and desktops. Not to mention five or ten years from now when we may well be deluged in so much more cheap iron looking to do something useful for us other than running bloated sequential code.

Programming shared memory threads in C# with transactional memory will not get us any closer to where we need to be. We need to think much differently with languages that support that thinking. It's only too bad we're still in the 1970s.

Tony Hoare developed monitors in the early 1970s then replaced them with concurrent message passing in the late 1970s. Then Java brought us monitors again in the mid-1990s.

Over a decade later we're still twiddling bits in critical sections stuck in a stretch of sequential code. It's ludicrous to think that's the natural human problem solving model. The tools have shaped our thinking. And I am rambling.

My Agile Failed - pause - NOT

OK, here's the deal: "agile" *cannot* fail!

Preposterous?

Here's why "agile" cannot fail: it is a set of tools that can be adapted to your needs. You may do better or worse with them. In that sense you may fail to benefit from them, or you may simply prefer not to use them. Or you may benefit from them. In either case it is you suffering or benefiting, not "agile".

If you think "agile" can fail, there is a different problem to talk about.

But "agile" cannot fail in the same way "hammer" cannot fail. (Thanks, Ed, for the analogy.)

Delaying The Inevitable

Dan Creswell on a few of the ways we developers paint ourselves into a corner...

Every time we assume we can keep all our data in a single memory or database (even if it’s a cluster) we’re embedding assumptions into our software that will be broken come the day we must partition across multiple memories or databases.

Each time we choose an algorithm that doesn’t easily partition or assumes a single memory/database we’re storing up trouble in our data and computational models.

In big monolithic systems it’s possible to create (by force) a never-fails environment which allows developers to ignore various edge cases.

PDX.erl

Merlyn Albery-Speyer has started a yahoo group for portlanders (and beyond, I presume) interested in erlang.

pdx.erl

The Race Is On, Or Is That Off?

Or: "I just dropped in to see what condition my condition was in."

Tim Bray ponders more cores, hardware (and software -- cannot forget the software) transactional memory as well as erlang, or some sort of erlang transmorgrigication into java or something less weird.

Ralph Johnson addressed that idea, probably accurately.

These are fascinatingly intertwined topics. Dan Creswell sent a link to me the other day: this Sun research paper on Hybrid Transactional Memory (pdf). I hope he blogs about it. He's got a good handle on the situation.

Unlike apparently many smart people at Sun, Microsoft, Intel, and elsewhere, I'm still unconvinced that transactional memory makes the overall problem any easier or better.

I do know that focusing on transactional memory is a short-term solution at best. Erlang addresses the true problem: a simple programming model that can scale out beyond SMP and yet scale down to a single core just as well.

Tim suggests transactional memory will remain well out of sight for application programmers. But these programmers need better tools, no matter how HTM affects them in the small (and eight, even 16, cores should be considered small over the next decade). The results of system programmers using transactional memory in low level SMP code is a drop in the bucket compared to today's and tomorrow's application development problems. These have little to do with a single piece of silicon and have everything to do with networks and complex concurrent collaboration among disparate subsystems.

Not so many years from now we will be awash in more, cheaper, hardware than our current application development languages and tools can reasonably accommodate. We should have a simple model for addressing all that hardware with less developer effort. We need simple languages and tools for concurrency and *distribution* so that we can waste cheap hardware in exchange for leveraging valuable developer ergs.

Today we are wasting hardware running garbage collectors in order to save developer ergs. Increasingly we need to be wasting hardware running large numbers of small processes.

Transactional memory is not even close to the support we need. I am not sure why so many people find it shiny. Maybe I'll be surprised.

Update: Some urls in comments made easier here:

• Bob Warfield: You may have already encountered a multicore crisis and just not known it
• Bob Warfield: 70% of the Software You Build is Wasted
• Brit Butler: The state of state

Brit's got a conversation going with Tim Sweeney on transactional memory vs. message passing.

Tim's example for TM is coordinating a lot of objects quickly in a shared memory for some game scenarios. Fair enough - I am unable to compare the complexity of transactional memory vs. traditional "critical section" mechanisms for this. Off the top of my head I would agree that a shared-nothing message passing mechanism does not really address this problem, but I would imagine it still useful for other aspects of that kind of a game system. My bigger point is this: there are relatively few people with that kind of a problem. Most of us have the kinds of problems that are far better addressed by shared nothing message passing.

So what frightens me as much as the transactional memory hardware and/or software itself is the *attention* it is receiving as any sort of general solution to developing software. Is the cost worth the benefit?

Phil Windley on the Microwulf

Phil Windley on driving down the cost of Beowulf clusters...

The world's cheapest supercomputer, built by a Calvin College CS professor Joel Adams and student Tim Brom is very interesting. They built an 8 core Beowulf cluster using four motherboards and a gigabit network switch for less than $2500. The resulting machine has a price/performance ratio of $100/Gigaflop. That's just plain fun.

I think there ought to be a yearly competition of this sort for students. Who can build the fastest supercomputer for $2500?

Rob Pike on Concurrency and Message passing in Newsqueak

Rob Pike and Luca Cardelli created a simple, concurrent language called Squeak (not to be confused with Squeak Smalltalk) for simplifying programming user interfaces. Pike then turned that into Newsqueak, a more complete programming language. (See "Squinting at Power Series", (pdf)).

Newsqueak has processes like Erlang. But instead of an implicit inbox and outbox per process, Newsqueak has channels as first-class types. All channels are half-duplex, synchronous communicating, well, "channels", as in C.A.R. Hoare's Communicating Sequential Processes. Newsqueak also has only immutable data values, although it does have true variables rather than single-assignment. (Not sure yet how that interacts with concurrent processes running closures over variables lexically known to each process.)

And so Newsqueak can be used to do Erlang-like programming and vice versa, using processes/channels/functions or processes/pids/functions to implement something like the other's mechanisms.

Although Newsqueak does not have the distribution mechanisms or the failure mechanisms of Erlang. And rather than using pattern matching over all the messages in a process inbox, in Newsqueak a process might use something like one channel per pattern or encode all the possible patterns into a structured type passed over a single channel.

Russ Cox has an overview of CSP in the context of Bell Labs where Newsqueak was developed and then led to other interesting things.

Pike is now at Google and not too long ago recorded an interesting and well-done Tech Talk on Newsqueak and concurrent, message passing programming generally...

• Define components as interfaces with all data flow and sharing done as communication over channels.
• The interface is a type; implementations of that interface just honor the protocol.
• Composition is linear in complexity of design but superlinear in expressibility. (The opposite of composition of state machines.) Interleaving is free. Compose interfaces, not state machines.
• Parallelism is not the point, but falls out for free. Networking and remote execution are not the point, but also can fall out (although not quite for free).

...Concurrent processes with message passing can be a powerful model for programming, whether the problem is intrinsically parallel (server design) or not (power series)...

The expressiveness - notation - is important.

Update: Ehud linked here from Lambda the Ultimate, and that thread has several comments of its own.

OK -- yeah, something about JAVA

When I first read the news that SUNW is changing to JAVA, I had to stop and think...

It's not April 1. What day is it? Literally I thought it was a joke.

I used Suns long before Java and imagine I will use them after Java is buried. The timing is curious when SUNW seems to be getting a good bit of non-Java press.

What do I know about these things? I'm pretty sure about this: Java isn't even the hottest thing on the JVM these days.

That's Fine

Bob Ippolito, Exploring Erlang. It's being used for MochiAds. Nice introductory slides.

Some of the Java people looking at Erlang are finding that it's not Java.

There's a reason for this. Unless you've done a fair bit of Lisp or other functional programming, you're not likely to "get" sequential Erlang in a day. Some will, others will practice then "get" it, and still others will run back to Java and pull the blanket over their heads.

That's fine. Just be aware: if you've only ever programmed with...

for (int i = 0; i < a.length; i++) ...

...then you will have to learn to think differently. There is a reason for this.

That's fine.

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.

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.

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.

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.

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.

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.

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. ;-/

Weird Computing in Portland

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

• Floating Point Systems
• Pyramid Technology
• Adaptive Solutions
• Cogent Research

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?

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.

• REST
• Hadoop
• Erlang/OTP
• Jabber
• Microformats

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?

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.

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.

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.

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.

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.

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". :-)

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!

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.

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.