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

Search This Blog

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


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.


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.


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.


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.


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.


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


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.


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.

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.