Archive
Firing Up The Eclipse Erlide Plugin
To help me learn and practice writing source code in Erlang, I downloaded and installed the “Erlide” plugin for the Eclipse-Helios IDE. The figure below displays a snapshot of Eclipse with the default Erlang perspective opened up. The set of Erlang specific views that are displayed within the default perspective are: the editor, navigator, process list, and live expressions views. Each Erlang specific view is annotated with this kool little Erlide logo:
As you can see, the editor is showing the content of the “hello.erl” source code file, which contains the definition of the “hello/0” function. The console view at the bottom of the screen shows the result of manually typing in “hello:hello().“, which runs the program on the version 5.8.2 Erlang virtual machine (VM). Upon completion, the VM did what it was told. It printed, duh, : “Hello World!”.
The complete list of Erlide views available to aspiring Erlang programmers is shown below. Since I’m a newbie to the land of Erlang, I have no freakin’ idea what they do yet.
With the aid of the supplied eclipse Erlide help module (see below), I was easily able to configure and link the IDE to my previously downloaded and installed distribution of the Erlang VM.
The snapshot below shows the configurability options offered up by Erlide via the eclipse “Preferences” window. I won’t go into the details here, but the “Installed runtimes” option is where you connect up Erlide with your installed Erlang VM(s).
So, C++ programmers, what are you waiting for? Download the latest Erlang distro, the Erlide eclipse plugin (you do use eclipse, right?), buy a good Erlang book, and start exploring this powerful and relatively weird programming language.
Oh, and thanks to the great programmers who designed, wrote, and tested the Erlide Eclipse plugin – most likely on their own time. You guys and gals rock!
Idiomatic Idiot
Programming idioms are the language-specific, more concrete equivalent of design patterns. I remember watching a video interview with C++ creator Bjarne Stroustrup in which he recommended that programmers learn how to program idiomatically in 5, yes 5, different languages. WTF? I’ve been working in C++ for years now and it seemed like forever before I could comfortably program this way. There’s at least one whole book out there that teaches idiomatic programming in C++. Sheesh!
I think that to remain idiomatically competent in a language, one has got to work in the language almost daily for a long, sustained period of time. How can one do this with 5 languages? Maybe it’s just me – I am an Idiomatic Idiot.
How many languages could you confidently say you know how to program idiomatically in?
Access Change
To ensure consistency across our application component set in the team project that I’m currently working on, I’m required to inherit from a common base class that resides in a lower, infrastructure layer. However, since my class resides in the topmost, domain-specific layer of our stack, I want to discourage others from inheriting from it – but (as far as I know) there’s no simple way in C++ to do this (no contorted singletons please – it’s overkill).
In addition to inserting a /*we’ll fire you if you inherit from this class!*/ type comment and removing the virtual keyword from all overridden member functions, I recently discovered an additional, trivial way of discouraging others from inheriting from a class that is intended to be a leaf in an inheritance tree. It may already be an existing C++ idiom that I haven’t stumbled across, but I’ll call it “access change” just in case it isn’t.
The figure below shows what I mean by “access change“. As you can see in the Derived class, in addition to leaving the virtual keyword out of the Derived::mandatory() function definition, I also changed its access qualifier from protected to private.
What do you think? Are there any downsides to this technique? Are there any other “gentle” ways to discourage, but not prevent, other C++ programmers from deriving from a class you wrote that wasn’t intended to be used as a base class?
My Erlang Learning Status
Check out this slide from Erlang language co-designer Joe Armstrong’s InfoQ lecture: “Erlang – software for a concurrent world“. I’ve circled the features that have drawn me to Erlang because I’m currently developing product software where those qualities are hugely important to my customers. Despite their importance to success, they’re almost always given second class status by programmers and managers because they’re not domain-specific, “glamorous“, features.
The blue arrow is my sore spot. You see, I’ve been programming imperatively in FORTAN, then C, and then C++, since Jesus was born. Thus, learning the stateless, recursive, functional programming mindset that Erlang is founded upon is a huge hurdle for me to overcome. Nevertheless, as I’ve stated before, I’m half-assedly trying to learn OMOT how to program in Erlang with the aid of this very good book:
Here’s my learning “status” in terms of the book’s table of contents:
I don’t have an ironclad, micro-scheduled plan or BS risk register pinned on the wall in my war room, so I have no idea when I’ll be 100% done. But who knows, if I don’t abandon the effort:
Note: OMOT = On My Own Time
The Language Of The Language
I found it amusing that “Gotcha” number 9 in Stephen Dewhurst’s wonderful “C++ Gotchas: Avoiding Common Problems in Coding and Design” is titled “Using Bad Language“. At first, I thought: “Come on, why require such stuffiness and rigid formality on matters so trivial?“. However, upon reflection, it does make sense that the careless abuse of the “language defining the language” can contribute to time being wasted and bugs being inserted and BBoMs being created.
Since it’s a powerful general purpose programming language, C++ is necessarily complex. Thus, it requires a creative mangling of the English language to carefully define C++’s features, syntax, semantics, and usage idioms. Understanding and memorizing this myriad of details in order to continuously move toward excellence is a time consuming process – no matter what those “Learn C++ in 24 hours” type books promise.
I consider myself a decent, intermediate level C++ programmer, but I’m constantly probing, sensing, and discovering new terms along with having to refresh my memory and understanding of “the language of the language“. How about you? Do you practice continuous learning and refreshment about your job and tool set?
Moving, Initializing, And Hotdogging
In an interview with C++ creator Bjarne Stroustrup, Danny Kalev asked Bjarne several questions about the major features being incorporated into the venerable C++ language via the C++0x standardization effort. Here’s one such Q+A exchange:
I know, I know. The “*” should be a “+” in the free function declaration box above. But does the typo really detract from the message being conveyed?
So, how hard is it to write a move constructor implementation? It’s as hard as this:
Notice how the lower level reference-to-a-reference (i.e. rvalue reference) feature in the Matrix move constructor enables the higher level “move” feature to be easily written. This capability to move big stuff around instead of copying the behemoth will be a great addition to the language, especially to library writers, no?
Bjarne’s examples of the new “uniform and universal initialization” C++0x feature jacked me up too:
We can use the {…} notation for every initialization and wherever we initialize an X with {v} we get the same resulting value. That’s a major improvement over C++98’s non-uniform set of alternatives using the =v, ={v}, and (v) notations:
With any new and powerful tool, there’s always the danger of “hotdoggers” conniving to show how much smarter than you they are. Here’s a typically wise and insightful, and universal quote from Bjarne on the topic:
Before we get to benefit from the simplifications offered by C++0x, we may go through a period where too many people try to show off their cleverness by enumerating language rules and digging into the most obscure corners. That can do harm.
You’re not one of “those” people are you? I’m not. Luckily, I ain’t smart enough to be a hotdogger. But if I was brilliant…….
Note: I know that the code above is really C, but it was the first googled C++ example I stumbled across.
Related Articles
- Bjarne Stroustrup Reflects On 25 Years of C++ (developers.slashdot.org)
- Bjarne Stroustrup on C++ Inception (thebitsource.com)
Remotivated, At Least For Now
After watching former C++ and CORBA guru Steve Vinoski rave about Erlang in this InfoQ video, I’ve been re-motivated to try and learn a dynamically typed (yikes!), functional programming language. After starting to learn CLisp with the “Land Of Lisp” serving as my training reference, I’ve switched gears. I’ve downloaded the Erlang distribution, I’ve downloaded the Erlang Eclipse plugin “Erlide“, and I’m using “Erlang Programming” as my first training book.
The book’s first chapter describes an impressive list of built in features that have drawn me to Erlang like a moth to a flame:
- Erlang was developed to solve the “time-to-market” requirements of distributed, fault-tolerant, massively concurrent, soft real-time systems.
- Erlang concurrency is fast and scalable. Its processes are lightweight in that the Erlang virtual machine does not create an OS thread for every created process.
- Erlang processes communicate with each other through message passing.
- Erlang has distribution incorporated into the language’s syntax and semantics, allowing systems to be built with location transparency in mind. The default distribution mode is based on TCP/IP, allowing a node (or Erlang runtime system) on a heterogeneous network to connect to any other node running on any operating system.
- Global variables don’t exist.
As of now, I’m planning to occasionally blog about my Erlang learning experience as I inch forward into the weird and whacky world of functional programming. But; since I’m doing this on my own time, I’m a slooow learner, I love working in C++, we don’t use Erlang where I work, and my intrinsic motivation may vanish, I may abandon the effort. If I do decide to “bag it“, be sure to call me a quitter.
Scott Meyers On C++0x
From what I know (which is very little), it looks like the C++0x programming standard will finally be released to the world as C++0B this spring. As part of preparing for this release, I recently listened to an interview with “Effective” Scott Meyers on Software Engineering Radio.
In case you find yourself bored, and with an hour of free time on your hands, check out my audio + notes pencast recording of the interview on the Livescribe smart pen site: here. (Clicking on the pic below won’t start the pencast in-situ. I haven’t figured out how to embed pencasts into this blog yet).
The interview was an interesting mix of good technical information from Scott, triggered by great questions from the interviewer. Nevertheless, at several points during the interview, the interviewer seemed to interject sarcastic commentary that showed his disdain for the language. He obviously wasn’t/isn’t a C++ language fan, but he still did a great job with his questions. The interview never veered off into a “your language sux and my language rules” religious war and the interviewer’s snarky remarks kept the interview refreshing:
“Why doesn’t C++ have garbage collection? …… Because then there would be nothing left.”
In summary, Scott used his considerable teaching talent to clearly and concisely explain these key features of the “C++0B” standard:
- concurrency
- the “auto” keyword
- move semantics using rvalue references
- variadic templates
- lambda functions
- uniform initialization syntax
- tuples (or as the interviewer pronounced, “two-pulls” 🙂 )
If C++ is your programming language of choice and you haven’t followed the development of the new standard, now may be the time to start wading in? The Meyers interview, this excellent Wikipedia C++0x starter page, and Bjarne Stroustrup’s C++0x FAQ page may help.
Related Articles
- An Interview with C++ Creator Bjarne Stroustrup (codeguru.com)
- Type Inference vs. Static/Dynamic Typing (herbsutter.com)
Where’s The Bug?
When you’re designing and happily coding away in the application layer and you discover a nasty bug, don’t you hate it when you find that the chances are high that the critter may not be hiding in your code – it may be in one of the cavernous homegrown libraries that prop your junk up. I hate when that happens because it forces me to do a mental context switch from the value-added application layer down into the support layer(s) – sometimes for days on end (ka-ching, ka-ching; tic-toc, tic-toc).
Compared to writing code on top of an undocumented, wobbly, homegrown BBoM, writing code on top of a professionally built infrastructure with great tutorials and API artifacts is a joy. When you do find a bug in the code base, the chances are astronomically high that it will be in your code and not down in the infrastructure. Unsurprisingly, preferring the professional over the amateur saves time, money, and frustration.
For the same strange reason (hint: ego) that command and control hierarchy is accepted without question as the “it just has to be this way” way of structuring a company for “success“, software developers love to cobble together their own BBoM middleware infrastructure. To reinforce this dysfunctional approach, managers are loathe to spend money on battle-tested middleware built by world class experts in the field. Yes, these are the same managers who’ll spend $100K on a logic analyzer that gets used twice a year by the two hardware designer dudes that cohabitate with the hundreds of software weenies and elite BMs inside the borg. C’est la vie.
Improper Inheritance
Much like Improper Inheritance (II) can wreck family relationships, rampant II can also destroy a project after large and precious investments in time, money, and people have been committed. Before you know it, BAM! All of a sudden, you’ve noticed that you’re in BBoM city; not knowing how you got there and not knowing how to get the hell out of the indecipherable megalopolis.
Here’s what the “C++ FAQ” writers have to say on the II matter:
Here’s what Stephen Dewhurst says in “C++ Gotchas” number 92:
Use of public inheritance primarily for the purpose of reusing base class implementations in derived classes often results in unnatural, unmaintainable, and, ultimately, more inefficient designs.
Herb Sutter and Andrei Alexandrescu‘s chapter number 34 in “C++ Coding Standards: 101 Rules, Guidelines, and Best Practices” is titled “Prefer composition to inheritance“. Here’s a snippet from them:
Avoid inheritance taxes: Inheritance is the second-tightest coupling relationship in C++, second only to friendship. Inheritance is often overused, even by experienced developers. A sound rule of software engineering is to minimize coupling: If a relationship can be expressed in more than one way, use the weakest relationship that’s practical.
On page 19 in Design Patterns, the GoF state:
“Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters.”
Let’s explore this malarial scourge a little closer with a couple of dorky bulldozer00 design and code examples.
The UML class diagram pair below shows two ways of designing a message. It’s obvious that a message is composed of a header and payload (and maybe a trailer), no? Thus, you would think that the “has a” model on the left is a better mapping of a message structure in the (so-called) real world into the OO world than the multi “Is a” model on the right.
I don’t know about you, but I’ve seen many mini and maxi designs like this implemented in code during my long and undistinguished career. I’ve prolly unconsciously, or consciously but guiltily, hatched a few mini messes like this too.
For our second, more concrete example, let’s look at the mixed design and code example below. Since the classes and member functions are so generic, it’s hard to decide which one is “better”, no?
By looking at the test driver below, hopefully the “prefer composition to inheritance” heuristic should become apparent. The inheritance approach breaks encapsulation and exposes a “fatter” interface to client code, which in this case is the main() function. Fatter interfaces are more likely to be unknowingly abused by your code “users” than thinner interfaces – especially when specific call sequencing is required. With the composition approach, you can control how much wider the external interface is – by delegation. In this example, our designer has elected to expose only one of the two additional interface functions provided by the Base class – the ifaceFunc1() function.
Like all heuristics in programming and other technical fields of endeavor, there are always exceptions to the “prefer composition to inheritance” rule. This explains why you’ll see the word “prefer” in virtually all descriptions of heuristics. Even if you don’t see it, try to “think” it. An equivalent heuristic, “prefer acceptance to militancy“, perhaps should also hold true in the world of personal opinions, no?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 