Prescriptions, Proscriptions, and Prognostications Breaking Up The Monolith: The End of the Procrastination! by Matthew Wilson September 10, 2008
Summary
Having spent nearly two years "getting everything sorted" ready to write my next book, I've decided enough is enough. It starts TODAY!
Advertisement
My next book,
"Breaking Up The Monolith: Advanced C++ Design Without Compromise",
is
humbly intended to illustrate how one can have one's C++ cake and
eat it. Specifically, how to have high robustness and performance and
expressiveness and flexibility, along with high(-ish) portability and
discoverability & transparency and modularity, and not have to
compromise one for the other. Clearly, not even the slightest bit humble, then. ;-)
Why C++? Why Monolith?
These raisons d'être are based on the following axioms:
Software must be correct and robust. If it's not, no-one will use
it (again).
(Qualification: I'm talking here about middleware, large-scale data mining,
network servers, trading systems and other systems where C++ is the language of
choice. Obviously web apps are riddled with defects and people continue to use
them. Ho hum.)
If your software must be efficient, C++ is very likely to be your
best/only choice. (If you think you can write
high performance systems
in C# or Java, you probably aren't going to be interested in my book, or even
the rest of this blog post, so save yourself the next non-refundable couple of
minutes out of your life: You may need them to give your enterprise system a head
start over one written according to the principles and techniques, illustrated
in Monolith, available to C++ users ;-)
If high efficiency is not needed, then for Bob's sake save yourself the
heartache, and use a simpler language! I take this advice myself every day,
deferring to C#, Python or Ruby when time-taken-to-write is more important than
time-taken-to-execute.
(This advice may sound somewhat heretical from a C++ author and practitioner. So be
it. I even said as much in the prologue to my last book
Extended STL, volume 1. That may have
something to do with why it's not yet eclipsed Scott's C++ book sales records. ;-)
If you've got to use C++, your job is already a hard one. C++ is not easy, and never
will be, and anyone who tries to convince you otherwise is telling pork pies.
Remember: All Abstractions Leak!
Given your situation, you now most certainly want all the help you can get in terms
of writing and maintaining your application code. You want to write your application
in terms of libraries that:
facilitate high expressiveness, so your application code is dense with what it
does, rather than overwhelmed with supporting code,
have high discoverability, so you are efficient in using the library to
express your intent, and are unlikely to make mistakes while doing so,
facilitate high transparency, so you can understand your application code
when you have to come to edit it, or explain it to someone else who is maintaining
it,
have high flexibility, so that as your application evolves you don't find
yourself having to impinge on efficiency and/or transparency in order to support
types or forms you'd not considered at the outset, or, the worst scenario, find
that you need to change libraries mid-stream with all that that entails in terms
of timeframes and risk
Subject Areas
The things to be learned from/elucidated by Monolith include:
Why strings are all wrong in C and C++, and why this costs so much in performance.
The Shim Concept(s) - An unbounded set of function overloads that
generalise between (aspects of) conceptually related but physically unrelated
types.
The Handle::Ref+Wrapper Pattern - [I haven't yet thought up a catchy
byline for this pattern. :$. It's essentially a way of sharing resources without
sacrificing syntactic simplicity and straightforwardness.]
The Type Tunnel Pattern - The situation
where a group of physically-unrelated types may be tunneled through an
extensible adaptation layer and presented in unified form to an underlying
layer for manipulation as a whole.
The Principle of Intersecting Conformance [Same here: no catchy
byline. Essentially it describes how structural conformance should be balanced
against performance and context-specific power.]
The Principle of Irrecoverability: it is not possible for a
software system to operate in accordance with its design if any component
part of that system has violated its design.
The Principle of Removability: When applied to contract enforcement,
the principle of removability states: A contract enforcement should be removable
from correct software without changing the (well-functioning) behaviour. When
applied to logging, the principle of removability states: It must be possible to
disable any log statement within correct software without changing the
(well-functioning) behaviour.
. . . and a whole load of the usual practical techniques and gotchas to enable you
utilise the concepts, patterns, practices, and principles in writing your own C++
libraries without compromise.
Already there's plenty of evidence as to the usefulness of these concepts, patterns
and principles.
Shims are one of the reasons that all the
STLSoft-related libraries work together
without any coupling between any of them.
The Type Tunnel pattern is put to good use - albeit in different forms
(different interface layers and/or tunnel mechanisms) -
in the
FastFormat,
Pantheios
and
VOLE
open-source libraries:
Pantheios is the
world's fastest
and most robust C++ logging API library. It is 100% robust because it is
100% type-safe and the correctness of a given logging statement is dependent
solely on compile-time factors. It has unmatchable performance, being several
times faster than other major logging libraries when a given severity level is
enabled ("switched on") and up to 500 x (that's 50000%) faster when a given
severity is disabled ("switched off").
The recently-released FastFormat will, I am confident, prove to be
the fastest type-safe C++ formatting library ever written. Early indications show it
to up to 4x faster than C's Streams library, 2-8 x faster than C++'s IOStreams
library and 5-20 x faster than Boost.Format, all the while being 100% type-safe
and infinitely extensible. (Exhaustive performance tests are being prepared,
and results will be reported on the
FastFormat website
in the near future.) If you're interested in these early stages, checkout the
memory allocation guessing game on the website to see just how sparingly the
library uses up processor cycles.
VOLE is a COM Automation driver library, that hides almost all the scary
and verbose guff that is involved when manipulating IDispatch,
allowing the user to pass and receive variables using natural C++ types.
The write-up of VOLE is the first thing I'll be attacking in the next phase
of writing of Monolith.
All three of these libraries strongly promote expressiveness and flexibility,
without sacrificing correctness, robustness or performance. Breaking Up The
Monolith will show you how.
Delays
Having started writing the book in Q3 '06, why is it that now, in Q3 '08, I am only
just getting serious about finishing it? Well, there've been a number of distractions. I
spent more than a year involved with running a development team for a client, something
that has challenges all its own.
I've also been trying to get all my content-related project ducks - libraries, blogs,
articles, other books, related consultancies - in a row, (in hindsight) a ludicrous
thing to try and attempt. This has, in part, led to the situation where
Pantheios has been in beta for two years,
and FastFormat has been in a state of unreleased
proven-concept for nearly that time. Enough already!
Since I'm never going to be ready, and my publisher's nearly set to put a contract
out on me - and not the kind that pays royalties - I've decided that, like having children, if there's never a good time to do it, I might as well start now. So that's what I've decided to do: come hell or high water, each week I will devote two days to writing Monolith.
Why blog about it?
Now having blathered on about all the whys, the last why is: Why am I telling you this?
Is this just another typical blog rant in narcissism? Of course it is. But ... there
are some valid drivers here as well. First, obviously, I want people to be interested in
the book. As I mentioned in a
previous blog post,
I've been advised by some of the greats to save the "how it works" / "magic" for the
books, and write about the "how to use it" & "why you should use it" in articles and
blogs, etc. If I can interest people with more of the latter, perhaps they'll be inclined
to stump up for the former.
Second, as an act of discipline, if I have to report on the progress of the book, and
its related libraries, on a regular basis - I'm still tossing up between weekly and
fortnightly - then any procrastination will be caught, and guiltily reported, much
earlier. And it's very likely that the embarassment and the focus will keep me on track.
Consequently, I've decided to blog about the process here, frequently and regularly. Since
I'm a combination of arrogant narcissist and cynical realist, I won't be surprised if
no-one reads or posts responses to any of it, but I will hold it against you!
In the next posts I'll start introducing you to the exemplars for the concepts, patterns,
practices and principles, beginning with VOLE, which I'm about to enhance significantly and document properly. I'll also report on how my first few days of concentrated writing have proceeded. But for now:
That'll do, Donkey. That'll do.
Talk Back!
Have an opinion?
Be the first to
post a comment about
this weblog entry.
RSS Feed
If you'd like to be notified whenever Matthew Wilson adds a new entry to his weblog, subscribe to his RSS feed.
Digg
del.icio.us
Reddit