Comment don't bother reading this (Score 1) 266
TFA is crap and has nothing to do with TFP which is also crap.
A quote from the Introduction of the paper (The alive reader will notice that they failed to spellcheck it):
Ironically, smart machines are invaluable for considering what they might do
to us and when they might do it. This paper uses the most versatile of smart
machines – a run-of-the-mill computer – to simulate one particular vision of hu-
man replacement. Our simulated economy – an overlapping generations model
– is bare bones. It features two types of workers consuming two goods for two
periods. Yet it admits a large range of dynamic outcomes, some of which are
quite unpleasant.
The model’s two types of agents are called high-tech workers and low-tech work-
ers. The first group has a comparative advantage at analytical tasks, the sec-
ond in empathetic and interpersonal tasks. Both work full time, but only when
young. High-tech workers produce new software code, which adds to the ex-
isting stock of code. They are compensated by licensing their newly produced
code for immediate use and by selling rights to its future use. Thestock of code
– new plus old – is combined with the stock of capital to produce automatable
goods and services (hereafter referred to as ‘goods’). Goods can beconsumed
or used as capital. Unlike high-tech workers, low-tech workers are right brainers
– artists, musicians, priests, astrologers, psychologists, etc. They produce the
model’s other good, human services (hereafter referred to as ‘services’). The ser-
vice sector does not use capital as an input, just the labor of high and low-tech
workers.
Code references not just software but, more generally, rules and instructions
for generating output from capital. Because of this, code is both created
byand is a substitute for the analytical labor provided by high-tech workers
in the good (autmomatable) sector. Code is not to be thought of as accumulating
in a quantitative way (anyone who has worked on a large software project can
testify that fewer lines of code often mean a better program) but rather in
efficiency units.