{"id":766,"date":"2013-05-13T18:19:20","date_gmt":"2013-05-13T22:19:20","guid":{"rendered":"http:\/\/alarmingdevelopment.org\/?p=766"},"modified":"2013-05-13T18:19:20","modified_gmt":"2013-05-13T22:19:20","slug":"getting-to-simple","status":"publish","type":"post","link":"https:\/\/alarmingdevelopment.org\/?p=766","title":{"rendered":"Getting to simple"},"content":{"rendered":"<p>There is one gigantic problem with programming today, a problem so large that it dwarfs all others. Yet it is a problem that almost no one is willing to admit, much less talk about. It is easy to illustrate:<\/p>\n<p><!--more--><\/p>\n<p><a href=\"http:\/\/alarmingdevelopment.org\/wp-content\/uploads\/2013\/05\/books-web.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-768 aligncenter\" alt=\"books-web\" src=\"http:\/\/alarmingdevelopment.org\/wp-content\/uploads\/2013\/05\/books-web-76x300.jpg\" width=\"76\" height=\"300\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: left;\">Too goddamn much crap to learn! A competent programmer must master an absurd quantity of knowledge. If you print it all out it must be hundreds of thousands of pages of documentation. It is inhuman: only freaks like myself can absorb such mind boggling quantities of information and still function. I wager that compared to other engineering disciplines, programmers must master at least ten times as much knowledge to attain competence.<\/p>\n<p style=\"text-align: left;\">The tragedy is that this problem is not inherent in the nature of software: it is largely our own fault. There are many reasons for this tragedy but as usual in such societal failures they boil down to the fact that the people with the power to change things have a vested interest in not doing so. But that is a topic for another discussion. For the moment I just want to define the problem.<\/p>\n<p style=\"text-align: left;\">I conjecture that in order to fix the problem we first have to be able to quantify it. Everyone gives lip service to simplicity. Then they use C++. We need an objective measure of what makes programming hard in order to hold people accountable and make progress. I want to propose a simple approximate measure of programming difficulty:<\/p>\n<p style=\"text-align: center;\"><strong>Difficulty = pages of reference documentation<\/strong><\/p>\n<p style=\"text-align: left;\">In other words, the height of that stack of manuals pictured earlier. Let me qualify this definition a bit. This measures the complete documentation of a programming technology for programmers to fully understand and use it. Not tutorials. Not guides. Not code comments.<\/p>\n<p style=\"text-align: left;\">Clearly this is an imperfect approximation. An average page of the C++ manual contains a lot more knowledge presented a lot more more obscurely than an average page of the Lua manual. So the nominal 12x page ratio underestimates the actual difference. On the other hand, regular expressions are\u00a0documented very precisely and concisely despite being tortuous to use. Nevertheless I want to suggest that on the whole documentation size is a reasonable approximation of how hard it is to program. More importantly, it is the only such measure I know of. I welcome better alternatives.<\/p>\n<p style=\"text-align: left;\">I have found this metric\u00a0quite helpful in my own work. All designers agree that simplicity is crucial, but how do we tell when we are in the trenches fighting with different designs of a language or API? Thinking about documenting the design to its users is a good way to clarify things. Whatever makes the documentation shortest is the best.<\/p>\n<p style=\"text-align: left;\">Perhaps this metric could also help solve a big problem with computer science research: simplicity is not a result. \u00a0We can&#8217;t publish papers claiming that one language or tool is simpler than another, because there is no &#8220;scientific&#8221; way to evaluate that claim, other than empirical user studies which are essentially impossible. That is why CS research focuses on hard results like performance and theory. If researchers could accept documentation size as an approximate measure of difficulty we might be able to at least discuss the issue.<\/p>\n<p style=\"text-align: left;\">But none of that really matters. What really matters is what this metric tells us about the future of programming. By far the most effective thing we can do to improve programming is:<\/p>\n<p style=\"text-align: center;\"><strong>Shrink the stack!<\/strong><\/p>\n<p style=\"text-align: left;\">I am talking about the whole stack of knowledge we must master from the day we start programming. The best and perhaps only way to make programming easier is to dramatically lower the learning curve. Now hold on to your seats, because I am going to break the most sacred taboo of our field. To shrink the stack we will have to <strong>throw shit away<\/strong>. Heresy! No one wants to even talk about it, much less risk their careers on it. Well, not quite no one:\u00a0Alan Kay has been a lone voice in the wilderness saying this for decades.<\/p>\n<p style=\"text-align: left;\">What we need is revolutionary thinking. Revolutionary in the sense of paradigm-shifting ideas, and revolutionary in the sense of angry citizens overthrowing corrupt regimes.<\/p>\n<p style=\"text-align: center;\"><strong>Programmers of the world, unite!<br \/>\nYou have nothing to lose but your docs.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>There is one gigantic problem with programming today, a problem so large that it dwarfs all others. Yet it is a problem that almost no one is willing to admit, much less talk about. It is easy to illustrate:<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[2,1],"tags":[],"class_list":["post-766","post","type-post","status-publish","format-standard","hentry","category-agitprop","category-general"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pfEnU-cm","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/766","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=766"}],"version-history":[{"count":26,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/766\/revisions"}],"predecessor-version":[{"id":794,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/766\/revisions\/794"}],"wp:attachment":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}