The Artima Developer Community
Sponsored Link

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:

  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:

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:

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.

About the Blogger

Matthew Wilson is a software development consultant and creator of the FastFormat, Pantheios and STLSoft libraries. He is author of the books Imperfect C++ (Addison-Wesley, October 2004) and Extended STL, volume 1 (Addison-Wesley, 2007), and is currently working on his third, Breaking Up The Monolith: Advanced C++ Design Without Compromise. He has published over 60 articles on C++ and other topics, and has served as columnist and contributing editor for C/C++ Users Journal. Matthew believes that code should be discoverable and largely self-documenting, and lives up to that by being a hopeless documentor. He can be contacted via http://www.imperfectcplusplus.com/ or stlsoft@gmail.com.

This weblog entry is Copyright © 2008 Matthew Wilson. All rights reserved.

Sponsored Links



Google
  Web Artima.com   

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