Life was likely easier 150 years ago, but not in the way most people will think. Midway through the Victorian era is not often considered to be an epitome of modernity. There were no cars, no electricity, and life moved at a much slower pace. There were many negatives of this time period, at the tail end of the industrial revolution – overcrowded, noisy, and polluted cities, poor living conditions, mediocre levels of hygiene and healthcare. Technology came in the guise of coal powered engines, and mechanical things. People in rural areas lived closer to the land and had an understanding about maintaining a balance between human activity and nature. Somewhere we lost that balance as humans ploughed ahead with all manner of technology – things that were meant to improve our lives, but invariably have turned out to be quite the opposite. Cars, nuclear energy, computers – they have all made our lives different, but not necessarily better. Initial positive experiences have been marred by long-term consequences. Corporate agriculture, greed, exploitation to name but a few. Technology companies are no better. Where once we built things to last, now we build a throw-away society. One has to question whether the best solution to the malady that encompasses our planet would not be to turn the clock back 150-200 years. More local food, slower travel, slower (more mechanical) technology.
How can we even hope to evolve as humans if we consistently forsake that which surrounds us. There is enough to be learned from the world around us without the need to create artificial intelligence. Plant more trees, clean up the plastic in the oceans – it is not hard to do, and it can be done. More iPhones? Future generations can’t eat code, nor should they live in a world where the only animals they can interact with are virtual ones.
Most people treat electricity as an limitless resource. We use it to power up our mobile devices with very little thought to whether it is green or not. It tends to be cheap, so we don’t think twice about it. Programmers tend to treat CPU cycles, and memory in a similar way. It wasn’t always this way.
First, an observation by Gordon Bell:
The cheapest, fastest, and most reliable components of a computer system are those that aren’t there.
Which in an ideal world would make programs omnipotent. But computers exist, and so do programs. Yet for the most part, programmers are warned off playing around with a programs efficiency. Consider Donald Knuth’s 1974 paper “Structured Programming with Goto statements”  in which he wrote:
There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. (…)
Yet have programmers forgotten about efficiency altogether? Many people tend to forget that even in a techno-obsessed world where memory in one form or another is cheap, not all software is efficient. Ever downloaded a webpage, or app that just consumes copious amounts of resources? On mobile devices this can be devastating, draining the battery. Even in digital cameras, some functions are battery bleeders, and best used sparingly. Some algorithms are just impossible to make more efficient, some programmers write horrible code. The basics of program efficiency rely on understanding the algorithm and the environment it is to be used.
 Donald Knuth, Structured Programming with go to Statements, JACM Computing Surveys, Vol 6, No. 4, Dec. 1974, p.268