The Artima Developer Community
Sponsored Link

Weblogs Forum
Breaking Up The Monolith: The End of the Procrastination!

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Breaking Up The Monolith: The End of the Procrastination! (View in Weblogs)
Posted: Sep 10, 2008 1:23 AM
Reply to this message Reply
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:

  1. 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.)

  2. 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. ;-)

  3. 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.

Topic: Estimate Archaeology - Unearthing Effort from a Repository Previous Topic   Next Topic Topic: Look Ma! No OS!


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us