Thinking Erlang – 2

Just as every programming language has a sweet-spot in the universe of problems and applications, every programming language is best approached with a particular mind set.

Years ago my company developed consumer and educational software products for major publishers. Target platforms included Apple II and the early IBM PC, including, sigh, the ill-fated and best forgotten IBM PC Jr. Our language of choice was Forth.

At the time various critics called the community of Forth programmers a cult. We were certainly enthusiastic about the power and productivity of Forth but, believe me, we would have jumped ship in a jiffy for a more productive tool set. During our prime years, however, over which we developed more than 100 shrink-wrapped software products, no such vessel showed sail above the horizon.

The inventor of Forth, Chuck Moore, was and is a minimalist. His mantra is less is more. He tossed out in-fix notation, looked askance at variables, floating point, conditionals, and control structures. He struggled manfully to get rid of the computer keyboard, but never quite succeeded. Once he’d stripped his language of all but power-packed bare necessities, he turned to chip design, took one look at the minicomputer-based CAD tools of the day, and… hated them.

It took Chuck two weeks to write a more powerful chip design CAD environment in his lean-and-mean language. His CAD system ran on a low-end PC. His first chip out of the fab was expressly designed to run his language as its operating system. Given that, he could design even more powerful chips on a 4×4-inch printed circuit board powered by a lantern battery. His display was a cheap TV set connected to the video-out pin on his chip.

Believe me. It’s true!

If you think Chuck’s journey is a path down madness lane, take a look at his latest chip, the SEAforth 40C18. Talk about the power of concurrent programming!

http://www.intellasys.net/

During our glory days we had a contract with an educational publisher to develop self-study software for algebra I and II students. We decided we needed at the heart of the product an algebraic equation solver. I hired a hot-shot C programmer with impeccable credentials, gave him a quick introduction to Forth, and left him alone.

A few weeks later my expensive hire came back with working code… proud as punch. The code ran, though slowly. I took one look at the source and wanted to cry. The source was all one Forth word (function), hundreds of lines long, with a gazillion variables, and deeply nested if-then statements.

I argued that this is not the way to write Forth. He countered that it was the best way to write the program and, after all, it worked. I offered to show him a better way, but he quit in a huff.

At the time two Forth programming books stood out, both written by Leo Brody. Starting Forth was akin to Joe Armstrong’s Programming Erlang. But Leo’s second book, Thinking Forth, changed the way we all thought about programming. Leo taught us how to write Forth programs that looked like this source code for an automatic teller:

: RUN
READ-CARD CHECK-OWNER CHECK-CODE TRANSACT ;

: READ-CARD
valid code sequence NOT readable IF eject card QUIT THEN ;

: CHECK-OWNER
owner is NOT valid IF eat card QUIT THEN;

: CHECK-CODE
code entered MISmatches owner’s code IF message QUIT THEN ;

etc.

The last thing I want to do is compare and contrast Forth and Erlang. Erlang has its own charms and I’m trying to learn them. That is, I’m trying to learn how to think and solve problems the Erlang way.

Last post, I commented on difficulties I encountered while tracing through source code for Joe Armstrong’s Simple Web Server. Two readers came back with helpful suggestions.

Joseph Wecker suggested that, given time and experience, I would learn to think of Erlang processes as an additional dimension of structure, orthogonal to modules and functions.

Hokan suggested that I look at UML sequence diagrams as a method for visualizing process intercommunication.

http://www.agilemodeling.com/artifacts/sequenceDiagram.htm

The sequence diagrams look like they might be useful, at least for newbies like me. And this got me thinking… since my drawing skills are feeble, and my penmanship near illegible, wouldn’t it be great to have a tool written in Erlang that displays sequence diagrams.

Input might look something like this:

Processes = {processes, [processA, processB, processC]}

Sequence_Diagram = {msgs, [{spawn, processA, processC}, {spawn, processB, processC,}, {msg, processA, processB,"my message"}, etc]}

Even if this tool has marginal value for code-review or design, it would be an excellent exemplar for a tutorial on Erlang gs.

http://erl.dougedmunds.com/

So, my challenge… who among you can come up with this program within the next seven days? You write it, I’d be delighted to work with you on the Erlang gs tutorial. Or, if you prefer, stand back and admire.

And maybe… this tool could be taken one step further: Feed Erlang source files in… get sequence diagrams out.

How hard could that be?

I’d dive into this myself, but I’m still trying to learn how to write a blog.

Anyway, it seems to me that anything we can do to speed our journey up the learning curve, tighten up the concept through production cycle and, in general, help us think more clearly in Erlang, can only be good.