Technology Holy Wars are Coordination Problems

Flamewars over platforms & upgrades are so bitter not because people are jerks but because the choice will influence entire ecosystems, benefiting one platform through network effects & avoiding “bitrot” while subtly sabotaging the rest through “bitcreep”.
technology, sociology, Python, insight-porn
2020-06-152020-07-09 finished certainty: likely importance: 3


The en­dur­ing phe­nom­e­non of ‘holy wars’ in com­put­ing, such as the bit­ter­ness around the pro­longed Python 2 to Python 3 mi­gra­tion, are not due to mere pet­ti­ness or love of con­flict, but be­cause they are a co­or­di­na­tion prob­lem: dom­i­nant plat­forms en­joy strong net­work effects, such as re­duced ‘bi­trot’ as it is reg­u­larly used & main­tained by many users, and can in­flict a mir­ror-im­age ‘bit­creep’ on other plat­forms which grad­u­ally are ne­glected and be­gin to bi­trot be­cause of the dom­i­nant plat­form.

The out­right neg­a­tive effect of bit­creep mean that hold­outs do not just cost early adopters the pos­si­ble net­work effects, they also greatly re­duce the value of a given thing, and may cause the early adopters to be ac­tu­ally worse off and more mis­er­able on a daily ba­sis. Given the ex­tent to which hold­outs have ben­e­fited from the com­mu­ni­ty, hold­out be­hav­ior is per­ceived as par­a­sitic and im­moral be­hav­ior by adopters, while hold­outs in turn deny any moral oblig­a­tion and re­sent the meth­ods that adopters use to in­crease adop­tion (such as, in the ab­sence of for­mal con­trols, in­for­mal ones like bul­ly­ing).

This des­per­ate need for there to be a vic­tor, and the large tech­ni­cal benefits/costs to those who choose the winning/losing side, ex­plain the (only ap­par­ent­ly) dis­pro­por­tion­ate en­er­gy, ven­om, and in­tractabil­ity of holy wars.

Per­haps if we ex­plic­itly un­der­stand holy wars as co­or­di­na­tion prob­lems, we can avoid the worst ex­cesses and tap into knowl­edge about the topic to bet­ter man­age things like lan­guage mi­gra­tions.

If there is a com­mu­ni­ca­tion plat­form for nerds, whether it’s , , fo­rums, Twit­ter, Github, Hacker News, Red­dit or what have you, there will surely be holy wars—those in­tractable peren­nial ar­gu­ments over whether tech­nol­ogy A or B sucks and why users of the other tech­nol­ogy are not just sim­ple-mind­ed, but so­cio­pathic, sin­ning against all that is good and pure. The re­cur­rent ‘holy war’ phe­nom­e­non in com­put­ing is de­fined in the :

flame wars…The pa­per by Danny Co­hen that pop­u­lar­ized the terms in con­nec­tion with the LSB-first/MSB-first con­tro­versy was en­ti­tled …Great holy wars of the past have in­cluded vs.: , Unix vs.: , vs.: , vs.: , C vs.: , etc. In the year 2003, pop­u­lar fa­vorites of the day are vs., vs., vs. [||]BSD. Hardy peren­ni­als in­clude vs.: …The char­ac­ter­is­tic that dis­tin­guishes holy wars from nor­mal tech­ni­cal dis­putes is that in a holy war most of the par­tic­i­pants spend their time try­ing to pass off per­sonal value choices and cul­tural at­tach­ments as ob­jec­tive tech­ni­cal eval­u­a­tions. This hap­pens pre­cisely be­cause in a true holy war, the ac­tual sub­stan­tive differ­ences be­tween the sides are rel­a­tively mi­nor.

The silent dog: where holy wars are not. One can prob­a­bly name fur­ther ones. For ex­am­ple, the great con­sole wars of the 1990s were ac­com­pa­nied by equally end­less and often ac­ri­mo­nious de­bates over the mer­its of the SNES vs the Sega Gen­e­sis (then the N64 vs the PS1, the PS2 vs XBox…). Or mov­ing 2 decades ahead, cryp­tocur­ren­cies such as Bit­coin vs Ethereum. We should also note what things aren’t holy wars: the ex­act choice of string search al­go­rithm in a tool like grep, one’s choice of FPS vs RPG video game gen­re, how large a hard drive or how many CPU cores1 to buy… There may be the oc­ca­sional de­bate over the­se, but they will tend to be lev­el-headed and pro­duc­tive in a way holy wars aren’t. It’s not mere “brand loy­alty” ei­ther—there are count­less brands out there with cults of fol­low­ers but no holy wars, and to the ex­tent they are de­bat­ed, most shrug and con­clude De gustibus non est dis­putan­dum.

Choices mat­ter. Are holy wars just nerds be­ing nerds? To some ex­tent, sure, ar­gu­ing is often a recre­ational ac­tiv­i­ty; but this can’t pos­si­bly be the whole ex­pla­na­tion, be­cause they de­scend into highly ac­ri­mo­nious flame­wars that no one en­joys and from which every­one comes away em­bit­tered. And con­tra ESR, the tech­ni­cal differ­ences are often quite sub­stan­tial. (Even us­ing his own ex­am­ples, ITS vs Unix or C vs Pas­cal or Emacs vs vi, they em­body dra­mat­i­cally differ­ent tech­ni­cal philoso­phies.) , com­plain­ing about the “emo­tional dis­tress” used to en­cour­age up­grades like Python 2→3 which ap­pear to “un­der­-de­liver” di­rect ben­e­fits com­men­su­rate with all the Sturm und Drang, is per­plexed by the whole mat­ter, and can come up with no bet­ter ex­pla­na­tion than holy wars com­ing from peo­ple en­joy­ing “suffer­ing to­gether” & be­ing “on the moral right side”, which are rad­i­cally in­ad­e­quate (why suffer in the first place?) and he does not en­quire any fur­ther, but re­veal­ingly notes in pass­ing that “very few projects ac­tu­ally are large enough that a fork by some third party would ac­tu­ally sur­vive”.

Net­work effects. What’s the differ­ence? The differ­ence is that holy wars (much like po­lit­i­cal de­bates) are al­ways about plat­forms with net­work effects, and the in­di­rect sec­ond-order effects are much more im­por­tant than the first-order changes. What OS or pro­gram­ming lan­guage or bi­nary num­ber en­cod­ing you use mat­ters to other peo­ple. Peo­ple flame over their fa­vorite MMO, but not their fa­vorite Soli­taire; even two neigh­bor­hood kids ar­gu­ing over video game con­soles ben­e­fit if they can agree on which con­sole is best, be­cause then they can eas­ily share games & save files & video game mag­a­zines.

In con­trast, what you do with them mat­ters a lot less. Once you have set­tled on Mi­crosoft Ex­cel rather than Visi­Calc or Lo­tus-1-2-3 for do­ing your spread­sheets on, the con­tents of said spread­sheets don’t mat­ter nearly as much to other peo­ple as the fact that you are an Ex­cel user.

(Inter)Network Effects

“Should ar­ray in­dices start at 0 or 1? My com­pro­mise of 0.5 was re­jected with­out, I thought, proper con­sid­er­a­tion.”

2

Grow the net­work, even with dirty tricks. If I use Python 3 and can con­vince every­one else to use Python 3 rather than 2, re­gard­less of how much the Python 3 im­prove­ments them­selves ac­tu­ally mat­ter to them or how dis­hon­est my ar­gu­ments are, I am much bet­ter off. The path of a pro­gram­mer who uses the most com­mon lan­guage is a blessed path: li­braries abound, bugs pro­gram­mers of lesser lan­guages rou­tinely en­counter daily will mys­te­ri­ously fail to oc­cur in rel­a­tively bul­let­proof code­bas­es, doc­u­men­ta­tion al­ways ad­dresses his use-case with help­ful snip­pets to copy­-paste, APIs mirac­u­lously re­turn data for­mat­ted in a way con­ve­nient for his de­fault data struc­tures, which their rich fea­ture­ful IDE will tab-com­plete the code for them, Stack Over­flow will over­flow with tips & tricks for any glitches (which come al­most as fun puz­zles, bagatelles be­tween the real work), for all is for the best in this best of all pos­si­ble worlds… There is a large per­sonal and col­lec­tive in­vest­ment in ex­plicit & (one must even learn to think differ­ently for spe­cific tool­s), but once the price is paid, life is good. While those who ven­ture away from the beaten path quickly dis­cover that how many of their own li­braries they will have to write, how un­der­-spec­i­fied many stan­dards are, how many as­sump­tions their OS or API makes (the bet­ter to stab them in the back), how few sign­posts there are or fel­lows to ask ad­vice, how quickly the yak shav­ing kills the beast by a thou­sand cuts (and the more dili­gent they are about fil­ing bugs or patch­es, the deeper they are sucked into the mire), and in their dark­est mo­ments, their faith wa­ver as they won­der if per­haps their fa­vorite lan­guage is not the best pro­gram­ming lan­guage in the world.

Not just ze­ro, but neg­a­tive-sum. Those pos­i­tive net­work effects are clear enough. But one could ac­knowl­edge them and think they are not ad­e­quate to drive the fer­vor of a holy war. So let’s con­sider a sub­tler prob­lem, which is how the suc­cess of one plat­form in­di­rectly harms other plat­forms by wrest­ing away shared re­sources.

Bitrot

Al­ways in mo­tion. The phrase bi­trot en­cap­su­lates the prob­lem of net­work effects for such plat­forms. Pro­grams do not bi­trot be­cause they changed on disk, or be­cause the mere pas­sage of time ren­dered them buggy (with oc­ca­sional ex­cep­tions like Y2K). Bi­trot hap­pens when the rest of the world changes around the pro­gram. APIs change a field name; or the name re­mains the same but the mean­ing changes; or an ob­scure func­tion is bro­ken by a change some­where else and no one no­ticed it un­til your pro­gram tried to use it as al­ways and it broke; or a ver­sion num­ber changed and some­thing else will no longer work be­cause it as­sumed the old ver­sion num­ber and is un­sure if the new one is safe; or you need a par­tic­u­lar pro­gram which can’t be in­stalled with­out up­grad­ing ex­ist­ing pro­grams (thereby po­ten­tially break­ing thou­sands of oth­er­s); or a sys­tem backup uses keys which qui­etly ex­pired or ran out of space or was never up­dated to backup a new server as well. The im­plic­it­ness of de­pen­den­cies and sys­tem in­ter­ac­tions means that there is no way to avoid tak­ing ‘the path of least re­sis­tance’ be­cause one does not re­al­ize there is even a path or that one is be­ing locked into any­thing. (“What do you mean, ‘a is­n’t al­ways 8 bits’‽”) Bi­trot must be ac­tively fought: if you are se­ri­ous about not build­ing in too many de­pen­den­cies, you need tricks like , or de­lib­er­ately crash­ing ser­vices which ex­ceed their ex­pected re­li­a­bil­i­ty.

No sil­ver bul­let. Tech­ni­cal fixes like type sys­tems can help re­duce bi­trot by iden­ti­fy­ing pre­cisely where things have changed dan­ger­ous­ly, but there is al­ways a sys­tem out­side the type sys­tem, and the only truly end-to-end test is the end-user.3

What gets used, works. What does­n’t… There is no cheap way to avoid bi­trot: what gets used gets main­tained. Pro­grams which are in wide use avoid bi­trot less be­cause of any in­trin­si­cally su­pe­rior de­sign but be­cause of the ecosys­tem around them: be­cause break­ing changes are im­me­di­ately de­tected by a cut­ting-edge user (s­par­ing all the oth­er­s), or the break­ing changes are never made in the first place (be­cause they tested & de­tected it, or were well-aware of the con­se­quences, or sim­ply be­cause it broke their own sys­tem first!), and be­cause every­one adapts their things to fit the pop­u­lar pro­gram rather than vice ver­sa. Thus con­stantly re­freshed and up­dat­ed, the pro­gram+e­cosys­tem avoids bi­trot—­like liv­ing flesh, which avoids rot­ting (de­com­po­si­tion by bac­te­ria etc) by con­stant re­new­al.

Bitcreep

“We all have strength enough to en­dure the mis­for­tunes of oth­ers.”

, Maxim #19, Re­flec­tions; or Sen­tences and Moral Max­ims

Dy­ing sys­tems ‘bi­trot’, grow­ing ones ‘bit­creep’. The flip side of bi­trot is what we might call bit­creep: be­cause there is only so much time and en­ergy to go around, a sys­tem which avoids bi­trot will also ex­pe­ri­ence ‘bit­creep’, where other pro­grams be­gin to ‘bi­trot’ in that they in­creas­ingly as­sume, de­pend, and are tested only with that sys­tem, and that grad­u­ally creeps through the ecosys­tem. In a sys­tem with heavy bit­creep, get­ting things done in any way other than the dom­i­nant way means thrash­ing around in what is not so much a ‘Tur­ing tarpit’ as a La Brea tarpit, di­vert­ing new pro­grams to­wards it. It be­comes a black hole, bend­ing space around it; once a pro­gram has built in enough im­plicit and ex­plicit de­pen­den­cies, it has passed the event hori­zon, and it can no longer es­cape (be­cause it would be eas­ier to rewrite the pro­gram from scratch). And be­cause the al­ter­na­tives are not be­ing used, they are not get­ting main­tained, which means that as bit­creep spreads, any­one in­ter­act­ing with older pro­grams in a way that used to work will dis­cover their pro­gram has suffered bi­trot, with­out hav­ing changed at all; all past in­vest­ments are jeop­ar­dized, rot­ting away in­vis­i­bly. (This sug­gests there are two evo­lu­tion­ary strate­gies for sys­tems: to be so sim­ple that no one would re­place them, and to be so com­plex no one could re­place them.)

“Em­brace, ex­tend, ex­tin­guish.” An ex­am­ple might be how has metas­ta­sized in Lin­ux: a boot script al­ter­na­tive has be­come in­volved in every­thing from desk­top en­vi­ron­ments to au­dio dae­mons; in­creas­ing­ly, the only way to do some­thing is via sys­temd. Things which used to be com­part­men­tal­ized and us­able with al­ter­na­tive tools now as­sume the user uses only sys­temd and tai­lor their ca­pa­bil­i­ties to sys­temd. In­creas­ing­ly, root­ing out sys­temd ceases to be pos­si­ble: it sim­ply breaks too many things, even things which os­ten­si­bly have noth­ing to do with the orig­i­nal pur­pose of boot­ing up Lin­ux. Some­one who dis­cov­ers the hard way that a key script of theirs has been bro­ken by sys­temd, through no fault of their own, and that sys­temd can­not be re­moved with­out brick­ing their sys­tem and the last OS ver­sion with­out sys­temd was many years ago and would break a dozen other pro­grams and be ex­tremely in­se­cure, and who dis­likes sys­temd for other rea­sons, could be for­given for be­ing up­set. And for a par­ti­san of sys­temd, it is not enough that sys­temd suc­ceed—others must fail.

One man’s bit­creep is an­other man’s stan­dard­iza­tion. Bitrot/bitcreep are them­selves qua­si­-neu­tral, nei­ther clearly good nor bad.4 The rest of the world is con­stantly chang­ing for good rea­sons, and bi­trot is an un­avoid­able con­se­quence of that; it also changes for bad rea­sons, and that bi­trot is bad. Fight­ing bi­trot re­quires a con­stant in­vest­ment in run­ning a pro­gram, and it may be bet­ter to just let bi­trot hap­pen and move on; too much in­vest­ment in back­wards com­pat­i­bil­ity & legacy sys­tems can be a ma­jor mis­take (con­sider Make­files re­main­ing tab-sen­si­tive after this was clearly a mis­take be­cause the cre­ator was too wor­ried about hurt­ing his lit­er­ally dozens of users, or the bur­den on Mi­crosoft Win­dows to try to run every­thing back to DOS no mat­ter how bug­gy). Bit­creep is bad when it is forc­ing through an in­fe­rior tech­nol­o­gy, but it also is just what con­ver­gence and stan­dard­iza­tion looks like. Fight­ing bit­creep re­quires a con­stant com­mu­ni­ty-wide in­vest­ment in ex­plor­ing the al­ter­na­tives and en­forc­ing, and it may be bet­ter to just let it hap­pen and move on to more im­por­tant things; it is not a bad thing if, say, the de­fi­n­i­tion of a byte as 8 bits grad­u­ally bit­creeps through an ecosys­tem, be­cause how use­ful is it re­ally to make the soft­ware ecosys­tem byte-ag­nos­tic?

Platform Life and Death

“All cru­elty springs from weak­ness.”

5

To­tal war: best never to be­gin, but once be­gun—win! The con­se­quence of the power of bitrot/bitcreep, how­ev­er, is to raise the stakes of choices dra­mat­i­cal­ly, and turn it into a . The more en­com­pass­ing a plat­form, the more im­por­tant it is to con­vert oth­ers, to not just ben­e­fit from pos­i­tive ex­ter­nal­i­ties, but to avoid bi­trot, and a com­peti­tor caus­ing bit­creep. Thus the holy war hi­er­ar­chy: en­di­an-ness > OS > lan­guage > ed­i­tor > desk­top… ter­mi­nat­ing in mock­-se­ri­ous de­bates like tabs vs spaces. (And also why some holy wars end. Peo­ple have ceased to de­bate Emacs vs vim not be­cause any con­sen­sus was reached or ei­ther one dis­ap­peared, but be­cause both are now such ex­ceed­ingly niche ed­i­tors that they are far more threat­ened by the gi­ants like or or .6) What mat­ters is less the mer­its of the vic­tor than that there is a vic­tor: “Worse Is Bet­ter”—e­nough JavaScript pro­gram­mers can push a noodle, or Node­JS, around the equa­tor a dozen times.

A bad com­pro­mise makes every­one un­hap­py. In the case of Python 2 vs Python 3, both are large com­mu­ni­ties, and could po­ten­tially go on in­defi­nite­ly. The per­sis­tence of 2 Pythons is a per­pet­ual headache for all Python pro­gram­mers, as it does not just for­feit the ben­e­fits of scale (2 half-com­mu­ni­ties add up to less than 1 whole-com­mu­ni­ty), but in­flicts com­plex­ity and er­ror on every­one deal­ing with Python, who must make sure they have mul­ti­ple ver­sions safely in­stalled and al­ways use the right one etc. And be­cause of that, Python 2 will en­joy the ben­e­fits of be­ing able to cause bit­creep in other sys­tems, which must work around and cope with Python 2 (rather than vice ver­sa). This is a pas­sive­ly-en­joyed sub­sidy, a ‘rent’, as it were, on the in­tel­lec­tual prop­erty built by past Python pro­gram­mers (iron­i­cal­ly, many of whom are be­hind Python 3). Why should the Python 2 users in­vest in learn­ing all the new idio­syn­crasies of Python 3? The users of Python 2 en­joy the ben­e­fits of a quiet life as their pro­grams do not bi­trot—but that comes at the steep triple cost of the op­por­tu­nity cost of the Python 3 changes (so easy to for­get in all this dis­cus­sion of net­work effect­s), of bit­creep, and of di­vid­ing the com­mu­ni­ty. And al­most all of this triple cost is borne by oth­ers rather than the hold­outs! (It would be hard to cal­cu­late, but con­sid­er­ing the im­bal­ance be­tween library/tool main­tain­ers and their po­ten­tially mil­lions of down­stream users, it seems likely that the ra­tio of cost:ben­e­fits is prob­a­bly im­bal­anced by mul­ti­ple or­ders of mag­ni­tude.) A Python 3 de­vel­oper could be for­given for be­ing up­set.7

War, by other means. Given all this, it’s no won­der that ar­gu­ments might be­come less than po­lite or some re­sort to bul­ly­ing: the stakes can in fact be quite high, and even if not a mat­ter of life & death, make a con­sid­er­able differ­ence to one’s qual­ity of life. Still, such de­cen­tral­ized un­co­or­di­nated flame­wars & bul­ly­ing is a bad idea; if it worked, per­haps it could be jus­ti­fied, but the his­tory of free­lance flame­wars shows that it al­most never works and it is merely de­struc­tive. Peo­ple should “be nice, at least un­til you can co­or­di­nate mean­ness”.

Explaining Holy Wars

This ex­plains why holy wars ex­ist for some tech­ni­cal things but not oth­ers, why they per­sist, why they are often the most vi­cious be­tween the most sim­i­lar groups (it is not but prag­matic be­cause they are com­pet­ing for the same scarce re­sources)8, why they are so in­tel­lec­tu­ally dis­hon­est and in­tractable, why par­tic­i­pants feel forced to re­sort to bul­ly­ing and emo­tional abuse, why they do in fact mat­ter a lot, and how they tend.

This per­spec­tive also sug­gests some ways to re­duce the dam­age.

Coordinating Migrations

Such co­or­di­na­tion prob­lems are not unique to com­put­ing. No one wants to be the first pen­guin off the ice­berg—but those fish won’t catch them­selves. In­stead of ad hoc up­grades, and re­sort­ing to flame­wars, pro­pa­gan­da, and bul­ly­ing of peo­ple who have differ­ent needs or un­der­stand­ably sim­ply do the selfish thing, could there be bet­ter ways?

Ap­peal to pub­lic-spirit­ed­ness. One bet­ter way would be to just raise aware­ness of the costs. Is an up­grade or al­ter­na­tive re­ally nec­es­sary? If it re­ally is, then hold­outs like Armin Ronacher should be made aware of the costs they are cre­at­ing in a rea­soned man­ner, in­stead of mak­ing vague out­raged noises at them.

Eco­nomic in­cen­tives? Given the need to do an up­grade, an­other op­tion is to use eco­nom­ics ap­proach­es: cre­ate a fund to pay main­tain­ers to do the tran­si­tion, or spon­sor a fork if need be (which can be re­turned to the orig­i­nal main­tain­ers once the tran­si­tion is a fait ac­com­pli and the sta­tus quo now cre­ates bit­creep in the other di­rec­tion). An might be a use­ful so­cial tech­nol­ogy here (pay­ing main­tain­ers for their up­grade costs is smaller than the to­tal gains and so is ), or per­haps sim­ply a pub­lic com­mit­ment to do the tran­si­tion at a spe­cific date, sim­i­lar to Python 2 be­ing EOLed.

De­lib­er­ately cen­tral­ize to solve co­or­di­na­tion prob­lems. From the per­spec­tive of bit­creep, at­tempts at mak­ing peace by bend­ing over back­wards to im­prove mod­u­lar­iza­tion and try to sup­port mul­ti­ple ecosys­tems in par­al­lel are noth­ing but self­-s­ab­o­tag­ing fol­ly: find­ing a ‘com­mand­ing height’ to do the tran­si­tion may be the sin­gle most effec­tive strat­e­gy, and it self­-ex­e­cutes by de­fault. (Such a strat­egy may seem un­der­hand­ed, but in co­or­di­na­tion prob­lems, kind­ness is cru­el­ty.) In­deed, per­haps we should recon­ceive the real role of a “” or main­tainer as not be­ing or­di­nary every­day project main­te­nance or or­ga­niz­ing, but sim­ply serv­ing as a fi­nal au­thor­ity to force the com­mu­nity into a new bet­ter equi­lib­ri­um—a role the more valu­able the more rarely ex­er­cised.

See Also


  1. As op­posed to which CPU brand or ar­chi­tec­ture.↩︎

  2. As quoted in Ex­pert C Pro­gram­ming: Deep C Se­crets, Pe­ter Van der Lin­den 1994; while this is the ear­li­est I found, Van der Lin­den says he does not know where it came from, sug­gest­ing it was al­ready folk­lore by 1994. (It is not in Kel­ly-Bootle’s The Dev­il’s DP Dic­tio­nary or The Com­puter Con­tra­dic­tionary.)↩︎

  3. A corol­lary here is that a sys­tem which is also cre­ated end-to-end, like a deep learn­ing sys­tem, may be able to re­duce bi­trot. In “Soft­ware 2.0”, con­ven­tional code like Ten­sor­flow (it­self no­to­ri­ously bi­trot prone) is min­i­mized as much as pos­si­ble in fa­vor of learn­ing all func­tion­al­i­ty. Con­sider a NN like when used for code com­ple­tion or spread­sheets: even if the text for­mat­ting changes, which would im­me­di­ately bi­trot a con­ven­tional soft­ware sys­tem re­liant on brit­tle reg­exps or parsers, they can be given ex­am­ples to do few-shot learn­ing () & smoothly adapt on the fly to “do what I mean”, and can re­train on fu­ture data with­out hu­man in­ter­ven­tion. As the ul­ti­mate input/output pairs change, it can re­train it­self end-to-end.↩︎

  4. One might ask why soft­ware ecosys­tems don’t evolve steadily to­wards higher qual­i­ty. A ma­jor rea­son that seems to be that, as Alan Kay puts it, “com­put­ing is pop cul­ture”. What­ever progress and ex­pe­ri­ence slowly ac­crete over time is swamped by ran­dom ex­oge­nous events. For pro­gram­ming lan­guages in par­tic­u­lar, it is bet­ter to be lucky than good.

    Good soft­ware prac­tice has too lit­tle cor­re­la­tion with fit­ness or profits, per­haps be­cause every­one and every­thing cy­cles over way too quick­ly, for good prac­tices to cul­tur­ally evolve. It was in­fi­nitely more im­por­tant for JavaScript to be avail­able in web browsers ‘na­tively’ than for any of its other de­sign choices to make sense; it was in­fi­nitely more im­por­tant for Face­book, say, to find a so­cial net­work niche than for it to not use PHP—the con­stant fac­tor cost of tech­ni­cal debt could be triv­ially paid off once they were a mul­ti­-bil­lion-dol­lar suc­cess. (As ab­surd as it sounds to make bad choices early on such that later on FB would have to write their own and build on top of it, well, nev­er­the­less, Mark Zucker­berg is rich and you are not, no mat­ter how much more re­fined your tech­ni­cal pref­er­ences are.)

    It’s just . The lower the co­vari­ance be­tween fit­ness and repli­cated phe­no­type, the less se­lec­tion is pos­si­ble. Shift­ing en­vi­ron­ments, poor repli­ca­tion of ‘cul­ture’ & pro­gram­mers, busi­ness mod­els and ecosys­tems cre­at­ing far higher fit­ness differ­en­tials than mi­nor choices of lan­guage or li­brary… then com­bine this with breath­tak­ingly high ‘mu­ta­tional tar­gets’ (“this year, we are Ag­ile!”)… Progress is slow, and every so often some­thing like the PC or web browser or smart­phone comes along, and every­thing must start over.↩︎

  5. Om­nis enim ex in­fir­mi­tate fer­i­tas est.; from , ↩︎

  6. In­deed, vi/vim users are now nat­ural al­lies of Emacs users sim­ply be­cause they both are threat­ened by creep­ing mono­lithic IDEs ren­der­ing it im­pos­si­ble for third-party ed­i­tors to effec­tively in­te­grate with com­pil­ers etc, and if Emacs can still in­ter­op­er­ate with some­thing suc­cess­ful­ly, then so too can vim (see eg the ).↩︎

  7. Ear­ly-adopters & com­put­ing pi­o­neers are our bridge to the fu­ture—be­cause we knife them in the back by tak­ing their work with­out giv­ing, and then step across the muddy ditch on their bod­ies.↩︎

  8. Eg a Scheme Lisp pro­gram­mer vs a Com­mon Lisp pro­gram­mer: if one Lisp pro­gram­mer de­cides to change his pre­ferred lan­guage, he’s prob­a­bly not go­ing to switch to Java!↩︎