Brand New Website

04 Nov 2012

At last!

I had been meaning to switch the website away from crufty CMS to some lean static HTML generator for a while. Lack of time and my aversion to web design conspired against this for years but I finally made the leap. This website is now generated by the amazing Jekyll, reuses the fine Solarized color palette and a minimalistic plain HTML layout cobbled together by yours truly.

Why bother?

“But”, you say, “isn’t QCodeEdit moribund? After all there hasn’t been much activity in the last 3 years…”

Well, not quite. Back in July 2009 I was excited about my work on the 2.3 branch, preaching to whoever would listen that I was onto something big. That not only the next version would add some amazing features but it would also significantly improve performances. And to be fair, it was not vaporware, I had made some good progress at the time of the announcement.

But, yes, how could there not be a but, I hit a wall. The codebase had become messy as time passed. I eagerly added new features without pausing to consider the bigger picture or rethink the underlying assumptions that had guided the initial design. Worse yet, I didn’t take unit testing seriously - don’t stare at me like that, I’m sure you’ve been young and foolish too - and looked down on assertions.

Long story short I got caught in a series of traps of my own making and that wasn’t exactly pleasant. Then university started to take its toll and QCodeEdit faded to the background.

But look, it’s still twitching

Even though development was stalled, every now and then I would ponder the shortcomings of QCodeEdit’s design and possible alternatives. Fast forward to August 2010, I’m in Zurich, doing an internship in a software company, having a blast and learning a lot (like, you know, the value of unit tests and assertions and the advantages of distributed version control). I had a pretty clear picture of what went wrong with QCodeEdit and many interesting problems to explore and truth be told, I just wasn’t ready to accept failure.

So I went back to work and started rewriting QCodeEdit from scratch. Yes, yes, I know, rewriting is Badâ„¢ but what can I say, after one year of separation, the prospect of wrestling with an unmaintainable mess wasn’t quite as attractive as the lure of a blank slate.

And… we’re back!

Two years later, I now have a Master’s in Computer Science and Applied Mathematics, a fancy-looking CV, a list of glowing references on my LinkedIn profile and a bunch of stamps on my passport but I still haven’t shipped a first public release of QCodeEdit 3…

I’ve made significant progress and even though I’m reluctant to make an official release before reaching feature-parity with QCodeEdit 2, I feel the codebase can now benefit from a larger pool of testers and reviewers. I am therefore making the git repository public today.

I owe many thanks to the fearless few who volunteered to test early code over the last two years. Without them I probably wouldn’t have gotten as far:

  • Benito van der Zander of TeXstudio fame
  • Shafqat Ullah
  • Seyyed Razi Alavizadeh

Feature-parity is not quite there yet but QCodeEdit 3 is already way ahead of QCodeEdit 2 in many respects:

  • Testing: I learned my lesson, the new version comes with a suite of unit-tests, microbenchmarks and fuzz-tests to assess the correctness, performance and robustness of the code.
  • Memory usage: the new version is significantly more frugal in many cases
  • Speed: not only is the new syntax engine lightning-fast but a variety of internal data structures (document buffer, line marks, watched positions) got redesigned with scalability in mind and it pays off. I routinely test QCodeEdit with files containing hundreds of thousands of dense C++ code and it hardly breaks a sweat, even in debug mode.
  • More powerful API: the redesign made oft-requested features like split-views trivial and new API have been introduced that enable a whole new level of features to be implemented easily and efficiently (more about that in future posts)
  • Unicode: QCodeEdit was originally intended to work only with ASCII and fixed-width fonts and it showed. Unicode support in version 2 was hackish at best and utterly broken in many cases. The new version aims to make Unicode a first class citizen. This is not the most extensively tested part of the code but it is already in a much better shape than it ever was in version 2.