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

Search This Blog


Friday, March 27, 2009

My Earliest Reference to Erlang (So Far?) - It's Been >10 Years!

I started playing with Erlang and Haskell around 1998. Wow. Over ten years ago. I recently came across a post that may be my first on Erlang. It's to the Squeak list, suggesting Erlang might be seen in the same "message-passing" family of languages as Smalltalk. Someone had written, "I would like to create an application which runs seamlessly across multiple machines and platforms, but it's too hard because the communication and coordination is a bitch.". I replied...

Another approach is the simple message passing approach. This would be interesting to consider, given Alan Key's recent email to this list about "messages" vis-a-vis "objects".

Consider the programming language named Erlang from Ericsson. It is a concurrent and distributed language with no shared memory. All communication is by sending high-level messages. Receivers can pattern match on messages with time outs, etc. What Erlang calls "processes" can be linked to each other for high level process control and reliability.

There are several production-quality communications programs built with hundreds of thousands of lines of Erlang code, so it seems to have some practicality, which may meet the "lots of gain" requirement. The simplicity of it seems to meet the "little pain" requirement.

Wednesday, March 25, 2009

Apollo Workstations: Programming Interprocess Communication

This was sitting in a tab in Safari. I don't remember how it got there. It is a pdf of an Apollo document from 1985. Maybe it was from reading Steve Vinoski's latest RPC, etc. stuff - Steve worked at Apollo.

Maybe you're interested in reading it, maybe not. Apollo workstations were the first true "the network is the computer" computer, predating SunOS. I used them at Boeing and at Mentor Graphics in the 80's and 90's.

The CAD tools I worked on at Mentor Graphics used mailboxes to communicate between components, e.g. back end simulation engines and front end graphics. Note that Pascal is the systems programming language for Apollo.

(Programming Language Evolution?)

I'm not sure I will ever understand this obsession with "lisp has
parentheses". (http://bitworking.org/news/419/programming-language-evolution)

Jesus: "Dear god, we cannot use lisp. It has parentheses! Please
deliver us from evil."

God: "OK, my son. Here's ruby. It's a hack. Try writing a correct
parser! There's no 'there' there. St. Peter and I gave up. We found it
more soothing to go back to lisp."

Dynamic Language Symposium 2009

The 5th Dynamic Languages Symposium has issues its CFP. Funny
description though, seeing Python, Ruby, PHP, and TCL listed as "a new

Clojure? Yes, a new generation.

PHP? Ruby? They're now parents. Smalltalk and Lisp are grandparents.


"The 5th Dynamic Languages Symposium (DLS) at OOPSLA 2009 is a forum for
discussion of dynamic languages, their implementation and application.
While mature dynamic languages including Smalltalk, Lisp, Scheme, Self,
Prolog, and APL continue to grow and inspire new converts, a new
generation of dynamic scripting languages such as Python, Ruby, PHP,
Tcl, and JavaScript are successful in a wide range of applications."

Wiki 14th Birthday

Today is the birthday of Ward's first wiki. 14 years ago. Wow... I see some familiar names from that first day... Patrick Logan (oh, hey!), Patrick Mueller.

Learning from Mistakes — A Comprehensive Study on Real World Concurrency Bug Characteristics

From http://pages.cs.wisc.edu/~shanlu/paper/asplos122-lu.pdf

Some of our findings are as follows: (1) Around one third of the examined non-deadlock concurrency bugs are caused by violation to programmers’ order intentions, which may not be easily expressed via synchronization primitives like locks and transac- tional memories; (2) Around 34% of the examined non-deadlock concurrency bugs involve multiple variables, which are not well addressed by existing bug detection tools; (3) About 92% of the examined concurrency bugs can be reliably triggered by enforcing certain orders among no more than 4 memory accesses. This indi- cates that testing concurrent programs can target at exploring possi- ble orders among every small groups of memory accesses, instead of among all memory accesses; (4) About 73% of the examined non-deadlock concurrency bugs were not fixed by simply adding or changing locks, and many of the fixes were not correct at the first try, indicating the difficulty of reasoning concurrent execution by programmers.

Monday, March 23, 2009

Apache Cloud Computing Edition

Something Steve Loughran is taking with him to hackathon...

"Slideware on my proposal for an Apache Cloud Computing Edition; an
application stack from Apache to provide the app layer for all the low
level infrastructure-on-demand hosting services. Someone has to do it,
and who else is up to it?"

Interesting idea.

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.