Saturday, April 27, 2013

Nerd Food: Interesting...

Nerd Food: Interesting…



  • Google Reader alternative for Emacs Ninjas: So the Mayans were almost right, the world is going to end in 2013, the year when Google reader will be decommissioned. Everyone is looking for ways of averting the catastrophe - I've even voted in one or two petitions. This guy proposes using Emacs. Hey, might give it a go, doing everything else on Emacs so why not?
  • Rootless Root: The Unix Koans of Master Foo: Missed this one from ESR somehow. Very jargon'esque, old school koans from the lisp days.

Other Programming Topics


  • Behavioral Finance Explains Bubbles: Pretty much everyone is convinced that regular economics has failed; its good to see that more attention is being paid to interesting offshoots such as behavioural economics. These guys start with how people actually behave rather than how they ought to behave, so their models have a fighting chance.
  • Crushing national debts, economic revolutions, and extraordinary popular delusions: Everyone has been on top of Rogoff and their excel error (which reminds me, you could do worse than listening to NPR's planet money take on it: Episode 452: How Much Should We Trust Economics?). Andrew Odlyzko looks at the problem from another angle, namely how Britain looked like around the industrial revolution. I always struggle with these historical extrapolations but he does make an interesting case.
  • The Bitcoin Bubble and the Future of Currency: Everyone has written an article or two on Bitcoin of late. This is yet another one, with an intro and an explanation on why it will never catch on. Some interesting points, despite shortsightedness.


Date: 2013-04-27 18:49:27 BST

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Wednesday, April 24, 2013

NP: Santa Maria da Feira

Pensando cada dia, cada hora
Pensando en ti
Caminando, mi cesta llena de moras
Son para ti
Temprano por la tarde y por la noche
Sueño de ti


Comiendo pera
En santa maria de la feira
Que placer
La gente buena solo goza nunca hay pena
Pa' que sufrir
Jugando en el mar, en la arena
Viviendo asi


Ventana blanca
Ay, que venga la mañana
Ay que venga otra vez
Asi es como yo paso mi tiempo
Esperando a Inaniel
Y rezando por su calor, por su aliento
Sobre mi piel

Te digo todo aqui va bien
Conmigo de no dormir
Amigo, te lo suplico, te lo pido
Que me ayudes a mi, a mi

Con mi ancla en la marea
Nadando en ti
Yo voy andando
Oyeme, te estoy llamando
Te amo a ti

Por el valle me encontré un rio escondido
Me recuerdo, hacía calor pero tenia frio
Me iba a morir

Ay paloma angelina
Por fin te vi

Sunday, April 21, 2013

Nerd Food: C++ times, they are a changin' - Part I

Nerd Food: C++ times, they are a changin' - Part I

I think most C++ developers would agree that there has never been a better time to be a C++ developer than the present: after all, the C++ 11 standard was released adding a slew of modern features to the language and we are now seeing clang and gcc nearing 100% feature completion. In addition, there is an amount of activity around the language and libraries that I don't ever recall seeing in my professional career; the C++ 14 papers give a pretty good idea of the diversity and reach of this work.

In effect, C++ is negotiating the transition from a closed, vendor driven platform to an open, community driven project. These two articles will attempt to narrate the process, from the perspective of a long time C++ user.

From the beginning, Stroustrup had always believed that without libraries C++ would be a pretty useless language:

Without a good library, most interesting tasks are hard to do in C++; but given a good library, almost any task can be made easy.

Plain C++ was a pretty useless language: many developers reinvented the wheel, and libraries of poor quality were endlessly rewritten. Its hard to remember now, but in the nineties it was a rite of passage to write your own containers such as doubly-linked lists. Slashdot user VortexCortex gives a pretty insightful picture of those long forgotten days:

Well, I wrote my own Hash Map implementation. Before that I had my own Linked Lists too. Before C++ came along I even maintained my own OOP implementation in C with a spiffy pre-processor to convert syntactic sugar into the equivalent ugly object oriented C code riddled with namespace prefixes, indecipherable pointer math for dynamic (virtual) functions (actions), and statically complied variable (property) look-up tables for run-time type inspection (reflection).

It led to incompatibilities between codebases – My Entities+C wouldn't be compatible with your C+OOP. Hell, we didn't even use the same terminology, or necessarily even support the same feature sets. The point is, I wasn't the only one who was doing that (see also: Objective C). There were lots of us, it was a huge waste of duplicated effort. So many, in fact, that C++ was born, and the STL too […].

It is in this context that the C++ 98 standard emerged, and it was seen as a major victory for all involved - a milestone in the development of the language. However, pragmatism won the day and parsimony is always a requirement for shipping; the standard library was pretty much just the STL, the I/O Library and naively-defined string support. Once one exhausted the core functionality of the standard library, well, you were on your own. This is were library vendors came in.

C++ had always been a highly profitable tooling market for vendors, and the vacuum of specification only served to amplify the profits. It was now possible to make a true claim for vendor independence - "hey we are 100% standards compliant!" - while at the same time providing large amounts of vendor specific code. Once a vendor was chosen, vendor lock-in was almost by design: the libraries provided so much functionality and in such vendor-specific ways that changing libraries was synonymous to rewriting entire code bases.

The other interesting aspect of these days was that C++ community just didn't know how to write good C++. Most of the vendor libraries coped out and simply defined object oriented APIs because that was easier to create and easier to consume. Stepanov's dreams - that the STL was simply one example of many of a different way of thinking, and a raft of libraries along the same lines were soon to follow - were put on hold.

But people were already learning from the success of community driven languages such as Perl and Python. A man that was ahead of the curve in this regard was Beman Dawes. Not only did he deeply understand the standardisation process - and its flaws - but he also saw that libraries were the key to success. Thus Boost began as an effort to provide the missing libraries, in a nimble, community driven way that at the same time had high quality standards; these were provided by peer reviews, requests for documentation and so on. Boost soon became the home for the "fundamental" C++ thinking, in many ways continuing the discovery process of the Stepanov ideas in libraries such as Boost.Graph.

In the mean time, the world didn't stand still. The rich pickings C++ provided to vendors proved to be their downfall, as the largess of the tools market gave way to lean times. The crowds moved over to the new shinny toys such as Java and C#, and the new breed of dynamic languages gave C++ the final kick into the legacy bucket. It was just not cool anymore to be seen doing C++. These new languages learned their lessons and came out of the box with large class libraries that provided support for all sorts of things, making the standard library look small and antiquated in comparison. Even with Boost, one would still be nowhere near the functionality of out-of-the-box Java or C#, let alone Python or Ruby.

When a COBOL-style death appeared certain, a phoenix-like effect kicked in. Just as it was with UNIX - where the death and shrinkage of UNIX vendors became the catalyst to create a new breed of UNIX based on collaboration rather than competition - so the same happened to C++. When the big money moved away it was suddenly noticed that no single company could afford to maintain a large library by themselves on the skimpy margins they were now making. Thus many companies opted for open sourcing their code - some just before they went out of business, others as a strategic way of staying in business. Many vendors died, but the few that remained found healthy niches from which to run their businesses.

The second factor that kept C++ alive after all the cool kids moved on was that the old school engineers were still around, and when efficiency became a key concern - as it always does in the end - they were there to explain how efficient server side code could be written in C++. So whilst uncool, C++ was alive and well, just surviving underground in the guts of data centres and in large scientific projects. These users were making hefty use of open source, with Linux GCC and a plethora of open source libraries as their weapons of choice. Together with the appearance of Clang, this mean that both the tooling and the libraries in C++ moved forward in leaps and bounds, but in a process that was almost entirely divorced from the standard. From not having enough libraries we went to having too many of them, with lots of overlapping functionality.

Whilst this was happening, C++ didn't stand still. Some of the more obvious Boost code got shipped into TRs and made their way to end users. And C++ 0x was cooking. This was a major change to the standard, composed both of core language changes but much more importantly, of a great deal of additions to the standard library. A number of Boost libraries were polished up and moved into the std namespace.

But this brought with itself its own problems. Some were related to the new language features - its still not certain how some of these should be used - and others are related to the new libraries. For those of us heavily reliant on Boost, a difficult problem emerged: the standard libraries didn't cover all aspects of the Boost libraries they standardised; for instance, Boost Serialisation won't work with std::shared_ptr, so now code bases become a mix of Boost and standard library code. Clearly the process of offloading Boost libraries to the standard has only begun. And this is what we will be covering in part II.

Date: 2013-04-21 19:02:43 BST

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Thursday, April 18, 2013

Nerd Food: Restoring a file from Git history

Nerd Food: Restoring a file from Git history

A common problem I've had with git in the past is how to restore a file from history. As it turns out, like with many things in git, it is quite easy once you know what you're looking for.

First we need to locate the file. For this we look at all paths affected by the commits we have done over time, so git log is a perfect suitor:

$ git log --all --name-only --pretty=format: | grep -i ecore

As I'm not really bothered as to which commit did what to this file, I just picked one of these paths. You may need to look into history and try to figure out which version is the one you're after. Now we need to figure out the SHA key:

$ git log -- diagrams/Ecore.dia | grep commit
commit f2d763df8b3775a9370ed43e00e3c28a07190932
commit a183879d848f32cd0f8b14c3b4b707f2b4946ca5

I'm sure you could do both of these steps in one go, but I'm too lazy to find out how. Finally, just checkout the blob from the object database:

$ git checkout a183879d848f32cd0f8b14c3b4b707f2b4946ca5 -- diagrams/Ecore.dia
$ head diagrams/Ecore.dia
<?xml version="1.0" encoding="UTF-8"?>
<dia:diagram xmlns:dia="">
    <dia:attribute name="background">
      <dia:color val="#ffffff"/>
    <dia:attribute name="pagebreak">
      <dia:color val="#000099"/>
    <dia:attribute name="paper">

It's that easy!

Date: 2013-04-18 23:51:11 BST

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0