Software Futurism2016-05-29T07:08:16+00:00http://aisipos.github.ioAnton I. SiposProgramming Workflow2012-01-31T23:01:44+00:00http://aisipos.github.io/2012/programming-workflow<p>Programmers are much enamored with their programming languages. Some so much so that it often defines what programmers are; you may hear “I am a Java programmer”, for instance. This runs deeper than we think. Often without realizing it, we are tied not only to the language but also its implementation. The implementation, rather than the language itself, imposes a workflow on how we write programs in the language, one that we usually do not see beyond.</p>
<p>For some time now, the most popular workflow of mainstream languages has been the familiar “edit, compile, run” (ECR) cycle. It has become so ingrained in many of us that we have forgotten other workflows, or worse never learned that any others exist. It was not always so. Popular languages of the past and present have included a different workflow, the “read, eval, print loop” (REPL). For myself, my first programming language was BASIC. My first programming prompt was a REPL.</p>
<p>Often when judging the merits of a language, we focus on the features of the language itself, rather than its implementation and workflows. This is dangerous, since the features of the language are only a part of what makes a programmer productive. The workflow of how you interact with a language is as much important as the language itself. Since many of us are used to only one workflow, more often than not that venerable “edit, compile, run” cycle, we have stopped looking for innovation in how we interact with programming languages.</p>
<p>With ECR, everything is a <strong>program</strong>. In order to get the computer to do something, you must edit a whole program (whether new or a modified old one), compile it, run it, rinse, lather, and repeat. This is a lot of effort for tasks that are very small. This is also a lot of effort when you need to experiment or tweak with small bits of code. Sometimes you only want to know the output of one function for one input. Sometimes you just need to get the base64 encoding of a string.</p>
<p>A REPL allows you to interact with the language one <strong>statement</strong> at a time. You can interact out of nothing, if you are just getting started on an idea, or you can interact with an existing program, one statement at a time. Feedback is usually instant. Writing a program with a REPL still means writing a program. But if you need something done that only requires one statement, then one statement is all you need. You cannot use just one statement with ECR. Small tasks become difficult with ECR, causing them more often than not to be skipped.</p>
<p>REPLs by their nature are interpreters. Because of this, they are typically only provided with interpreted languages. But interpretation versus compilation is merely an implementation detail. All languages can in theory be interpreted. Thus all languages could in principle offer a REPL. REPLs having a long tradition, heralding back to LISP and BASIC, both old languages. But with the rise of compiled languages, primarily C, C++, and Java, the REPL was largely forgotten by a generation of programmers. The “dynamic languages” such as Perl, Python, Ruby, and Javascript have brought a resurgence of the REPL, but not all programmers have explored the dynamic language world.</p>
<p>There’s no reason to not ship a REPL with modern compiled languages such as C# or Java. Mono in fact ships <a href="http://www.mono-project.com/CsharpRepl">C# REPL</a>, and <a href="http://www.beanshell.org/">BeanShell</a> exists for Java. But merely providing a REPL is no guarantee that the masses will use it. Long exposure to the ECR for a generation of programmers has lulled us to sleep. Programmers used to the ECR in compiled languages are often amazed at REPL demos in their favorite language <a href="#note-37-1" title="http://blog.jonudell.net/2007/09/27/first-look-at-resolver-an-ironpython-based-spreadsheet/"><sup>1</sup></a>, but immediately go back to ingrained habits. We are too enamored with our tools, and the mindsets they put us into.</p>
<p>The natural question that a Software Futurist might ask is, is there anything available more advanced than the REPL? The answer is yes. There is a slight variant of the REPL, the “notebook” interface. A notebook interface allows you to go back in your command history to change a statement and see the changed output. The REPL was designed in the days of teletypes- think of the REPL as like a long fixed interaction with the computer printed on paper. The Notebook interface allows you to go back to any point and make changes. While this seems like a minor advance, it really does make iterative development easier. Notebooks have long been a staple of mathematical systems, like Mathematica, but has been working its way into other languages like Python.</p>
<p>While the notebook has advantes over a REPL, it is not a fundamental shift. For that, as we often do we have to look to the past rather than the future – Smalltalk.</p>
<p>Smalltalk implementations offer what is called “the <strong>Image</strong>“. It is a fundamentally different paradigm than ECR or the REPL. With the Image, you start a running instance of a complete environment. The Image contains the live objects of your program, as well as the development environment. You make changes to these live objects, or make new live objects, interactively with the development environment. This can be done textually, or graphically depending on what tools you choose to use and what is available at the time. Think of it as “sculpting” a collection of live objects. Once the live objects have reached a point you consider ready, you can freeze the Image, copy it and deploy it wherever you like. In Smalltalk, you work primarily with objects, rather than primarily with text.</p>
<p>So far as I know, this interaction paradigm is unique to smalltalk. Dan Ingalls, one of the creators of Smalltalk, has attempted to bring it to the Javascript language in a project called the <a href="http://www.lively-kernel.org/" title="Lively Kernel" target="_blank">Lively Kernel</a>. It is a laudable effort, but sadly few seem to be paying attention. Just as we have been lulled to sleep by ECR, the current generation seems to have been lulled to sleep by the REPL.</p>
<p>It remains to be seen if Image based programming is an advance on the REPL. Certainly it is essentially unknown outside the Smalltalk world, itself a fringe language by today’s standards. It is likely hampered by its all or nothing nature; the entire development environment must be implemented in Smalltalk, inside the Image. Entire ecosystems of supposedly language agnostic tools are thus unable to interact with it – source control tools, documentation generators, indexers. But as least the Image is a creative idea, one designed after the lessons of both ECR and the REPL. I haven’t seen such originality in other interaction paradigms. It’s originality that’s desperately needed if we are to design tools that will make any real leaps in productivity in the future.</p>
<p>Addendum:</p>
<p><a href="http://worrydream.com" title="Brett Victor" target="_blank">Brett Victor</a> gave a great <a href="http://vimeo.com/36579366" title="talk" target="_blank">talk</a> talk that touched on this at CUSEC 2012. His guiding principle is the requirement of immediate feedback. He rightly points out that the REPL is a recreation of the teletype, a now obsolete relic from the 1970’s. He gives demonstrations of several javascript programming environments of his own creation, all of which allow you to vary parameters as you edit code and see the results immediately.</p>
<p><a href="http://subtextual.org/" title="Subtext" target="_blank">Subtext</a> is another post-REPL environment, where code and data are edited in an environment with immediate feedback. He states in his <a href="http://alarmingdevelopment.org/?p=5" title="manifesto" target="_blank">manifesto</a> “The language <em>is</em> the IDE” (emphasis mine)</p>
<div class="simple-footnotes">
<p class="notes">
Notes:
</p>
<ol>
<li id="note-37-1">
<a href="http://blog.jonudell.net/2007/09/27/first-look-at-resolver-an-ironpython-based-spreadsheet/" title="http://blog.jonudell.net/2007/09/27/first-look-at-resolver-an-ironpython-based-spreadsheet/">http://blog.jonudell.net/2007/09/27/first-look-at-resolver-an-ironpython-based-spreadsheet/</a> <a href="#return-note-37-1">↩</a>
</li>
</ol>
</div>
The Web is not the Net2010-02-12T01:18:34+00:00http://aisipos.github.io/2010/the-web-is-not-the-net<p>A while back you would still hear a lot of talk about Web 2.0. It’s exciting to a lot of people, but I am troubled by it. It strikes me as a very rigid form of constrained thinking, coloring in the lines. If you insist on buzzwords, I’m not so much interested in Web 2.0 as I am in Net 2.0.</p>
<p>We seem to have forgotten that the Web is only one application of the Internet, or Net for short. There was a time when the Web didn’t exist, when we used the Net for other things. Telnet (and its modern avatar SSH), FTP, Email, News, and IRC all come to mind. These are still around, but to varying degrees have lost the importance they once had. Email is still going strong, but there are competitors starting to chip away at it making its future dominance unclear. The same will be true for the Web some day. Today, the Web certainly dominates the Net in the amount of time spent using it, even if it doesn’t dominate number of bytes transferred. Its dominance is reflected in the fact that we tend to conflate the terms Net and Web. However, there’s good reason to believe that this will not be the case eventually. The Net has changed before, and it will change again. The Web is not the Net. Who will be the next <a href="http://en.wikipedia.org/wiki/Gopher_%28protocol%29">Gopher</a>?</p>
<p>I should point out, the inventor of the Web, Tim Berners Lee, has some thoughts on the difference between the Web and the Net <a href="http://dig.csail.mit.edu/breadcrumbs/node/215">himself</a>. He foresees the need for a Semantic Web, which he would rather be called a “Giant Global Graph”. I’m not here to disagree with him, I’m merely trying to suggest we need to open our eyes as wide as possible. In fact, I do believe the Semantic Web, with a more computer centric focus rather than human focus, will be an area that will provide us with some large advances in computing. But it is not the horizon, it is only another step along the way.</p>
<p>The Web was designed to deliver us a “web” of hyperlinked documents, containing text and images, each with an address. It does this quite well. Originally Tim Berners Lee conceived of a more <em>write</em> as well as <em>read</em> medium, which is what I believe the original intent of the HTTP POST verb was. The Web never really got this “produce as well as consume” spirit, until wiki’s came around. Wikipedia showed what you could accomplish with true read and write collaboration of hyperlinked documents. It would not be possible to replicate the success of Wikipedia without its technological underpinning of the wiki augmented Web. When used appropriately, the Web is a great medium to both produce and consume content on.</p>
<p>But is the Web the pinnacle of what the Net can do? Are there things the Web doesn’t do well? In the beginning there were HTML and HTTP. As people tried to use the Web for newer things the boundaries of what was possible made themselves felt very sharply. A litany of supporting technologies emerged: Cookies, Javascript, CSS, Keep Alives, XmlHttpRequest, and very recently <a href="http://dev.w3.org/html5/websockets/">Web Sockets</a> and HTML5. The incoherent result can only be politely called a hack. This isn’t even counting the separate closed technologies such as Flash and Silverlight that live within Web pages yet are from a technological standpoint only strange guests, living in HTTP requests but only participating in the Web stack indirectly. Adding to the difficulty is that your platform, the Web “Browser”, is usually implemented incompatibly in the most insidious of ways. To develop for the Net these days usually means being a “web developer”, and it is sadly often a painful experience as a result.</p>
<p>The web was intended for <em>documents</em>, but often we use it for <em>applications</em>. Gmail and Turbotax are examples of applications, not documents. Yet they are built with Web technologies, with their document centric focus. This technological mismatch makes itself painfully felt in many ways. The phrase “don’t hit your browser’s back button” is laughable but still all too common symptom of this mismatch. There are protocols designed to build applications that can be consumed remotely over the Net. <a href="http://en.wikipedia.org/wiki/X_Window_System">X</a> is one such example. X served its purpose for many years- the ability to consume a graphical application running on a remote server. X is now an ancient technology, new thinking is sorely needed in this area. The web development world is now focused on building Single Page Apps, but these are still built on a HTML/HTTP foundation, with all of the limitations inherent to them.</p>
<p>There are interesting projects attempting to rethink web development from the ground up. One example is the <a href="http://www.lively-kernel.org/">Lively Kernel</a>, Dan Ingall’s attempt to preach the Smalltalk gospel to the Web generation using Javascript. Sadly, just like Smalltalk these days, even with the new Javascript clothes not many people seem to be paying much attention.</p>
<p>What if we agreed we didn’t have to make everything a web page? What if we were designing a collaboration medium from scratch on the Net? What if we removed all the limits? You might consider that such a medium would be a full 3-d environment with graphics and sound, in a deliberate mimic of the real world. Such media exist on the net, commercially with <a href="http://www.secondlife.com">Second Life</a>, in research with <a href="http://www.opencroquet.org/index.php/Main_Page">Croquet</a>. These media can display documents, just like the web can, and can address them too, but aren’t limited to documents alone. These media are not the pinnacle of what we might use the Net for. But they do show us that there we can use the Net for things beyond just email and hyperlinked documents. I’m not recommending these platforms themselves. What I am recommending is the wider viewpoint they take.</p>
<p>Skeptics to new Net technologies may point out that the Browser has become a universal consumer for Net content, and that any new medium on the Neb not viewable in a browser is a non-starter. In the days of slow internet connections, when it wasn’t possible or easy to download a large client program quickly, this was true. Today however, with fast broadband connections in the home more the norm, if your content is good enough users will download the needed client. Second Life and Croquet require downloads. Games, which are increasingly social on-line applications these days, require downloads or purchasing a box in the store. Some games are so addictive that people actually <a href="http://kotaku.com/350895/blizzard-loots-12-billion-from-2007-thanks-to-wow">pay real money</a> to download their large fat clients. Your new idea will be the same, it doesn’t have to be shoehorned into “the Browser”.</p>
<p>Despite its faults, it’s obvious to see why the Web gets so much attention. It’s made some people very rich, and made many others a comfortable living, myself included. So long as this is true, people will continue to develop for and use the Web. As is so often the case, money trumps technical concerns. Even today, I see so many small companies trying to re-inflate the “.com” bubble, believing that any idea will sell merely because it is on “the Web”. But in the increasingly crowded space of today’s Web, the crowding brings in inherent competition which means making money is far from guaranteed. Some day, a new killer application will appear that doesn’t use the Web, and the innovator will make a fortune as a result. The copycats will come in, and the cycle will repeat.</p>
<p>I have no doubt that the Web will improve as time goes on. WebSockets, WebRTC, HTML5, ES5, these are all useful advances. But do we still have to see everything through the lens of a markup language and a stateless textual transfer protocol? A little revolution every now and then is a good thing.</p>
Credo2009-08-02T12:58:39+00:00http://aisipos.github.io/2009/credo<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
<p style="margin-bottom: 0in;">
<em><strong>Credo</strong></em>
</p>
<p style="margin-bottom: 0in;">
<p style="margin-bottom: 0in; font-style: normal; text-align: center;">
<strong>Computer</strong><span style="font-weight: normal;">. </span><em><span style="font-weight: normal;">n. </span></em><span style="font-weight: normal;">A device for saving human labor.</span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;">Often computer science literature talks about what and how, but not so much about </span><em><span style="font-weight: normal;">why</span></em><span style="font-weight: normal;">. Computers are meant to make our lives easier. If they fail in this task, we are better off burning the lot of them.</span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;">When viewed as a whole, computers have saved us countless volumes of time and enabled the human mind to achieve feats previously thought impossible. Even more importantly they have allowed us to achieve feats previously not even anticpated or imagined. </span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;">However, the picture is not always this rosy. For many of us, much of our day is spent on front of the computer. The computer should be serving us. All too often though we feel like we are serving the computer. The computer should always </span><em><span style="font-weight: normal;">save </span></em><span style="font-weight: normal;">work for us but often it </span><em><span style="font-weight: normal;">creates </span></em><span style="font-weight: normal;">work for us. We throw up our hands and assume this is the way of things.</span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;"><strong> It doesn’t need to be this way. </strong>The computer is our creation. When it isn’t serving our needs we must step back and figure out how to make it serve us.</span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;">We must remember that computers are only a means to an </span><em><span style="font-weight: normal;">end</span></em><span style="font-weight: normal;">. They are not the end in themselves. Edsger Dijkstra famously summed this up as “Computer science is no more about computers than astronomy is about telescopes”. We have become to complacent in our view of computers. Some of us do not remember a time before computers, and assume that the form they take and the way they operate isn’t open to change. We must remember the computer should adapt to serve us, and that everything about it is open to change.</span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal; font-weight: normal;">
Much industrial computer science these days amounts to a “paint by the numbers” approach. We follow methodologies blindly, only rating ourselves on how closely we follow the method, rather than analyzing how well we are achieving our actual goals. Good software engineering is difficult, so we use methodologies as crutches to make us think we are treading correctly when in reality we are blindly going down the wrong road. Software engineering is a creative endeavor. No amount of fixed methodologies will change that. To achieve something novel and useful will require creative thinking. The computer has no creative powers. By removing the creative element from software engineering we are removing the possibility of real advances in the craft. </p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;">How then are we as programmers going to make computers improve our lives? To start we must never lose sight of the </span><em><span style="font-weight: normal;">why</span></em><span style="font-weight: normal;">: save us labor. Saving us labor saves us time. And the old adage tells us what time is: if you’re good at making the computer save time, you can make a lot of money. Money is a powerful motivator, but it’s not the only motivator. More so than money, saving us time frees us up for other pursuits. By doing the grunt work the computer liberates us to do the creative work. And since computer science is as much an art as a science, you could say computer science is a </span><em><span style="font-weight: normal;">liberal art.</span></em><span style="font-weight: normal;"> </span>
</p>
<p style="margin-top: 0.16in; margin-bottom: 0in; font-style: normal;">
<span style="font-weight: normal;">These of course are reasons </span><em><span style="font-weight: normal;">why</span></em><span style="font-weight: normal;"> we must sharpen our skills as computer programmers and computer scientists. Well then, </span><em><span style="font-weight: normal;">how</span></em><span style="font-weight: normal;"> are we to go about it? There’s no one single way, good old creativity and ingenuity will have to power our way. Let’s explore </span><em><span style="font-weight: normal;">how</span></em><span style="font-weight: normal;"> in upcoming writings, but never forgetting </span><em><span style="font-weight: normal;">why.</span></em>
</p>
</p>