Habit, happiness, and programming languages
One of the occupational hazards of spreading the word about Eiffel is the frequent answer “yes, it’s much better than the language I use now, I would like to switch, but…“, followed by some sheepish excuse.
Last night I went to see Eugene Onegin once more (I still hope some day to land the part of Monsieur Triquet). Towards the beginning of the first act [1], Tatiana’s mother (Larina), reflecting in a melancholic tone on the vicissitudes of her (long ago) arranged marriage (and (amazingly) anticipating the very fate (as sketched in the last act) of her own daughter (talking about (amazing) anticipation, is there any other similarly hair-raising case of an author (here of the text behind the libretto) so presciently staging the (exact (down to the very last details)) story of his own future tragic death) but enough digressions (sorry (this is supposed (after all) to be (although it is not the first time (and probably not the last either) it strays from the script) a technology blog))), sings
From above, we were given habit:
It is a substitute for happiness
Is this not exactly the excuse?
Reference
[1] Libretto of Onegin, in English here, in the original there.
Eiffel Software
Home page at ETH
Informatics Europe
LASER summer school
Propulsion Academy
When all the mathematical dust particles have settled to the bottom of the chamber, what remains standing above it is the greatly misunderstood and blurred qualities of human emotional attachment and the strength of it over reasonable choice.
Over twenty-plus years of experience in this business, what is starkly clear to me is how software engineering is a highly charged emotional experience where deeply held attachments shape what ought to be mostly logical choices by mechanisms of human behavior little understood, but having a moment by moment living impact on the work we do.
We ought then not forget how human programmers are, how the memes plus emotions anchor them like suckling babes to the technologies they stumble in to and embrace. As children are raised with the transferred thoughts and beliefs of their parents, so the heads of programmers are filled and bolted on to the particular view of technology from their own corner of that universe.
Following the 80/20 rule, where the 20% are those capable of leading the way home and 80% will follow when enough energy of the group reaches that critical motivational mass, it becomes apparent either a great deal of time, energy or both is required to effect change in a universe already flowing in a particular direction. However, the very technology itself has an embedded mechanism of radical change. For example: The C2Eif project has such potential!
The C2Eif projects ability to leverage years and perhaps decades of code, transforming it from C to Eiffel in such a small amount of time, opens a vast emotional draw of “Shock-and-awe” (e.g. “Gee — did they really just take years of C and transform it flawlessly to Eiffel?”) plus “Yes — We can do that!” By positioning such large bodies of C into the Eiffel universe and doing so with code that is present tense relevant to the marketplace is not a idea to be taken lightly.
It is these reasons and so much more that generates an excitement in me for Eiffel! And there you have it: The emotional bits that drive the energy behind the logical choices. Am I a convert or what?
There is habit, and then there is comfort.
My ability to code and maintain large software written in C has certainly been boosted by my knowledge of Eiffel (and its (remarkable, undoubtedly) foundations — being based on sound principles (that we today call (rightly or wrongly) “object-oriented” but which to me refer to more basic concepts such as modularity, genericity, polymorphism, abstract data types, etc…).
I’ve been in love with Eiffel for the last 20 years, but I can’t seem to be able to enjoy programming as much unless I write C code. Or maybe Perl code :-)
Actually, I could take the view that Eiffel has ruined any programming career I might have had. I started using Eiffel in 1988, after years of C, and a university education in Pascal, Simula, and other typical languages of academic instruction, and have been unable to stop.
I and the others suffering under the same pathology of ‘less is more’ watch our colleagues writing masses of code in other languages, struggling to turn mental models cleanly into code (endlessly working on workarounds), and suffering for lack of direct access to built-in contracts and lambda calculus. We watch the industry as a whole tirelessly trying to make its little god ‘Uml’ perform basic feats of representation, while being simultaneously convinced (or at least evincing so much to others) that it already does ‘everything’ (it’s not a dead labour – one can always work on redefining ‘everything’ to something less, rather than work on the actual problem).
Indeed that’s the job market. Somehow I got left out.
I could be resentful. After all Eiffel isn’t perfect. There’s no ‘enum’ construct. Very annoying. But otherwise I can’t complain too much. More time to read the paper. And programming is a hobby. It doesn’t take up enough time to be called a career…
[…] [1] Habit, happiness and programming languages, article in this blog, 22 October 2012, see here. […]