Productivity - Cakes and lies

On my "C++ and Ruby - Side by side" post, I mentioned having a natural affinity towards a programming language. Today, I'll elaborate on that, using something I've worked on recently to illustrate.

 

Important note: Nothing I write below is an indictment/endorsement for this or that language. What I'm going for is the exact opposite - whenever you read a book/article about a language (any language) that promises greater productivity just by switching to that language, you should be suspicious.

 

The problem

I've never liked the way IDEs (in my case, Visual Studio/Qt Creator) define their project structures, and I've been trying to setup my own structure, with the goal of supporting multiple tools.

 

Unfortunately, the tools prefer their own particular structure arrangements, and aren't very cooperative to anything that strays from their comfort zone.

 

So, in the end, I've settled for a two-step procedure - I create the projects using the IDEs and then I run a process I created to move the project to my structure. The moving part is easy, and I could do it manually. The tinkering with the project settings files is more tricky, and is what ended up giving me the final push to look at automating the whole thing.

 

I've had three attempts at creating this process.

 

Perl

The first version of this process was a Perl script. Why Perl? Well, because... scripting language... well-suited to small hacks... higher productivity... y'know?

 

It was easy to create a linear script. However, a few weeks later, when I wanted to introduce some changes, it was also easy to get lost navigating around said script, trying to get a grasp of what I had done.

 

So, I went through several redesign/refactor iterations, trying to move from a linear script to something a bit more structured.

 

I finally settled on a version that lasted several months, with Modern::Perl and Moose as foundations. As I used this script, I became aware of several weaknesses in my original design. So, a few weeks ago, I decided to review my design, and proceeded to change the script. And, again, I was lost. Even more so than in the linear script, in fact.

 

I've had to review all the scripts/modules I created in order to understand again what I had done at that time (docs? Come on, it's a simple script to create some directories, copy a few files, edit a couple of those, and init git). And, since I had to do that, I've decided to have another go at it, but this time in...

 

Ruby

Why Ruby? Well, because... scripting language... well-suited to small hacks... higher productivity... y'know?

 

It began well. I removed some syntactic quirks, especially where OO-ness was concerned. Strange as it may seem, a clean language presents a greater potential for a clear design. Maybe it's just me, maybe I'm easily distracted by these syntactic quirks, which I admit should not be quite so important.

 

Long story short, it began well, but... I've started having growing difficulties to implement my design. I've finally decided to try...

 

C++

Yes, predictable, I know...

 

Why? Because I've decided that maybe "lower productivity" was worth a shot.

 

And it went smoothly. Not "easily", not "simply"; but definitely smoothly. I've actually finished the process with the design I wanted. I can actually navigate around the code, easily finding what I'm looking for.

 

What was I aiming at? Here, look at my "main()":

 

void Run(int argc, char *argv[])

{

    AppOptions<ConfigProjectOptions>

        ao{argc, argv, "Opções ProjectConfig"};

 

    if (ao.HaveShownHelp())

    {

        return;

    }

 

    ConfigProjectOptions const& opt = ao.GetOptions();

    string project_name = opt.GetProjectName();

 

    // All objects are validated on construction.

    ProjectDirectory prj_dir(PROJ_PRJ, project_name, 

        STRUCT_PRJ, SHOULD_NOT_EXIST);

    ProjectDirectory bld_dir(PROJ_BLD, project_name, 

        STRUCT_BLD, SHOULD_NOT_EXIST);

    ProjectDirectory stg_dir(PROJ_STG, project_name, 

        STRUCT_STG, SHOULD_EXIST);

 

    Project<QtcStgValidator, QtcCopier, QtcProjectConfigUpdater>

        qtc_project{project_name, prj_dir, bld_dir, stg_dir};

    Project<MsvcStgValidator, MsvcCopier, MsvcProjectConfigUpdater>

        msvc_project(project_name, prj_dir, bld_dir, stg_dir);

 

    // Everything is valid, get user confirmation.

    if (!UserConfirms(project_name))

    {

        return;

    }

 

    prj_dir.CreateStructure();

    bld_dir.CreateStructure();

 

    if (opt.WantGit())

    {

        ConfigureGit(prj_dir.GetProjectHomeDir());

    }

 

    if (opt.IsQtcProject())

    {

        qtc_project.Copy();

    }

 

    if (opt.IsMsvcProject())

    {

        msvc_project.Copy();

    }

}

This is what I was after all along, but was unable to achieve either with Perl or Ruby. It's as clean as it gets, with the main classes clearly identified, based on the operations that I need to do, and with support classes implementing policies that actually take care of the different ways things are done.

 

The code itself is quite simple (this is a trivial program, after all), and you can find it here.

 

I probably could have achieved the same with Ruby, but this is what I'm talking about when I say "natural affinity". With C++, this code structure flowed naturally; with Ruby, not so much.

 

 What's all this about, then?

I'm repeating myself, but I'll say it anyway.

 

Don't trust productivity promises at face value, especially for quick hacks/trivial programs, where everyone says shell/scripting languages are the best choice. Sometimes, the cake is actually a lie.

 

If all you want is to get a count of particular string/regex on a log file, grep is the way to go. But say you need to do some manipulation on the results - e.g., the customer finds out he doesn't need a simple total count, but rather a list of totals for each key (e.g., customer ID). Suddenly, you're reading man pages/docs and searching the web, finding awk/perl/whatever "solutions" that don't quite give you what you want; so, you fiddle with those solutions and read some more man pages/docs.

 

And, then, you look at the clock, see how much time has passed and say - if I had fired up MS Access, I'd probably have written a little VBA, finished this and moved on (yes, "MS Access" and "VBA" are just examples, not endorsements).

 

At the end of the day, just because it's the best option for someone else, doesn't mean it's the best option for you.