A year after C++11

A spherical horse from MOBITECH

.. But - there's one proviso.

The model is only valid for a perfectly spherical horse

moving through a vacuum.

A well-known joke

C++11 has been standardized on August 2011, more than one year ago. Though I'm not using it in everyday tasks (ARMCC for 3DS is said to have support for C++11 maybe in 2013), it's still interesting to know what's happening in a world of big programs and unrestricted resources.

Even more rope to shoot yourself in the foot

The title of this book describes what I consider to be the main problem with both C++ and C: the languages give you so much flexibility that, unless you're willing and able to discipline yourself, you can end up with a large body of unmaintainable gobblygook masquerading as a computer program. You can do virtually anything with these languages, even when you don't want to.

Allen I. Holub

"Enough Rope to Shoot Yourself in the Foot"

C++11 is already here. I'm not going to make another overview of all the good new things in it. Actually, I don't know much about those good new things. What I'm going to make - is an overview of why these good new things don't matter much (and why I am not too ashamed of not knowing much about them). There are few reasons.

Write-only code

There are lots of modern and mature languages stating the speed of coding as one of major language advantages:

Python lets you write the code you need, quickly. 

python.org

Perl -- Because life's too short to code without punctuation.

perl.org

Phrases like this always puzzle me. While it sounds nice to be able to write code quickly, what's about reading it? I mean, the code you write is not only for a compiler to read. The code is to be read by humans. By you! And by those unfortunates, who will have to support your code after you leave the building. These poor guys will be glad to know that the fancy language allowed you to write that shit of a code by 15 minutes faster. This warm thought would be with them all that hours they would spend sticking eyes into cryptic lines, trying to fix that little mistake you did 6 months ago..

Documentation?

Well, yes. Documentation. You know that you have to write it for your code, but you never write it, because it's soo boring. And when you have to deal with other's code, you blame them for not writing the documentation.

OK, all clear, next post please.

Well, if you are still here, that's what I wanted to say. There are many huge projects done by serious companies with lots of the documentation. And it's clear that they spent lots of time on documenting all and every public function. But still they are doing it in a wrong way! Lots of documentation is not great by itself!

Rewrite or not rewrite

When I first read Joel on "Things You Should Never Do", I thought that though he's mostly right, there are things that can be argued.. It was long ago and forgotten, until recently I've read "Why rewriting code can be startup suicide" article by Steve Blank and it reminded me of that matter. So here are my 2 cents.

In a perfectly designed world—one with no history—we would not have to suffer everything from hemorrhoids to cancer.

Neil Shubin

"Your inner fish"

GAE, cookies and everything

The reason I'm posting this is because I think the solution we found could be useful for others.. So here's the story.

Some time ago we were trying using Google App Engine to create some king of a web-crawler. And pretty soon we have found that doing HTTP requests to other sites with GAE is not a piece of cake. It's more like a piece of something less tasty...