“My second childhood was kindly delivered to me by my children. This, I suspect, was no coincidence. Children know something that adults have forgotten — something adults have to forget when they begin playing the great game of growing up and becoming someone.”—Tennis with Plato, by Mark Rowlands
“…students almost universally resist going back over material they’ve written. But… students are willing to revise their essays, even multiple times, when their work is being reviewed by a computer and not by a human teacher. They end up writing nearly three times as many words in the course of revising as students who are not offered the services of E-Rater, and the quality of their writing improves as a result. Crucially… students who feel that handing in successive drafts to an instructor wielding a red pen is “corrective, even punitive” do not seem to feel rebuked by similar feedback from a computer.”—Robo-readers aren’t as good as human readers — they’re better
I have often wondered how things grow, and specifically, how software projects grow. Some initial looks at specific projects had pointed out that they grew super-linearly.
A recent paper looks at a large cross-section of open source projects to analyze how adding people to projects affects their productivity.
They find that production intensity , as measured by number of commits, grows super-linearly with the number of project members. The median exponent was 4/3, which works out to a productivity boost of a factor of 2.5 when number of members is doubled.
Not surprisingly, the exponent was smaller (but still super-linear) for larger projects, but also showed less variability.
Now today, in the 21st century, we have a better way to attack problems. We change the problem, often to one that is more tractable and useful. In many situations solving the exact problem is not really what a practitioner needs. If computing X exactly requires too much time, then it is useless to compute it. A perfect example is the weather: computing tomorrow’s weather in a week’s time is clearly not very useful.
The brilliance of the current approach is that we can change the problem. There are at least two major ways to do this:
Change the answer required. Allow approximation, or allow a partial answer. Do not insist on an exact answer.
Change the algorithmic method. Allow algorithms that can be wrong, or allow algorithms that use randomness. Do not insist that the algorithm is a perfect deterministic one.
“The conservative view sees this as an automotive technology, and most of them are very used to thinking about automotive technology. For the aggressive school, where I belong, this is a computer technology, and will be developed — and change the world — at the much faster pace that computer technologies do.”—The two cultures of robocars
Your understanding of the domain, or the domain itself, has changed drastically in the process of building the first version.
The scale for which you built the initial system has grown by more than an order of magnitude. The right design for millions of users is very different than that for thousands.
Newer languages and runtimes make the product much better along some dimension: deliver better performance, be more maintainable etc.
You have accumulated so much technical debt that starting from scratch is easier than untangling the mess you have. This is often the most misleading reason, because engineers always prefer a system they wrote from scratch to inheriting one which works just fine. But even so, it does happen.
None of the above takes away from what Spolsky wrote. A rewrite is still a risky endeavor, even if one or more of the above conditions hold true, and should always be approached with caution and humility.
His argument was much stronger in the era of software that was shrink-wrapped to PCs, because the slow rate of change of the surrounding environment made many of the above reasons inapplicable.
But server-side software that powers online services is always in a constant state of flux. There is rarely any concept of “done”. The product might look more or less the same from the outside, while the backend code constantly churns to deal with growing scale, new stacks, and other services it depends on.
If you are a “regular” person living and working in modern civilization, it is likely that your life has a few recurring patterns:
on weekdays, you travel from home to work in the morning, and back in the evening; perhaps punctuated with a school or daycare drop-off and pick-up.
on weekends, you either mostly stay at home or frequent a small set of haunts (beaches, restaurants etc).
infrequently, you break out of this pattern by leaving the orbit of work-home to go on a vacation.
This is easy to figure out by observing someone for a short period of time. Of course, your phone already does this.
The above model of your life could be described in a few kilobytes. It is a zeroth-order machine learning problem. Is that depressing? Does that mean your whole life has a few kilobytes worth of complexity?
Free will can now be defined as the ability to surprise a prediction model.
Our past data betrays our future actions, and rather than put us in a police state, corporations have realized that if they say just the right thing, we’ll put the chains on ourselves… Yet this loss of our internal selves to the control of another is the promise of AI in the hands of the private sector. In the hands of machine learning models, we become nothing more than a ball of probabilistic mechanisms to be manipulated with carefully designed inputs that lead to anticipated outputs… The promise of better machine learning is not to bring machines up to the level of humans but to bring humans down to the level of machines.
That is a dim, if plausible, view.
It is based on a pessimistic view of humans as always giving in to nudges to behave as our worst selves. I hope that we are better than that. We are already surrounded by advertising for junk food, and yet a substantial fraction of us manage to ignore that and eat healthy. I hope machine predictions that try to nudge us face a similar fate: predictions that look down on us will be indistinguishable from low-quality ones. The quality and tone of predictions will become an important part of the brand identity of the company emitting them. Do you really want to be the company known for peddling fatty, salty food, legal addictive substances, and predatory loans?
A tangential point: naming matters. Statistical inference, which is what machine learning really is, is a less scary name. “Statistical inference” conjures images of bean-counters with taped glasses; “machine learning” of an inevitable army of terminators.
Circling back to the question I posed above: is your life really describable in a few kilobytes in a predictive model? No. A model is a probabilistic abstraction. You, and your life, are not a sequence of probabilities, in much the same way that hiking a trail is a much richer, “realer” experience than tracing your way through a detailed trail map.
“The AP announced last month that it would use Automated Insights’ software, called Wordsmith, to produce up to 4,440 robot-written corporate-earnings reports per quarter, more than ten times the number its human reporters currently produce. When Alcoa’s earnings report hit the wire that day, the data was instantly compiled by a firm called Zacks Investment Research and passed through the AP’s proprietary algorithm, which pulled out key numbers and phrases and matched them against other contextual information. In milliseconds, the software produced a full story written in AP style, indistinguishable from one made with human hands. In short order, the story appeared on many AP member sites.”—Robot Journalism
“Here’s the tablet news app I’m hoping for in 2014: something that detects when I’m lying down in bed (it knows my device orientation and, using the ambient light sensor, can detect it’s dark) and serves me the sort of video content that I never have time to watch during the day.”—Katie Zhu
I define a garland word to be one which can be formed by chopping off the last few letters and “wrapping around” to the start.
For example: You can chop off the the trailing “on” from “onion” and still form the word by wrapping around to the starting “on”. In other words, you can write the letters “o”, “n”, “i” in a circle, in that order, and form the word “onion”.
I say that a garland word is of degree n if you can do the above with the last n letters of the word.
It turns out that garland words are fairly rare. In the English dictionary that came installed on my Ubuntu machine, there were 99171 words, only 199 words were garland words of degree 2 or above. The highest garland degree was 4.
The exact distribution was: there were only 3 words of degree 4, 32 of degree 3, and 164 of degree 2.
The degree 4 garland words were: “hotshots”, “beriberi” and “abracadabra”.
This question comes into stark relief if you look at what a modern language or VM runtime does: among other things, it multiplexes resources, and protect access to them. But that’s also exactly what the OS is supposed to do!
The paper riffs on an earlier idea from Dan Ingalls: “An operating system is a collection of things that don’t ﬁt into a language. There shouldn’t be one.” The central problem tackled in the paper is that of having more generic object bindings in the OS, as opposed to the “static” filesystem bindings for most operations. Kell uses the following example:
Suppose we wish to search some object for text matching a pattern. If the object is a directory tree of text files, grep -r does exactly that. But suppose instead our directory tree contains a mixture of zipped and non-zipped files, or is actually some non-directory collection of text-searchable objects, such as a mailbox. In Smalltalk parlance, how can we make these diverse objects “understand” (via a collection of interposed objects) the messages of our grep -r (and vice versa)?
This would indeed be elegant. But I’m afraid the engineer in me isn’t terribly excited by that.
Indirection is controlled by some sort of configuration the binds each side of it. And configuration implies a lot of added complexity. The UNIX model of “everything is a stream of bytes and can be treated like a file” might be simple and unstructured, but that is precisely what enabled a multitude of structure to be built on top of it.
The only unit of time that matters is heartbeats. Even if the world were totally silent, even in a dark room covered in five layers of foam, you’d be able to count your own heartbeats.
When you get on a plane and travel you go 15 heartbeats per mile. That is, in the time it takes to travel a mile in flight your heart beats 15 times. On a train your heart might beat 250 times per mile…
… If we are going to ask people, in the form of our products, in the form of the things we make, to spend their heartbeats—if we are going to ask them to spend their heartbeats on us, on our ideas, how can we be sure, far more sure than we are now, that they spend those heartbeats wisely?
With each increase in animal size there is a slowing of the pace of life. A shrew’s heart beats 1,000 times a minute, a human’s 70 times, and an elephant heart beats only 28 times a minute. The lifespans are proportional; shrew life is intense but brief, elephant life long and contemplative. Each animal, independent of size, gets about a billion heartbeats per life.
The biggest winners may be lawyers who can use machine intelligence to create an automated large-scale practice. The Walton family, it’s worth recalling, got rich by effectively automating large-scale retail. More generally, there may be jobs for a new category of engineer-lawyers—those who can program machines to create legal value.
But the large number of journeyman lawyers—such as those who do routine wills, vet house closings, write standard contracts, or review documents on a contractual basis—face a bleak future.
“Autodesk’s automated design software works through three layers. Generators populate physical space with matter, creating thousands of design suggestions in a split-second. Analyzers test each design against constraints developed by the designer: does it fit in the desired shape? Does it satisfy strength, thermal, material, and mechanical requirements? Above those, an optimization system finds the best designs, returns them to the starting point, and refines them repeatedly.”—The Automation of Design
The Eames house was everything I wanted: modern, but lived in, made out of everyday, accessible materials. No pristine white, dustless Dwell magazine show rooms here. There are plants and books and lights and seats and dust and you get the feeling it is a beautiful, functional space. There are finger prints all over it. The more I click around the web, the less and less I sense those fingerprints on people’s websites the way I used to. I’m not sure if it’s because of templates, or because those things take time, or if people just don’t think it’s worth it. But I think those traces of people are worth the effort, so I wanted to really work towards having this site feel like it was made by a person, and not some smug guy in a very tight, black turtle neck. Has anyone ever smiled in Dwell?
I wanted something homey. Better yet: homely. Americans think of homely as something that’s unhandsome, maybe even ugly. But the Brits observe the root “home,” since they invented the damn language. Homely, for them, is like a house: familiar, comforting, easy. There’s a rightness to it. For me, the Eames house is homely, because they filled it to the gills with the things they loved. How great would it be to have that online, where you would not run out of shelves? It’s an old dream, and one that’s still alive, but we’ve outsourced it. I think that shelf belongs at home.
Most reactions to this have been along the lines of “look at these rich powerful elites thinking they can up and leave and do without all the rest of us!” I want to focus not on the politics behind this, but the motivation.
These ideas are getting attention now because rich and powerful titans of tech are espousing them. But these are the secret fantasies of every geek, rich or not, powerful or not.
Geeks have deep isolationist tendencies. They prefer losing themselves in sci-fi worlds to hanging out with friends. They build an early affinity with machines and programs. They sense that programming is the ultimate in world-building, and what’s more, it’s executable! They build elaborate towers of abstraction. They are drunk on the clean rationality of the world that the machine and they have built and understand.
Eventually, they secretly wish for a more ordered world. A world that is not messy or unpredictable. A world where one might have to work hard to establish the priors, but once they are, everything follows.
It is telling that one of the central activities in programming is abstraction. Abstraction is nothing but taking a jumble of intricate detail, putting it in a tightly sealed box, and then poking very small, well-defined holes in the box to interact with that jumble. So clean! So much better!
But every abstraction is leaky. Ints carry the baggage of their bit-width. In a perfect world, every int would be a BigInt with unlimited range. But we live in a world where it matters whether ints fit in a hardware register or not. Networks carry the baggage of not being perfect links. In a perfect world, a link between two machines would be an immutable, always-available channel for sending messages between them. But we live in a world where wires break.
This is the central tension in the mind of every geek. The constant need to abstract, to order, to rationalize, pitted against the necessary realization the world and entropy will eventually thwart you.
Secession is simply the same need for order and abstraction carried into the geek’s mental model for society.
The world of humans is messy, unpredictable, and—this is the part that infuriates you the most, the part you simply don’t get, the part that will forever make you an outsider—unreasonable. Humans are unreasonable. Your whole life, you’ve trusted one thing to save you. And saved you it has, again and again, without fail. That one thing is reason. Computers are a tool of reason, to be handled by people who obey the code of reason. People who are involved with computers, they’re reasonable, just like you. You all share a deep, unspoken bond. You’re all worshipers in the church of reason.
What advice would you give to someone starting out?
"You have to be prepared to give creative work 150%. I hear a lot of young people talking about life/work balance, which I think is great when you’re in your 30s. If you’re in your 20s and already talking about that, I don’t think you will achieve your goals. If you really want to build a powerful career, and make an impact, then you have to be prepared to put in blood, sweat, and tears. I don’t think everybody is willing to do that, but if you have the opportunity to do so, you should. That’s why many people go to graduate school in their late 20s: it forces them to devote intense time and focus to their work. It’s an experience that will change you forever."
A lot has been written about Heartbleed. Here are my two cents.
The problem is that all our modern computing infrastructure is written in a language, C, that was designed to be a thin layer over assembly and hence has no memory safety. A memory-safe language, which is to say, any modern post-C/C++ language, still allows writing buggy code that can be exploited—for example, look at the raft of SQL injection attacks in Java backends—but the bar for exploitation is much higher and the space of possible attacks much smaller when an attacker can’t turn array dereferences into a way to read and write arbitrary memory addresses.
Type and memory safe languages have existed for a while now. Language based security and static analysis is still a thriving research area, but it is also mature enough that a broad set of results and techniques have been found to be generally useful, many of which have even made it into mainstream languages and tools. Why then are we still in this state?
The two immediate answers that come to mind—improving the safety of C/C++, and writing infrastructure in safe languages—are, upon closer inspection,riddled with complexities.
Making C/C++ memory safe is possible, but it is not as simple as flipping a switch. There is a price to be paid in performance, of course, but even if one were willing to pay that, there might be scores of subtle behavior changes in code made safe this way. There is probably tons of code out there that depends on unsafe behavior.
Writing SSL in a safe(r) language is possible. But everything that would want to link it (browsers and web servers) is written in C. One could use cross-language calling facilities, but that is rarely clean due to impedance mismatches, and of course, that still leaves the calling code memory-unsafe. You’d have to rewrite all the net’s critical infrastructure in a safe language and runtime. That’s wishful thinking.
When physical infrastructure decays it is visible. A new road uses the latest knowledge and practices for building roads, not those from thirty years ago. Neither is the case for our computing and network infrastructure.
I recently read “The Second Machine Age” by Erik Brynjolfsson and Andrew McAfee. The major points the book makes—that information technology and digitization is exponential, that automation is rapidly expanding into even cognitive tasks that until recently were thought doable only by humans, that the digital worldwide economy rewards winners and leaves even close seconds in the dust—are all quite well-known by now, but the authors have tied them together with a narrative that makes the book a good single place to read about them.
I particularly looked forward to the chapter titled “Racing With The Machines: Recommendations for Individuals”, in which they suggest what kind of work will be left for humans to do, and what skills we should try and develop to stay ahead of automation. I really wanted to know if they had cracked the nut of how we would stay gainfully employed. I was disappointed.
The the authors looked at prior attempts by Levy and Murnane that tried to predict limits on what activities would still require humans. They said that computers are good at following rules and bad at pattern-recognition, giving the example of driving a car as being too cognitively and sensorially complex to be automated. As the authors say in the book: “so much for that distinction.” Then they go right ahead and make their own prediction of the next frontier that computers will be unable to cross:
Our recommendations about how people can remain valuable knowledge workers in the new machine age are straightforward: work to improve the skills of ideation, large-frame pattern recognition, and complex communication instead of just the three Rs. And whenever possible, take advantage of self-organizing learning environments, which have a track record of developing these skills in people.
The biggest problem with this advice is that it is skating to where the puck is, not where it is going to be.
The example they lean on the most is freestyle chess where teams of humans and chess programs compete against each other (hence the title of the chapter). It turns out that the combination of a chess program guided by a human is more powerful than either alone. Freestyle chess is also a central example in Tyler Cowen’s latest book. Unlike Brynjolfsson and McAfee, Cowen wonders if this is just a transitional phase, and if humans will ultimately not add any value in this pairing.
Their recommendation about “ideation” and “large-frame pattern recognition” is not concrete enough. What does that mean specifically for someone choosing a college major today? And more importantly, can we be sure that those activities will remain out of the reach of computers by the time they graduate?
The debate about whether human thought is computable is an open one, but the vast majority of human cognitive activity does not happen anywhere near that threshold. In an ironic similarity to the diagonal cut, perhaps the only people secure in their isolation from automation are mathematicians probing the bounds of what is computable, and how.
But each one of the rest of us has to wonder if, within our lifetimes, our jobs are automatable. I program for a living, and while a good fraction of what I do is intellectually challenging, there is also some that makes me feel like justanoperator.
Many non-technical authors think of Kasparov losing to Big Blue as a major milestone in AI, but that was largely due arriving at a point in time that Moore’s Law delivered enough computing beef to “solve” an exponentially complex game like chess. A more meaningful threshold would be when insight can be computed. For example, could a computer propose an algorithm with the simple elegance of Quicksort?
“Running with the machines” is a temporary strategy at best. That is simply the halfway house between humans doing something and it being fully automated. A more accurate phrase would be “run by the machines”, because cheap human labor is crowdsourced for the kinds of problems that are just barely outside a computer’s (current) reach.
I see two strategies for staying ahead of automation:
The first is to be the one doing the automation. In other words, to be a programmer. (Massive disclaimer: of course I would say that, being a programmer.) More bluntly, be the hunter instead of the hunted. The problem is that not everybody is able or willing to do that.
The second strategy is to be a doctor of machines. Large computing systems show organic behavior, and tending to them often requires the same mindset and behaviors as a doctor diagnosing and tending to patients. I like to draw an analogy to cities. A (relatively) small number of people initially construct the infrastructure (pipes, wires, roads), but a much larger number of people maintain them continuously.
1 - Net connectivity does not necessarily mean “thin client”. I can use net connectivity for data and still do a lot of processing on the client.
2 - The server/client power ratio doesn’t matter unless I’m actually trying to solve those large problems.
3 - There are some problems that need large machines and there are also some problems that could fit on either side. We’re not trying to figure out whether web search is going to be running on the phone. The real question is where the small things run.
4 - I do use my phone and tablet when I don’t have net connectivity. They are not bricks (maybe this is different in Androidland). Most of the things I do aren’t big problems. Even some previously big problems that only fit on a big computer now fit on my phone (like maps).
5 - Bandwidth and storage keeps getting better. Latency and availability aren’t improving much. Bandwidth and storage makes the “sync all my data among all my devices” model work for a larger and larger subset of my data. My data is not growing as quickly as storage, so I can see all my data fitting on my phone within a decade.
For any given problem, do I ever want to give up low latency and high availability to have it run on the server instead of my client? Generally, not unless it’s a much better experience to compensate for the slowness and unavailability. For most everything I do (text editing, word processing, photo processing, web browsing, games, email, social networking), it’s hard to justify.
Unfortunately most of today’s client apps are based on the old model assuming no networking. You email files around if you want to share. I think we can do much better by using synchronization among multiple clients as a fundamental building block. Data and compute stay local but when you have connectivity you synchronize with other places the data is stored. Google Wave was a stab at this. OneNote too, I think. Git does this for programming. DropBox is built on this model but it handles only simple synchronization at the moment. They have the potential to build infrastructure for apps to synchronize in a more structured way (like Wave), but I don’t know if they’re planning to do this.
[one of the authors] has had experiences facilitating web-based video dialogue, and even though she sees it could have enormous potential when it works well, very often it does not. When we learn online, we are not together in one room, and we need to recognize not only the limitations of that, but the openness of its possibilities.
The strengths of online learning, especially in massive courses such as MOOCs, and especially for adult learners, might lie in their asynchronous interactive components.
Despite protestations that they are backed by “decades of research,” these claims don’t actually have much supporting data. They are widely cited, but it turns out that very few people think it worth their time to locate the original sources of the research and check what the data actually said. I spent a few months doing just that for my book.
What I found was that these claims owed most of their popularity to what the webcomic xkcd dubbed “Citogenesis”.
The process goes like this: someone acknowledged as an Authority makes a fairly informal claim, like “defects cost exponentially more to fix over time.” Later authors, looking to borrow the Authority’s authority, refer to the claim as “research.” A further generation counts these indirect citations as if they were themselves original research: the claim now looks very strong, as it appears to be backed by multiple replications. Later “studies” of the same topic may take the result so much for granted that they dispense with actually collecting the relevant data, but will still be counted as additional confirmation.
Consider a process to decide who receives some award or benefit; and suppose we want to make sure the process is not biased against some disadvantaged group, which I’ll call Group G. If a person just makes the decision, we can ask them whether they were fair to members of Group G. Or we can ask them why decided the way they did. Either way, they can simply lie about their true motivation and process, to construct a story that is consistent with non-discrimination; or they might honestly believe their decision was fair even though it reflected unconscious bias. At the risk of massive understatement: history teaches that this kind of bias in human decision-making is difficult to prevent.
An algorithm, by contrast, cannot hide from everyone the details of how it reached its decision. If you want to know that an algorithm didn’t use information about a person’s Group G status, you can verify that the Group G status wasn’t provided to the algorithm. Or, if you prefer, you can re-run the algorithm with the Group G status field changed, to see if the result would have been different. Or you can collect statistics on whether certain parts of the algorithm have a disparate impact on Group G members as compared to the rest of the population.
Corporations can be thought of as information-processing feedback loops. They propose products, introduce them into the marketplace, learn from the performance of the products, and adjust. They do this while trying to maximize some value function, typically profit.
So why can’t they be completely automated? I mean that literally. Could we have software that carries out all those functions?
Software could propose new products within a design space. It could monitor the performance of those products in the marketplace, and then learn from the feedback and adjust accordingly, all while maximizing its value function. If the product is a webapp, most of these steps are already within the reach of full automation. For physical products, what’s missing is APIs that allow a program to order physical products, and move them around in the physical world.
A limited version of what I’m describing already exists. High-frequency trading firms are already pure software, mostly beyond human control or comprehension. The flash crash of 2010 demonstrated this. Companies that are centered around logistics, like FedEx or Walmart, can be already thought of as complex software entities where human worker bees carry out the machine’s instructions.
This happens naturally, because over time more and more of the business logic of a company becomes encoded in software. Humans still have some control (or so they think) but mostly what they’re doing is supplying parameters to the computation. A modern corporation is so complex that it does not fit in the brain of a single person (or a small number of persons). Software carries the slack.
The intermediate step to a fully automated corporation is one where tasks requiring humans are performed not by employees but are broken into micro-tasks and fulfilled by crowdsourcing (using, for example, services like Mechanical Turk).
I hypothesize that the management overhead which makes corporations grow sub-linearly is due to the limited information processing capability of individual humans. People at the top do not have local on-the-ground information: how are individual products performing, what are customers’ complaints etc. And the rank-and-file folks on the ground do not have the relevant high-level information: how does what I’m doing translate to the value that the corporation as a whole seeks to maximize? In fact, the the flow of value and information is so complex that employees have pretty much given up on determining that relationship, and know of it only at a macro P&L-center level.
An algorithm will have no such problems with acting on both global as well as fine-grained local information. In fact, I suspect that the more information it gets to act on, the better decisions it will make, making automatic corporations grow super-linearly.
One objection to being a purely automatic corporation might be that it precludes visionary, groundbreaking products, because it resembles incremental hill climbing and is susceptible to get stuck in local maxima. But a visionary, groundbreaking product is (initially) indistinguishable from picking a new random point in the product space, and hill-climbing from there. There is no reason why the automatic corporation couldn’t allocate some fraction of its resources to exploring new points in the space completely unrelated to its current neighborhood.
The CEO of an automatic corporation will be a devops engineer: fixing software bugs, writing “features” (i.e. new ways for the corporation to behave), watching performance dashboards (imagine all the pretty graphs!), and providing some vestige of human input to tune parameters used by the software. Eventually they can take their hands off the steering wheel, having configured everything to run on auto-pilot, and set up alerts to page their phone if something really goes wrong.
Automatic corporations will start within narrow domains, where the product design area and value functions are relatively simple. But they will gradually move upmarket. This is a familiar pattern in the dissemination of most new technologies. There will be a smattering of small automatic corporations by the end of the decade.
I’m growing increasingly frustrated with how little today’s patchwork of messaging/email and docs matches my workflow needs.
What I really need to keep track of are not emails and docs and appointments, but projects.
Imagine these emails/docs as pebbles, and each project as a collection of pebbles. This project is red pebbles. That one is blue pebbles. Yet another one is yellow pebbles. Then imagine throwing all of them on the floor. Then imagine being asked “can you construct for me a coherent state of all the yellow pebbles?” That’s how it feels trying get a high-level view of a project from all these pebbles flying around.
I feel like email and shared docs are like assembly language, and we need an abstraction above them. The analogy is fitting, because a high-level language is restrictive: you can do more things and have more control in assembly. But with the restriction comes freedom to express more complexity more succintly.
The problem with every project management solution that I’ve seen is this: it assumes it is the only thing in the world. “If you use this tool, and only this tool, and capture every little detail as it happens, then this tool will give you a coherent state of the world, yaaay!” Of course, life never works that way.
I’m not saying this is an easy problem to solve. I don’t even know what a first approximation of the solution would look like. But I do know there an opportunity here.
“The lighting field has its own Moore’s Law, an LED counterpart called Haitz’s Law. In 2000, Dr. Roland Haitz, then with Agilent Technologies, predicted that the cost of LED lighting will fall by a factor of 10, while “flux per lamp” (what we call brilliance or luminosity) will increase by a factor of 20 per decade. How long that trend will continue is also a matter of intense debate, but solid-state lighting (SSL) technology is based on semiconductor components, so the technology price fix is in, at least for now, and lighting is likely to keep getting cheaper.”—Drowning in light
But in a departure from his usually cold hard intellectual style, his recent piece about how the quality of light affects our work and our rhythms really tugged at my heart. A lot of that was because of the most powerful rhetoric device—nostalgia. Because I grew up in India in the 80s and 90s and also went through those load-shedding hours. It was inconvenience, boredom, excitement and respite all rolled into one.
Dark evenings without power were a special time for children. The candle-lit hours on porches and balconies were a strange mix of an ethereal kind of intimacy, beckoning darkness, and thoughts that retreated from both sunlight and electric lights.
You could do nothing useful during those hours. There was no TV or radio. Reading was difficult. Candle-lit meals tended to be either quick, simple affairs whipped up in semi-darkness, or leftovers. Families who turned the blacked-out evenings into family time generally sat out on the porch. Adults would use the time to tell family stories to children. Teenagers and some couples would stroll up and down the street, occasionally stopping to chat with neighbors. Younger kids would run around squealing and playing, seemingly possessed by the strange euphoria-inducing forces leaking in from another world. Or they would huddle together and try to scare each other with ghost stories.
It used to be that the platform on which most software was developed was also the one on which most of it was deployed—-the personal desktop computer. As a developer you only needed one machine.
Now, the target deployment platform is an app for a phone or tablet. But you still need a big desktop machine to develop them.
The first effect of this development-deployment divergence is that it cements the new position of the desktop as a specialized factory machine.
But another effect is that it raises the barrier to casual hacking. In the PC age a kid who wanted to write software just needed to download a bunch of simple tools and was off running. But today that kid would need to setup a complicated toolchain on a beefy desktop. And that too in an age when they think of desktops as something quaint, and might very well not even have one, because their “primary device” is just their phone or tablet.
Even the term “primary device” probably sounds funny to them. Growing up if someone asked me what my primary device was I’d laugh at them because my PC was my only device and it was all I needed or wanted.
So here’s my wish—-and challenge. Make it so that a young person who gets the urge can code and build something on their phone or tablet. I suspect it will be easier with the extra screen real estate on a tablet, but the big problem is the same. Make it so that some of that infinite interstitial time that their phone soaks up can be filled with programming. What if at the end of that Apple ad the teenager presented his family with a cool app rather than a movie?
If you look at features in mainstream programming languages over the last couple of decades, they seem to be converging around a common set of core features, surrounded by fashion, preference and whim. These core features are:
first class functions
lists and maps are part of the language
These features first originated in dynamically typed scripting languages like Python. (Well, they originated in Lisp, but then everything originated in Lisp.) Then they gradually found their way into statically typed compiled languages like C++1 and Java. Some of the most anticipated features of Java 8 are lambda expressions and type inference.
There is a subtle distinction between succinctness and expressivity. Expressivity almost always leads to succinct code. My favorite example is list comprehensions. But succinctness is also about omitting unnecessary verbiage. A good example is type inference enabling the omission of spelling out types.
Go had all three from the get-go.
Two things that are not yet part of this common core are objects and concurrency. I almost added “object orientation” to the list above, but then Go’s model of defining structs and interfaces made me think otherwise. It reminds me of Niklaus Wirth’s philosophy of understanding programs by looking at their data structures first. As for concurrency, there are wildly different ways of expressing it, but I have a hunch that the CSP model adopted by Go (and Erlang) will prevail. Maybe in another few years there will be five items on the list of common language features.
This is a good thing, because it looks like we’re gradually finding our way towards abstractions and constructs that are proving to be widely useful and broadly applicable. It is also rendering irrelevant many of the PL community’s fiercest debates. The agitation over static vs dynamic types starts fading when a C++ or Java code snippet with range-based for loops, lambdas and omitted type declarations looks very much like a Python or Ruby one. I was also surprised to see that while Go is very much a systems language, in chatting with other programmers I found Go eating more share from Java and Python than C++.
Yes, lists and maps are not technically part of the core C++ language, but of the STL, which is pretty fundamental to the actual use of C++. I wouldn’t be surprised if a future spec introduced core-language syntax for lists and maps. Same goes for Java. ↩
I’ve followed Kevin Kelly’s work for a while, and in my humble opinion he is our foremost apologist for technology. If you want an introduction to his work, this Edge interview is a dense yet readable summary.
I call myself a protopian, not a utopian. I believe in progress in an incremental way where every year it’s better than the year before but not by very much—just a micro amount. I don’t believe in utopia where there’s any kind of a world without problems brought on by technology. Every new technology creates almost as many problems that it solves. For most people that statement would suggest that technology is kind of a wash. It’s kind of neutral, because if you’re creating as many problems as it solves, then it’s a 50/50 wash, but the difference in my protopian view versus, say, a neutral view is that all these new technologies bring new possibilities that did not exist before, including the new possibility of doing harm versus good.
Many years ago, before I had a GPS-enabled smartphone with maps, we went on a roadtrip along the coast of Maine, stopping at nearly a dozen lighthouses. When I look back, I myself am surprised that I was able to pull that off without clutching my phone the whole way. But it was a memorable roadtrip. We saw all the lighthouses we wanted to see, and got a glorious experience of the Maine coast.
How did I navigate? In the days (weeks?) before the trip, I drew maps on paper of our entire route, with all the places we wanted to see. I used Google Maps as the source. It was probably tens of pages of hand-drawn maps. It was tedious, but it did have advantages:
I omitted unnecessary details. Just the streets I was going to be on.
I highlighted relevant details: landmarks, distances.
I wish I had saved that paper, because it would be a memento as evocative as the pictures from that trip.
(In 2001, LineDrive tried to address some of these issues by automatically generating driving directions in a style similar to hand-drawn maps.)
I tell you this story not to reminisce about my travels (well, maybe a little bit) but to point out that analog artifacts still have affordances that give them advantages over digital devices. Even today, for complex multi-hop trips I prefer to hand-draw maps on paper.
I want my digital interfaces to be more organic and analog, and my analog experiences to make it into my digital corpus effortlessly.
“In publishing, meanwhile, the deal with the customer has always been dead simple, and the advent of digital has not changed it: You pay the asking price, and we give you the whole thing. It would make little sense to break novels or biographies into pieces, and they’re not dependent on the advertising that has kept journalism and television artificially inexpensive and that deceives the consumer into thinking the content is inexpensive to make.”—The Publishing Industry is Thriving, by Evan Hughes
There’s a German word for it, of course: Sehnsucht, which translates as “addictive yearning.” This is, I think, what these sites evoke: the feeling of being addicted to longing for something; specifically being addicted to the feeling that something is missing or incomplete. The point is not the thing that is being longed for, but the feeling of longing for the thing. And that feeling is necessarily ambivalent, combining both positive and negative emotions.
Star Trek and Babylon 5 are two space operas that offer very different views of humans, technology and the relationship between them. That one is hugely popular, has entire conventions dedicated to it, still gets reruns and has spilled over into popular culture beyond just geek circles, while the other is likely to draw blank stares when one mentions it says a lot.
Star Trek is an expression of the idea that technology cleanses people. It is technology manifested outwards to people and society. And technology is clean and rational.
Star Trek depicts a clean world. Not just physically clean, but also emotionally and socially clean. There are no politics. (Did Picard ever have to contend for limited resources with other Star Fleet captains?) There is no heartbreak or jealousy. There is no class. There are no vices, no addictions, no crime. The Enterprise does not have a dark, seedy corner. There is no soul-searching. It’s telling that the non-human Data is often the most reflective character. Good and evil are clear. Star Fleet and everyone it in is good. All problems and all evil comes from the outside (Q, the Borg, other civilizations etc etc).
Babylon 5 is an expression of the idea that human nature is independent of technology. It is technology as one part of people and society. And people are messy and irrational.
Babylon 5 depicts a world of humans with all their failings. In it, technology has brought us far into space, but we are all still humans. Life is still messy and unpredictable and hard. Politics, within the humans, and among the space-faring races, is central. Society is stratified. There are haves and have-nots. It is not always clear which side is “right”. People experience joy, sorrow, heartbreak and the full range of human emotions. They battle demons and addictions.
Ben Thompson’s latest post is about Dropbox, Box and focusing on consumers vs enterprise as customers. I don’t have anything to say about that. I do, however, want to talk about his opening paragraphs:
The problem with the old thin client model was the assumption that processing power was scarce. In fact, Moore’s Law and the rise of ARM has made the exact opposite the case – processing is abundant…
…Thus, over the last few years as the number of fat clients has multiplied – phones, tablets, along with traditional computers – the idea of a thin client with processing on the server seems positively quaint; however, in the context of our data, that is the exact model more and more of us are using: centralized data easily accessible to multiple “fat” devices distinguished by their user experience.
Calling today’s phones and tablets “fat” is, I think, quaint. It is an easy trap to fall into. They are many orders of magnitude more powerful than those a decade ago. If the Palm Pilot was a thin client, certainly a modern iPhone cannot also be called “thin”.
But the thin client computing model was never about the absolute processing power, or lack thereof, of the clients. The crucial factor was the relative difference in processing power and storage between the client and the server. No matter how powerful the device we’re holding in our hands is, the warehouse-scale computer on which it depends is many, many more times more powerful. And without knowing what datacenters two decades ago looked like, I think it’s safe to say that the server/client power ratio has only increased over time, and is likely to continue increasing.
A smartphone or tablet’s impressive computing power goes largely into pushing pixels around, and giving us a great experience by responding quickly. It would be useless without all the backend services (app stores, cloud storage, social networks… the list is endless) it derives its usefulness from. A phone or tablet without net connectivity if pretty much a brick. And so, by definition, it “depends heavily on some other computer (its server) to fulfill its computational roles”.
Lately I’ve felt lost when in front of the computer. I feel like every time I turn to the screen, I’m at the bottom of a deep ravine and the sky is blocked off but for a thin strip between its high walls. I have to claw my way back to the top to see the lay of the land, and where I am located on it.
What was I doing? What do I need to do next? These are the most important questions when I’m working. And modern interfaces make it easy to lose track of them when I’m in the thick of it, and downright hard to answer them when I try to come back after a break, or an interruption.
The contours of my attention are varied and varying. They have peaks and valleys and plateaus. They are changing, rising and falling. Some things are central, some peripheral. Some things are important, some urgent, and some whimsical. Some peripheral things might be important. Some whimsical things might become central.
The modern UI does not know about the contours of my attention. It is a vast plain, with no distinguishing marks.
(Note that this is a different problem than that of being distracted, and being on a device where distraction is so easy. Not that I don’t suffer from that problem too but that’s a whole different story.)
I’ve taken to going analog. Writing things down. I got a couple of nice fountain pens that lightly tickle my nostalgia bone and that make me enjoy the sensual pleasure of putting wet ink on smooth paper. Underlines. Doodles. Boxes. Large writing. Small writing. They all tell a story. They all anchor thought, and recollect it.
Rather than the keyboard driving, I let the paper drive. I write tasks and designs and box and arrow diagrams. Then I go do one little thing on the computer. Then I come back to the paper. And so on. This is very similar to the idea of having an analog desk and a digital desk.
This is the next challenge in designing UIs: making them recognize and adjust to the contours of my attention.
“Being a computer science professional means more than just being a programmer. What does it take to become a successful professional in computing? Andy Begel and Beth Simon did a study computer science graduates newly hired as software developers at Microsoft. They found that the demands of the job had very little to do with what the students learned in their classes. The students’ classes gave them technical skills to design and develop, but mostly what the new hires did was to collaborate and debug.”—What’s Our Goal for a CS Degree, and How Do We Know We Got There?, by Mark Guzdial
So I finally got to use Go at work, which was a great excuse to learn the language. Here are some newbie impressions after all of three weeks with it.
the documentation is fantastic. Having a tutorial where one can execute (and edit!) the examples on the webpage itself really helps.
the syntax favors terseness. It is a relief after the chattering verboseness of something like Java. Types don’t need to be always declared and are inferred wherever possible. There are a few quirky choices: I didn’t think I’d see “:=” after I moved on from Pascal. And the biggest breakthrough of all: the automatic formatter “gofmt” saves Go programmers quintillions of hours in avoided debates about formatting style and micro-futzing with spacing in the editor.
concurrency is part of the language in the form of channels and goroutines. About time too, since we’re in the 21st century and threads cannot be implemented as a library(or at least, it’s always clunky when they are).
like Python, the cognitive size of the language is small enough to fit in one brain without constantly thrashing out. I write Go in an editor (Emacs), not an IDE, and that works just fine. With Java there was a heavy productivity hit to opting out of something like Eclipse and auto-complete. I felt like the IDE was an earth mover for code.
If one is writing a new system (especially a backend) from scratch that doesn’t have to call existing C++ or Java code (or only calls them via RPC), then Go is a pretty compelling option right now. That is great after a decade of no other viable options.
I never thought I’d say this, but its exhausting. Even worse, it’s boring.
Seeing as I make my living in the field, this conundrum spurred some soul-searching in me. I don’t want to be the software engineer who bitches and moans about tech.
My first computer had a monochrome (green!) monitor with a resolution of 720x348 pixels. Moving up to 4-bit color was a huge step up. Fast forward to today, with millions of colors and resolution indistinguishable from natural surfaces, what remains for flat displays to accomplish? The next interesting thing to do is take displays to places they haven’t been to yet, like inside your eyes.
Once displays crossed the threshold of human resolution, they were essentially “done”.
Something similar has now happened with computers. For the vast majority of users, specs like amount of RAM and CPU speed simply don’t matter any more. At some level, even individual computers don’t matter any more. What’s more interesting is what you can build with giant warehouses full of them. Capabilities like Google Now and Siri (powered by warehouse computers) have pushed what we can do with phones more than a faster SnapDragon processor.
And that’s the source of my ennui with CES. A lot of what they’re showing is pushing past the human resolution threshold. More of more. We need to go to new places, even if it is with less.
“If the Ph.D. was always about self-enrichment and not about carving out a career path, I should have treated it differently. I didn’t need to turn my life upside-down to put lines on my C.V. because no one outside academe, and not even those inside academe who would eventually hire me as an adjunct, would ever care to see them… If you’re really on the passion track, or even on the alt-ac track, and not on the secretly-hoping-for-tenure track, then take the pressure off and treat your scholarship like you would any other serious hobby: as something you value and enjoy but wouldn’t set above other things like your family or your job.”—Beware the Passion Track, by Deb Werrlein. The author is talking about humanities PhDs, but the point that one should mould their PhD experience according to what they want to do afterwards is true in general.
The widely cited statistic that one in three women ages 35 to 39 will not be pregnant after a year of trying, for instance, is based on an article published in 2004 in the journal Human Reproduction. Rarely mentioned is the source of the data: French birth records from 1670 to 1830. The chance of remaining childless—30 percent—was also calculated based on historical populations.
In other words, millions of women are being told when to get pregnant based on statistics from a time before electricity, antibiotics, or fertility treatment. Most people assume these numbers are based on large, well-conducted studies of modern women, but they are not.
I recently finished reading "The Distraction Addiction" by Alex Soojung-Kim Pang. It’s a comprehensive look at both the technology and human sides of why our devices and how we use them make us so scatterbrained. The refreshing angle is the even-handed focus on how to use both technology (better software and tools) and ourselves (being more mindful, cultivating better tech habits). The chapter on mindfulness and meditation gave me a perspective on it I hadn’t read before. He ended the book with eight principles, not tools and toys, for getting a better grip on our minds and our devices. Had me nodding my head in agreement throughout. Overall a good read, with tons of examples and perspectives from folks he spoke with.
If anything, I think he oversold parts of it, but that’s probably because someone who hangs out in my corner of the internet already knows that yes, we obsessively and compulsively use our connected devices, and yes, it hurts our focus and even our relationships, and yes, there are tools like Freedom and WriteRoom that claim to help.
I also wish he had delved a bit more into a word from the title of the book: addiction. About how we use our devices and connections in addictive ways, with no tangible benefit. About how, just like addiction to other substances, one needs to come face-to-face with the empty void that’s sucking them in before they come to their senses. How is a compulsive itch to swipe-to-unlock your phone different from a yearning for a shot of cocaine? You would’d sneak out a flask of whiskey from your jacket and take a swig in the middle of a meeting, but it’s completey acceptable to peek at your cellphone.
Reading the book reminded me and made me go back and read this manifesto for calm computing, written back in 1996. (At the risk of sounding pedantic, I’ll say that was a glaring omission from Pang’s citations). In it, the authors foresee our current crisis of attention, more than a full decade before the onslaught of net-connected smartphones. And they correctly identify the need for technologies that, as they say, “both encalm and inform.” The central principle they identify is that our interfaces need to show us both a center and its periphery, and appropriately move items between them. That’s what makes it not overwhelming when we perceive the natural world, or when we walk down a busy city street. Things naturally flow from the periphery to the center of our attention and back. Indeed, I know of no modern prevalent UI that does this, nearly two decades after the authors wrote this. Modern UIs are what I like to call attention-flat: everything is arranged on the screen either in a way that pulls attention equally (many windows visible) or in a way that completely obscures the periphery (one window maximized, hiding all others).
That makes me think there’s much more we can do on the technology front, particulary with UIs, to tackle the issue.
But there are readers and there are readers. There are people who read to anesthetize themselves—they read to induce a vivid, continuous, and risk-free daydream. They read for the same reason that people grab a glass of chardonnay—to put a light buzz on. The English major reads because, as rich as the one life he has may be, one life is not enough. He reads not to see the world through the eyes of other people but effectively tobecome other people. What is it like to be John Milton, Jane Austen, Chinua Achebe? What is it like to be them at their best, at the top of their games?
English majors want the joy of seeing the world through the eyes of people who—let us admit it—are more sensitive, more articulate, shrewder, sharper, more alive than they themselves are. The experience of merging minds and hearts with Proust or James or Austen makes you see that there is more to the world than you had ever imagined. You see that life is bigger, sweeter, more tragic and intense—more alive with meaning than you had thought.
“When humans team up with computers to play chess, the humans who do best are not necessarily the strongest players. They’re the ones who are modest, and who know when to listen to the computer. Often, what the human adds is knowledge of when the computer needs to look more deeply. If you’re a really good freestyle player, you consult a bunch of different programs, which have different properties, and you analyze the game position on all of them. You try to spot, very quickly, where the programs disagree, and you tell them to look more deeply there. They may disagree along a number of lines, and then you have to make some judgments. That’s hard—but the good humans do that better than computers do. Even very strong computers don’t have that meta-rational sense of when things are ambiguous. Today, the human-plus-machine teams are better than machines by themselves. It shows how there may always be room for a human element.”—Tyler Cowen
There is endless debate about the characteristics of each generation, but how can one assign characteristics to something as broad as an entire set of humans born in three designated decades? But one can at least try to assign characteristics to their times.
I feel like part of neither Gen X nor the millennials. Gen X feels too old, more like my parents’ generation. And most millennials feel too young.
I feel like part of the analog-digital generation. I’m calling it Generation AD. The generation before was firmly analog. The generation after are digital natives. Generation AD is the confused one in the middle.
I define Generation AD to consist of those who spent their early youth (approximately up to high school) living a largely analog lifestyle, and transitioned to a largely digital one thereafter.
The internet had not caught on when they were young. There wasn’t a cellphone in everyone’s hands. No screens in the classroom! They had to call their friends on landline phones, make concrete plans about when and where to meet, and then go there. They learned cursive handwriting in school. They were taught that penmanship was important.
And then, by the time they were in their late teens and early twenties, a giant switch got flipped in the span of a few years. The internet exploded. Mobile devices proliferated. Digital took over. Typing replace handwriting. Cellphones meant everything could be planned in real time and nothing needed to be planned of ahead of time.
Generation AD deeply understands the advantages of being cleanly digital, and yet feels a nostalgic pull to analog things like pens and paper. This results in Frankenstein workflows like making heavy use of notebooks… and then scanning them for posterity. Bits, after all, are much lighter than atoms, and moving a hard disk is much easier than lugging boxes of notebooks.
Generation AD is the last and only one familiar enough with both sides of the digital/analog divide to truly reason about each. Gen X is analog at heart and puts up with digital life mostly because it has to. Millennials skipped analog altogether. Neither are in a position to produce nuanced critiques of our digital lifestyles. Only Gen AD knows which nooks and crannies analog fills better, and hence truly appreciates those where going digital has more impact. Gen AD consists of people who remember concepts or quotes from books spatially (“it was on the top of the left page, somewhere near the middle of the book”), but who will gladly ditch the dead-tree version and sling their tablets when they travel.
“Most days, Nicholson Baker rises at 4 a.m. to write at his home in South Berwick, Maine. Leaving the lights off, he sets his laptop screen to black and the text to gray, so that the darkness is uninterrupted. After a couple of hours of writing in what he calls a dreamlike state, he goes back to bed, then rises at 8:30 to edit his work.”—How to write a great novel.