Sustainability affects the long-term operation of systems. Computer programming, in particular specific programming languages constitute a system whose sustainability can be analyzed. What makes a programming language sustainable?
- Code written once functions for a long time
- The design of the language makes it easy for non-fanatics to use it in programming
- The code produced executes efficiently
- The presentation of the language (how it looks on a page when pretty-printed) lends itself to understanding
A few general observations:
Markup languages like HTML and CSS are quickly understood by a wide variety of people, ranging from fine artists to engineers. The accessibility and usability of these languages is the main reason the web grew. If, instead, the web had been some collection of Java applications, like those on early mobiles, the Internet ecosystem would have been very different. In contrast to HTML, Java is difficult to learn, and the concepts required to program are non-visual, abstract things not easily understood by designers.
A “Java” web would have been very poor in sites, and those sites would likely have been created by large corporations from the start – just like the pre-iPhone app Java world of the early mobile web. HTML and CSS earn massive points for sustainability by increasing the number of programmers, and allowing them to develop ideas as individuals or small groups instead of large teams. We saw this happen with mobile – in contrast to the open web of a million sites, we had walled gardens with a few centrally-planned programs available in “stores” to mobile subscribers.
But HTML won, and its durability demonstrated long-term sustainability as a programming environment. In fact, it was so easy that by the early 2000s the web had entered a sort of stasis – the 90% dominance of Internet Explorer (which I call the IcE Age) meant that there was little change in the languages. Interestingly, design on the web also stopped, and many web pages in 2006 looked like they had in 2001. The arrival of the iPhone and the “forcing” of HTML5, broke the logjam. Today, contrary to beliefs that we are entering a “code free world”, HTML looks more robust and long-term than ever. I expect that there will still be substantial number of HTML/CSS developers in 2020, and I wouldn’t be surprised if the same was true in 2050.
Based on this, PHP is not bad (which is what you hear from Python people) but unsustainable. It is hard to see how the language can evolve from its current messy state to a regular, standardized form. The enormous number of overlapping functions may in time create a “combinatorial explosion” which will make the language too hard to program without tripping up some server environments. The language’s origin in open-source ensures that more stuff will be loaded into it, but making the language more stable in the long run is less likely.
In a future post I’ll consider what formal features of programming languages confer sustainability (hint: I can code in an hour or two) but now let’s move to two posts from Strangeloop.
The first adds up wasted time waiting for slow websites, and asks, “Does the Average Web User Wait 2 Days a Year for Downloads?” The most interesting result of this study is that people feel the web is slower than it actually is – and slow sites are seen as even slower than they actually are. This calls into question the use of statistics for download times – User Experience (Ux), focusing on perceived downloads are more important. And, from a user perspective, they are. Each second waiting for a download makes the person less efficient – and the wasted time implicitly impacts all web users in their daily life. That is to say, the indirect result of slow pages is a downstream decrease in efficiency during daily (physical) life. This is a great example of why sustainability is more than numbers, and making a sustainable site is more than optimizing a software engine. Changes in the way the site works (e.g. an offline mode) could increase user efficiency without requiring the Internet to be upgraded. The design of the overall system, rather than an individual speed metric, is most important.
The second post is also interesting. In the tradition of other physical features of the world mapped to the virtual one, Strangeloop discusses the “performance poverty line“. In the words of the author:
The performance poverty line is the plateau at which load time ceases to matter because you’ve hit close to rock bottom in terms of business metrics. If your pages are below the performance poverty line, making them a couple of seconds faster doesn’t help your business.
Plots of user behavior versus download time (or time to view a full web page) show a hyberbolic curve. This means that they react more as a page slows – but only up to a point. After that cutoff, slower speeds don’t affect behavior – the user has shifted from a someone accomplishing something to one mired in “the world wide wait”. This is the point where the user no longer feels in control, and instead sees themselves as dominated by the slow-moving system. It is a shift from active to passive behavior. This point of no return is around 8 seconds, comparable to the oft-quoted “7 second rule” for home page loads. What’s interesting from a sustainability level is what people do when waits become long. My guess is that they become less productive overall, and this shift happens at about 8 seconds. It’s like the difference between walking in sand versus heavy mud – in one case, you keep walking, even if more slowly, while in the other you have to shift to a new, ultra slow motion pulling feet from the mire.
Along with the 8-second rule, a second rule under 1 second has been identified. Possibly due to fast-acting non-web programs (“twitch” games reacting to the user in milliseconds come to mind), users react negatively to sites that take even a half a second to load. An article in the New York Times quotes both Google and Microsoft engineers as saying that the magic number is close to 1/4 of a second – anything longer, and users do less on the web. Since the web needs the same amount of power to run whether or not users are waiting, this is a significant issue. According to some studies, impatience may be rising as an increasingly-ADD Millennial generation becomes a major user of the business web. From the article:
In 2009, a study by Forrester Research found that online shoppers expected pages to load in two seconds or fewer — and at three seconds, a large share abandon the site. Only three years earlier a similar Forrester study found the average expectations for page load times were four seconds or fewer.
It’s too bad that the discussion is purely on speed. Speed doesn’t solve everything, and the real issue is the ability of web users to accomplish tasks efficiently. For many online tasks, waits of a few seconds are not important – but for others, speed is all important. We can improve the sustainability of the web by using design, market research, and user experience studies to determine where we need speed.