Archive
My Erlang Learning Status – III
Since my last status report, I haven’t done much studying or code-writing with Erlang. It’s not because I don’t want to, it’s just that learning a new programming language well enough to write idiomatic code in it is a huge time sink (for me) and there’s just not enough time to “allocate” to the things I want to pursue.
However, that may change now that I have e-access (through my safaribooksonline.com subscription) to a second, terrific, Erlang book: “Erlang And OTP In Action“. Together with the equi-terrific book, “Erlang Programming“, the two different teaching approaches are just what may motivate me to pick up the pace.
When learning a new topic, I like to use multiple sources of authority so that I can learn the subject matter from different points of view. It’s interesting to compare the table of contents for the two books:
Currently, I’m in chapter 2 of the Erlang/OTP book (left TOC above) and chapter 6 in the Erlang book. As I lurch forward, the going gets slooower because the concepts and language features are getting more advanced. I hate when that happens. 🙂
Note: If you’re interested in reading my first Erlang learning status report, click here. My second one is here.
The Assumption Was Wrong
While performing maintenance on some legacy C++ code, a colleague came across a code fragment that performs a large, buffer-to-buffer byte copy. Instead of using the std::memcpy function to implement the copy, it was written the homegrown way – using a loop over the number of bytes to copy. The reason given for the choice was to “avoid the overhead of a function call“.
As the test code and results below show, the performance of std::memcpy blew away the loop-dee-loop strategy by a factor of 40X. The untested assumption behind the decision to write the loop was that std::memcpy was implemented under the covers as a loop by the compiler writers. An alternative assumption, that the compiler replaces std::memcpy with highly efficient, CPU-architecture-specific, inline code, either wasn’t known or it didn’t come to mind.
It took me about twenty minutes to prove, with objective data, that “the assumption was wrong“.
So, what’s the lesson here? There is none. It’s impractical to challenge and test every single assumption we make as programmers – and as people, no? Perhaps the original programmer was a newbie who hadn’t yet learned the rule of thumb that it’s almost always better to use compiler-supplied library functions and classes over equivalent homegrown code. Perhaps the assumption was so ingrained (like the theory X assumption that “anointed” superiors are smarter, more trustworthy, and more responsible than subordinates) it didn’t occur to the programmer to test it out. Perhaps it did occur to the programmer that he/she should test the assumption but he/she felt immense schedule pressure to plow ahead with blinders on.
21st Century Assembler
I love working in the malleable medium of C++, but I wonder if it is becoming, or has already become, the “assembly language” of the 21st century – powerful and fast, but hard to learn and easy to make hard-to-diagnose mistakes. I recently stumbled upon this 5 year old interview with C++ creator Bjarne Stroustrup. The interviewer opened with:
Mr. Stroustrup, the honest soul that he is, essentially validated the opening, but with a trailing caveat:
C++ has indeed become too “expert friendly” at a time where the degree of effective formal education of the average software developer has declined. – Bjarne Stroustrup
Since “experts” tend to be more narrow minded than the average Joe, they tend to look down upon newbies and non-experts in their area of expertise. And so it is with many a C++ programmer towards new age programmers who side step C++ for one of the newer, easier to learn, specialized programming languages. In the classic tit-for-tat response, new age programmers belittle C++ users as old timers that are out of touch with the 21st century and still clinging to the horse driven carriage in the era of the lamborghini.
So, who’s “right“? And if you do share your opinion with me, what language do you work with daily?
Procedural, Object-Oriented, Functional
In this interesting blog post, Dr Dobbs – Whither F#?, Andrew Binstock explores why he thinks “functional” programming hasn’t displaced “object-oriented” programming in the same way that object-oriented programming started slowly displacing “procedural” programming in the nineties. In a nutshell, Andrew thinks that the Return On Investment (ROI) may not be worth the climb:
“F# intrigued a few programmers who kicked the tires and then went back to their regular work. This is rather like what Haskell did a year earlier, when it was the dernier cri on Reddit and other programming community boards before sinking back into its previous status as an unusual curio. The year before that, Erlang underwent much the same cycle.”
“functional programming is just too much of a divergence from regular programming. ”
“it’s the lack of demonstrable benefit for business solutions — which is where most of us live and work. Erlang, which is probably the closest to showing business benefits across a wide swath of business domains, is still a mostly server-side solution. And most server-side developers know and understand the problems they face.”
So, what do you think? What will eventually usurp the object-oriented way of thinking for programmers and designers in the future? The universe is constantly in flux and nothing stays the same, so the status quo loop modeled by option C below will be broken sometime, somewhere, and somehow. No?
Movin’ On Up
For some unknown reason, I recently found myself reflecting back on how I’ve progressed as a software engineer over the years. After being semi-patient and allowing the fragmented thoughts to congeal, I neatly summed up the quagmire as thus:
- Single Node – Single Process – Single Threaded (SST) programming
- Single Node – Single Process – Multi-Threaded (SSM) programming
- Single Node – Multi-Process – Multi-Threaded (SMM) programming
- Multi-Node – Multi-Process – Multi-Threaded (MMM) programming
It’s interesting to note that my progression “up the stack” of abstraction and complexity did not come about from the execution of some pre-planned, grand master strategy . I feel that I was “tugged” by some unknown force into pursuing the knowledge and skills that have gotten me to a semi-proficient state of expertise in the design and programming of MMM systems.
Being a graphical type of dude, here’s a pictorial representation of how I “moved on up“.
How about you? Do you have a master plan for movin’ on up? Wherever you are in relation to this concocted stack, are you content to stay there – in the womb so-to-speak? If you want to adopt something like it as a roadmap for professional development, are you currently immersed in the type of environment that would allow you to do so?
Bug Reporting Rate
My Erlang Learning Status – II
In my quest to learn the Erlang programming language, I’ve been sloowly making my way through Cesarini and Thompson’s wonderful book: “Erlang Programming“.
In terms of the book’s table of contents, I’ve just finished reading Chapter 4 (twice):
As I expected, programming concurrent software systems in Erlang is stunningly elegant compared to the language I currently love and use, C++. In comparison to C++ and (AFAIK) all the other popularly used programming languages, concurrency was designed into the language from day one. Thus, the amount of code one needs to write to get a program comprised of communicating processes up and running is breathtakingly small.
For example, take a look at the “bent” UML sequence diagram of the simple two process “echo” program below. When the parent process is launched by the user, it spawns an “Echo” process. The parent process then asynchronously sends a “Hello” message to the “Echo” process and suspends until it receives a copy of the “Hello” message back from the “Echo” process. Finally, the parent process prints “Hello” in the shell, sends a “Stop” message to the “Echo” process, and self-terminates. Of course, upon receiving the “Stop” message, the “Echo” process is required to self-terminate too.
Here’s an Erlang program module from the book that implements the model:
The go() function serves as the “Parent” process and the loop() function maps to the “Echo” process in the UML sequence diagram. When the parent is launched by typing “echo:go().” into the Erlang runtime shell, it should:
- Spawn a new process that executes the loop() function that co-resides in the echo module file with the go() function.
- Send the “Hello” message to the “Echo” process (identified by the process ID bound to the “Pid” variable during the return from the spawn() function call) in the form of a tuple containing the parent’s process ID (returned from the call to self()) and the “hello” atom.
- Suspend (in the receive-end clause) until it receives a message from the “Echo” process.
- Print out the content of the received “Msg” to the console (via the io:format/2 function).
- Issue a “Stop” message to the “Echo” process in the form of the “stop” atom.
- Self-terminate (returning control and the “stop” atom to the shell after the Pid ! stop. expression).
When the loop() function executes, it should:
Suspend in the receive-end clause until it receives a message in the form of either: A) a two argument tuple – from any other running process, or, B) an atom labeled “stop“.
- If the received message is of type A), send a copy of the received Msg tuple argument back to the process whose ID was bound to the From variable upon message reception. In addition to the content of the Msg variable, the transmitted message will contain the loop() process ID returned from the call to self(). After sending the tuple, suspend again and wait for the next message (via the recursive call to loop()).
- If the received message is of type B), self-terminate.
I typed this tiny program into the Eclipse Erlide plugin editor:
After I compiled the code, started the Erlang VM in the Eclipse console view, and ran the program, here’s what I got:
It worked like a charm – Whoo Hoo! Now, imagine what an equivalent, two process, C++ program would look like. For starters, one would have to write, compile, and run two executables that communicate via sockets or some other form of relatively arcane inter-process OS mechanism (pipe, shared memory, etc), no? For a two thread, single process C++ equivalent, a threads library must be used with some form of synchronized inter-thread communication (2 lockless ring buffers, 2 mutex protected FIFO queues, etc).
Note: If you’re interested in reading my first Erlang learning status report, click here.
Fully Qualified
When I’m coerced into inheriting from one or more base classes to reuse pre-existing functionality, I prefer to fully qualify my calls to base class member functions like this:
Coding this way helps me to keep a conceptual separation between classes and eases downstream maintenance – I know where to look for the function definitions. Since I’m a “has a” instead of an “is a” programmer, I prefer black box composition over white box inheritance; unless it’s necessary or authoritative coercion is involved. How about you? What’s your preference?
Ammunition Depot
In preparation for a debate, both sides usually spend some time amassing evidence that supports their distorted view of the issue. Well, this post is intended to serve as a repository for my distorted side of an ongoing debate.
All the above snippets were strategically and carefully culled from various discussions posted on the wonderful Joel Spolsky and Jeff Atwood site: Stackoverflow.com.
Hard To Misuse
I’ve seen the programming advice “design interfaces to be hard to misuse” repeated many times by many different gurus over the years. Because of this personal experience, I just auto-assumed (which is not a smart thing to do!) all experienced C++ developers: knew it, took it to heart, and thought twice before violating it.
Check out the three date() function prototype declarations below. If you were responsible for designing and implementing the function for a library that would be used by your team mates, which interface would you choose to offer up to your users? Which one do you think is the “hardest to misuse“, and why?



















