Building SeaTurtle, a Logo-like Language in Swift and SpriteKit

Today, my programming environment for teaching coding to young people, SeaTurtle, was released on the Mac App Store. SeaTurtle is inspired by the languages that were popular on microcomputers in education for teaching programming in the 1980s—Logo and BASIC. Like these languages, SeaTurtle has a very simple and approachable syntax. And like Logo in particular, SeaTurtle is centered on turtle graphics. My aim in this post is to explain what SeaTurtle is and then give you some insight into how I built it.

While most Logo programs can be fairly easily translated into SeaTurtle, SeaTurtle is not a version of Logo. It has a slightly different syntax, which in my opinion is even simpler. For example, there are no special characters in the SeaTurtle programming language. There are some other simplifications: all variables are global, variables can only hold integers, and variable and subroutine names are case-insensitive. Some experienced programmers might scoff, but SeaTurtle is purposely an extremely simple programming language. These simplifications might seem like they’re teaching bad practices, but the goal is to eliminate whole classes of beginner programming errors and not give them enough features to become overwhelmed.

In my opinion, SeaTurtle is the absolute least featureful and most basic syntax programming language you can have that is still fun to use and can serve its essential function: inspiring young people to learn coding. SeaTurtle has just enough syntax to teach important concepts like variables, loops, subroutines, and arithmetic. It’s not meant to go beyond that. It’s not even meant to be a long-term programming language. It’s simply a first stepping stone to pique a person’s curiosity, so that they then have the interest to pursue a “real” programming language like Python or Java. If you want to checkout SeaTurtle’s syntax, you can see the “Language Reference” section of the SeaTurtle documentation. I have also put together an introductory video tutorial on YouTube.

SeaTurtle is a native Mac app. It has modern features like syntax highlighting, a source code stepper, and animated GIF exports of SeaTurtle drawings. It still probably has some bugs and some useful features that would be beneficial to add. If you have ideas or run into problems, let me know on Twitter @davekopec.

How I Built SeaTurtle

SeaTurtle is a Cocoa app built in Swift. The main intepreter is built in pure Swift using just the Swift standard library and no external dependencies. The turtle graphics runtime is built using SpriteKit. I originally wrote SeaTurtle because I got interested in building an interpreter. The last time I had built a parser was in a compilers class I took in graduate school. It was my lowest grade in graduate school, frankly, probably for some reasons beyond my control, but that’s a story for another time. So, I wanted to retackle this material 7 years later.

I bought the famous Dragon book and started reading it (we used a different book in graduate school). I got some value out of it, but I got more value out of more modern, less academic, more interpreter and less compiler focused books like Writing an Interpreter in Go and Crafting Interpreters, as well as some online tutorials. The tokenizer was fairly easy to write after looking at some other Swift examples. I decided on a handwritten recursive descent parser after studying the alternative options. This seemed like the easiest choice to implement, and there didn’t seem like many downsides for a relatively simple project like this. The best tutorial I found on recursive descent parsers is actually the short article Parsing Expressions by Recursive Descent by Professor Theodore Norvell at Memorial University in Newfoundland, Canada.

The interpreter is written in a protocol-oriented fashion, with one implementer of the protocol being a subclass of NSViewController that manages a SpriteKit scene. SpriteKit was an obvious choice because I had experience in it, and its “actions” (SKActions) for things like movement and rotation of the turtle mapped perfectly to the timed actions I needed for the turtle. There were some frustrations with SpriteKit though during development. In particular, SpriteKit is not good at drawing primitive shapes like lines. There is SKShapeNode but you have to repeatedly add lines to a CGPath and reset the path of the SKShapeNode. The API is not ergonomic to say the least. It would be nice if SpriteKit had a better facility for graphics primitives.

I spent almost as much time as I did writing the actual interpreter on features like animated GIF export, syntax highlighting, printing, and line numbering. Line numbering was surprisingly obtuse for NSTextView. I could’ve used an open source implementation, but I decided to instead write my own as a kind of pride thing. However, I did look at the source code for some open source implementations of line numbering in Cocoa to get an idea of where to start. In the end SeaTurtle doesn’t have any external dependencies beyong Cocoa and SpriteKit.

Like on my last Mac app, Restaurants, I used Cocoa Bindings throughout SeaTurtle. It seems like a technology that’s on its last legs now that Marzipan is a thing. I cannot wholeheartedly recommend it to other developers. It just does not get the attention from Apple that it deserves. The documentation is also not great. The best documentation is really the book Cocoa Programming for Mac OS X, which being built on Swift 1 is quite outdated (hopefully a 6th edition will come out).

Finding an Audience

I don’t know if there is an audience for SeaTurtle. Logo revivals have been very popular on Hacker News the last few months, so my timing seems good. But do people want to use a Mac-native Logo-like language that’s actually lacking some of Logo’s features (subroutines can’t have parameters in SeaTurtle for instance, another simplification, and there are no arrays/lists) but has an even simpler syntax? And that’s not Logo? I guess I will find out shortly, now that SeaTurtle is finally out. I think there might be some software developer parents out there, who are Mac users, who learned on Logo themselves growing up, and think it would be fun to teach their kids programming in a similar environment.

That audience would certainly be a niche. And if there’s not such a niche, then I got to relearn about parsing and interpreters in my spare time, and I have something functional and fun to show for it. If you buy SeaTurtle and find a bug or want a feature added, do get in touch with me.

Book Review: Losing The Signal

Losing the Signal is the cautionary, underreported tale of the smartphone technology company Research in Motion (now BlackBerry) rising into the stratosphere and then fairly quickly falling from grace. The journalist authors are competent writers and story tellers who did a significant amount of background research to make the book happen. They interviewed all of the primary players, including extensive interviews with the co-CEOs of Research in Motion for much of the company’s lifespan, Mike Lazaridis and Jim Balsillie.

The authors are more than fair to the primary players, whom they enjoyed strong access to. As much as it tells the story of BlackBerry, Losing the Signal is equally a narrative of the careers of Mike Lazaridis and Jim Balsillie. The beginning of the book starts as almost a hagiography of the former co-CEOs as it weaves in and out of their respective childhoods and early careers in an effusively glowing tone. Through to the end, the authors seem cautious with their criticism of the two. They never quite blame either whole-heartedly, and instead just report the facts as they see it and let the reader make up his own mind. That shows some integrity as journalists, but perhaps it can also be read as conflicting gratefulness for the high level of access that the two provided them.

Not taking a stand can be frustrating for the reader. Throughout its 250 pages, Losing the Signal offers little meta-analysis of the events that are duly reported from an all access vantage point. It can’t help but be surmised that the authors either did not want to offend their subjects, or that they simply did not have a full grasp of some of the more technical issues that brought down the company. The latter certainly does bleed into the pages in parts.

There are numerous errors/misunderstandings/omissions in the book with relation to its coverage of software technologies. For example, on page 169, it says “Lazaridis realized that to match Apple, RIM would have to base its next browser on the freely available technology called WebKit.” However, in the following paragraph, it’s never mentioned that WebKit is actually an open source project sponsored by Apple itself, an ironic point that highlights just how much of a follower BlackBerry had become. Another example, is on page 172: “What made the Java system ideal to run a narrowly focused e-mail device left it ill-suited to handle the more complicated functions of a smarter smartphone.” There’s two problems: 1. throughout the book, the authors don’t seem to understand that Java is a programming language and virtual machine that systems are built from, and refer to it nebulously as an all encompassing system in and of itself and 2. of course Android, the smarter smartphone that is challenging Blackberry during the narrative, is powered largely by software also written in the Java programming language, making the authors blame of Java seem hollow.

There are more technical errors than the two illustrated above—which is always one of the issues when tech business books are written by journalists. It would’ve helped to have had a software specialist do a proofread of the manuscript, especially when software issues were one of the main reasons BlackBerry declined. The authors’ lack of understanding of this critical area is the main flaw of Losing the Signal.

If you do a book search for “BlackBerry” on Amazon, Losing the Signal is the only title related to the company that will come up. The authors deserve praise for their significant research and painstaking interviews to tell this important technology and business story. Losing the Signal is flawed, but it’s probably the best objective narrative of the BlackBerry story that will ever be produced. There just does not seem to be that much interest in BlackBerry now that it has dwindled into its diminutive form of today. That might be because it’s not an American company, or that might be because its contributions seem less important in retrospect. Either way, it’s good that two competent journalists took the time to lay down the historical record for posterity.

Book Review: Small Fry

Lisa Brennan-Jobs is a good writer: quick-witted, poignant, and observational. Her style reminds me of her aunt’s (Mona Simpson) novels. This is no surprise, since she mentions her in Small Fry as an inspiration. Also of note, is that her aunt has written a fictionalized account of the same period in Lisa’s life as is largely covered by Small Fry. I read that novel, A Regular Guy, when I was a teenager. In fact, I’ve been reading books about Steve Jobs for about two decades now. Like many readers, Steve Jobs is the reason I picked up Small Fry, but Lisa’s journey resonated with me almost as much as the moments about her father.

When you become interested in a historical figure and start watching and reading about them, there’s a cast of characters—their family, their friends—that you’re introduced to along the way. My first exposure to Lisa came through the 1999 film Pirates of Silicon Valley, in which the story of her relationship with her father plays prominently. By the time I had read The Second Coming of Steve Jobs by Alan Deutschman the following year, to me she was an important sidenote—his initial denial of paternity of her following her birth, a significant blemish, for an otherwise heroic figure. The deeper you go in a canon (and there is a Steve Jobs canon—at least fifteen books), the more you become interested in those peripheral characters. And somewhere along the way I became interested in Lisa’s story.

Lisa’s story is intertwined with that of her mother, Chrisann Brennan, Jobs’s high school girlfriend, first love, and financial dependent for a large portion of Lisa’s life. She wrote a memoir a few years ago, The Bite in the Apple. So, in actuality we have three books—A Regular Guy, The Bite in the Apple, and Little Fry—which overlap very significantly in the period and relationships that they capture. Each comes from a different perspective, and I think it was likely important to Lisa that she recapture her own narrative through this memoir. It’s not only a chance to correct the record, but also can provide some kind of closure.

Ostensibly this is more than a memoir about her relationship with her father. It’s a memoir about growing up with that as a backdrop, but I frankly found the first half of the book pretty slow. That’s probably because there’s less of her father in the first half, and the parts with her father were the parts that interested me the most.

Lisa has a tendency to write about events that occurred to her 30 years+ ago in great levels of detail. Levels of detail so great (exact words, imagery, and small happenings) that one has to conclude she either has a photographic memory, or is remembering things in the most dramatic way to suit her narrative. The Bite in the Apple also suffers from this flaw—overly exact ancient memories that cause the reader to question the veracity of their content. It is of course possible that both mother and daughter have incredible memories, but it’s also possible that there’s a little bit of dramatic license in their accounts.

Small Fry is emotionally powerful. The story is dramatic enough that even readers more interested in Lisa’s emotional journey than Steve Jobs will get something out of it. Ultimately, as most memoirs by definition tend to be, it’s also one-sided. The low points with her father seem awful, and the high points seem agreeable and fascinating but dulled. Mona Simpson and Laurene Powell Jobs (Steve Jobs’s widow) have put out a statement questioning Lisa’s harsh treatment of her father. I think, in wanting to recapture her narrative, Lisa did have something of an agenda in writing this book, even if she’s not willing to admit it to herself in its pages. However, that doesn’t mean it’s not a good book, that doesn’t take you on a meaningful emotional journey, and further develop your understanding of Steve Jobs.

Book Review: Grant by Ron Chernow

At nearly one thousand pages in length, Grant by Ron Chernow, is a true commitment for a casual reader. Chernow ably navigates the events of Grant’s life as well as the complex history and politics that surround them. One comes away from the book with a firm understanding of the civil war, mid-late 19th century American politics, and the characters that influenced Grant’s life. However, Grant himself remains an enigma for much of the book.

Chernow is one of the ablest biographers of our time. His masterful, award-winning biographies of Alexander Hamilton and George Washington are different from his treatment of Grant. Of the three, Grant, with his everyman persona and significant personal failings, is the most relatable to the average reader. And this comes across in Chernow’s work, but there is also a distinct difference in writing style. Almost emulating his subject, Chernow uses less of the grandiose language and vocabulary ever-present in his earlier books. That does not mean the writing is any less refined. If anything, it is just more approachable.

Chernow chooses the right level of detail with regards to discussing Grant’s family, friends, and rivals. We learn enough about them to understand how they affected Grant, and Chernow does not shy from interesting anecdotes. But the book, despite its length, never gets bogged down in unnecessarily long side stories about minor characters.

What was missing in most of the book was an understanding of Grant’s personality and what it would be like to sit in a room with him. There are constant references to his laconic manner in public, drinking issues, and also mentions that he was a good story-teller in private. However, unlike with Washington, Chernow does not paint the kind of personality portrait that makes you feel like you know what it would be like to talk to Ulysses S. Grant. Chernow tries to express Grant’s personality through his actions, but it’s not enough. Perhaps this is an over-correction for Chernow, who was criticized by some for playing pseudo-psychologist in Washington.

One does get a better sense of Grant’s personality in the final couple of hundred pages. The story stays compelling right through to the end. Perhaps this is because Chernow knows what to include and what to leave out, or perhaps this is because Grant’s life was just so compelling. Either way, Grant is worth reading through to the end. Not only is it a superb history lesson, it’s also a comprehensive portrait of a human enigma that deserves dissecting.

Announcing Classic Computer Science Problems in Python

I am pleased to announce the availability of my third book, Classic Computer Science Problems in Python. Starting today, you can purchase early access to the book from Manning. Use promo code mlkopec2 for 50% off through August 3rd, 2018. I have completed drafts of the first four of nine chapters, three of which are available today from Manning, with the next three to follow over the summer. The final version of the book will arrive in Fall 2018. The book requires Python 3.7 and makes extensive use of type hints.

Classic Computer Science Problems in Python is a great “second book on Python.” It is aimed at those with some basic knowledge of Python’s syntax who want to delve deeper into the covered problem solving techniques, brush up on core algorithms, or learn more Python using problems familiar to them from other languages. It is suitable for professionals looking to deepen their understanding of the covered topics, students with some programming background looking to expand their computer science knowledge, and anyone preparing for coding interviews.

What is a “Classic Computer Science Problem?” It is a problem one typically finds in an undergraduate computer science curriculum. The topics covered in the book span the gamut from core computer science algorithms you would find in a data structures & algorithms class to artificial intelligence and its sub-discipline machine learning. There are both practical and whimsical problems. They include classic search problems, constraint satisfaction problems, graph algorithms, genetic algorithms, k-means clustering, simple neural networks, and more!

All of the code in the book is available on GitHub. The book takes advantage of the latest features in Python 3.7 like dataclasses and improved support for type hints. The code only uses the Python standard library throughout (with the small exception of the typing_extensions package for improved type hints), so there’s no wrestling with third-party libraries. You will learn how to solve all of the problems in the book “from scratch” so that you gain a deeper understanding of how each problem solving technique works under-the-hood.

To learn more, checkout the Classic Computer Science Problems in Python page on Manning’s website where you will find a full table of contents and free access to the Introduction and Chapter 1 (Small Problems). If the table of contents looks appealing to you, dive in with promo code mlkopec2 which will give you 50% off through August 3rd!

This is the second book in the Classic Computer Science Problems series. If the contents of the book interests you, and you are a Swift developer, you may want to checkout the prior book, Classic Computer Science Problems in Swift. The two books have similar contents, but in the Python book we are careful to write our code in a Pythonic way, whereas in the Swift book we made every effort to solve each problem in a Swifty way… For example, whereas in the Swift book you’ll find protocol-oriented programming in the fourth chapter (Graph Problems), in the Python book you’ll find extensive use of object-oriented patterns, first-class functions, decorators, and new Python features like dataclasses.

Remember that you are purchasing a pre-release version of the book, so you will be joining me on the journey to its final release in the fall. You will be receiving rough drafts of chapters before they have been fully developed. I encourage you to send me your feedback, but keep-in mind that these are early days and everything is not yet perfect. You will receive the final version of the book upon publication.

History of Web Programming (2014)

2018 Note This is Appendix B from my 2014 book, Dart for Absolute Beginners. Like the rest of the book, it’s now a little outdated. It misses the developments of the past 4 years—notably the rise of large client-side JavaScript frameworks (Angular, React, etc.) and the failure of Dart to conquer the world as a client-side Web technology. It’s still, I think, pretty good reading, a decent summary of the history, and interesting in terms of what it got right and wrong about trends. Any mistakes are my own and/or a result of conversion to Markdown for this blog. If you like my writing, you may enjoy my new book, Classic Computer Science Problems in Swift which you can get for 40% off with code kopec40 on Manning.com.

History of Web Programming

Author's Note: This appendix is not meant to be reference quality material. It contains speculation, suppositions, and opinion. The technologies/programming languages mentioned were built by incredibly smart and dedicated people who did not have the foresight of twenty-five years of the Web that we have today. Any slights pointed towards them must be read with that context in mind.

To fully appreciate Dart's place in the Web development ecosystem and its purpose, it's necessary to understand a little bit about where that ecosystem has come from. This appendix is not about Dart – it's about what led up to Dart. It's about the languages that have been used for programming the Web throughout its history.

Client-Side

In the beginning, the Web was static. A page was downloaded and it didn't change. When Tim Berners-Lee released the first web browser in 1990, web pages consisted of text with a little styling, and links to other web pages. It was a web of information – not of interactivity. One has to remember the technology of the time. A cutting edge microprocessor in 1990 operated at 50 megahertz and the average personal computer had a few megabytes of RAM. The speed of computers has improved exponentially since then.

Over time the technologies available in web browsers for content presentation became more impressive. Images were added. The ability to play sounds was added. Browsers included the ability to extend themselves with plug-ins. CSS was introduced to improve styling. New HTML tags were introduced to improve layout.

Even as web pages became prettier, they still lacked the capabilities of native applications. Web browsers were in essence HTML document viewers. They lacked the ability to respond to users in any kind of dynamic way. In order for the Web to become a platform that could compete as a venue for interactive applications, client-side browser programming languages were developed.

Java Applets

Java 1.0 was released in 1995 by Sun Microsystems[1] and it made a big splash. It promised to be a new, memory-safe, secure, object-oriented, platform-independent programming language/software runtime with familiar syntax. A cool aspect of the new language/platform were so-called applets. Java applets are Java programs that run with a graphical user interface in a pre-defined rectangle on a web page.

The promise of Java applets was that programs could be written once and run on any platform that had a Java runtime environment and a web browser. This write once, run anywhere philosophy, aimed to make the distinction between running a program on a Mac versus on Windows irrelevant (or on a Unix workstation). Netscape Navigator was the first web browser to support Java applets.

The reality in the late 1990s was that Java applets were slow to load, had inconsistent user interfaces, and suffered from incompatibilities after Microsoft bundled its own Java runtime environment with Internet Explorer (a lawsuit was fought over this) that had subtle differences from that deployed by Sun. Java applets can still be run today on any web browser with a Java plug-in but they're becoming increasingly rare. The lack of support for Java applets on mobile platforms like iOS has sped along their demise.

JavaScript

The introduction of JavaScript happened practically in parallel with that of Java applets. JavaScript also launched in 1995 and Netscape Navigator was also the first web browser to ship with it. Indeed, JavaScript was the creation of Brendan Eich, a Netscape employee, and the story goes that he designed the whole language in ten days. JavaScript was not originally meant to be used for the same kind of applications as Java applets. It was supposed to be a lightweight scripting language. There had been previous attempts at providing scripting languages in a web browser but none of them had the backing of a major player like Netscape or Microsoft until JavaScript. The name JavaScript was a marketing ploy to take advantage of the hype around Java.

JavaScript was standardized as ECMAScript by Ecma International. JavaScript was popular enough that Microsoft incorporated a slightly modified version of it in Internet Explorer the following year. The incompatibilities between Microsoft's version of JavaScript and Netscape's version, despite the ECMAScript standard, would plague web developers to this day.

While JavaScript quickly gained popularity, for the first decade of its life it was utilized almost exclusively for what we would consider today to be quite small use cases. A major reason for this was its speed (or lack thereof). The original JavaScript engines were interpreted. It wasn't until the 2000s that JavaScript engines commonly included a Just-in-Time Compiler (JIT).

Over the past decade, as the speed of JavaScript engines increased, its features expanded, and its compatibility across browsers improved, it began to be used for increasingly significant applications. Browser apps increased in complexity to the point where they rivaled native software. JavaScript also increasingly became popular on the server (see below in Server-Side).

Today, JavaScript is the lingua-franca of the Web. There are very few, if any, of the most popular websites in the world that are not powered largely by JavaScript on the client-side. By any measure JavaScript is one of the most popular programming languages in existence. For a little more on JavaScript from a technical standpoint, checkout Chapter 17's section on it.

VBScript

Microsoft once had a tendency to leverage its near monopoly status in the industry to push proprietary technologies that would encourage platform lock-in. VBScript was arguably one such proprietary technology. Added to Internet Explorer in 1996 as a kind of answer to/Microsoft eco-system alternative to JavaScript, VBScript leveraged the Visual Basic name in a similar fashion to JavaScript leveraging Java's brand (in name only).

VBScript attempted to fill a similar nitch to JavaScript-that being a lightweight scripting language for making web pages more interactive. Due to its proprietary nature however, websites with VBScript could not function properly in non-Microsoft web browsers. This was okay for a while, when Internet Explorer had around 90% marketshare in the early 2000s, however proprietary technologies are considered antithetical to the ideals of the open Web.

VBScript lost out to JavaScript but found its way into some other Microsoft products. As of Internet Explorer 11, it has been deprecated as scripting language for the web browser[2]. Although it hasn't been a real player on the Web for over a decade, many will still say good-riddance to the proprietary Web.

Flash

Flash is a platform for interactive content that is most commonly used for games and streaming video. It actually extends beyond the Web, but we’ll keep our discussion limited to the Flash web browser plugin. Flash was originally developed in the 1990s by several different companies before coming under the guise of Adobe after its 2005 acquisition of Macromedia. Flash is programmed with the ActionScript language. Interestingly, ActionScript is derived from ECMAScript, the same standard as JavaScript.

In a world where Java applets were too slow loading, and JavaScript was too unsophisticated, Flash came to dominate the niche of web-delivered richly interactive experiences. The Flash browser plugin was at one point installed on over 90% of web browsers and commonly came bundled with new computers. Flash was everywhere.

Flash’s big challenger came in the form of improved JavaScript engines and APIs. The smartphone revolution rendered another blow to Flash as mobile web browsers didn’t include plugin support, most famously the original iPhone. Steve Jobs wrote an open letter in 2010 criticizing Flash as a proprietary, legacy technology who’s time had passed[3]. The letter was controversial, but ultimately signaled a shift in the industry away from Flash and towards HTML5 and JavaScript technologies.

However, Flash is still the main language used for Web games and streaming video on laptop and desktop web browsers. There are JavaScript and HTML5 technologies that are making inroads, but the Flash plugin will likely still be with us for years to come. With that said, it’s probably not a good idea to develop new Web applications in Flash.

Silverlight

Silverlight is another Microsoft technology that was seemingly developed as an answer to an industry de-facto standard. As VBScript was an answer to JavaScript, Silveright was an answer to Flash. Microsoft Silverlight is based on the technologies of the .NET Framework, Microsoft’s sophisticated software stack that underlies most of its modern platforms. Silverlight is delivered chiefly in the form of a web browser plugin.

Silverlight applications can be programmed from several different programming languages, but the browser plugin never saw widespread adoption outside of the Microsoft ecosystem. The notable exception has been Netflix, which plans to move away from Silverlight in a future version[4]. First released in 2007, Silverlight may have simply come too late to market to garner widespread adoption.

The official Silverlight browser plugin is only available on Windows and OS X. Although a free software version of Silverlight is available that runs on Linux and other operating systems, like with Flash, you will be leaving iOS and Android users in the lurch if you develop your site with Silverlight. Further, Microsoft's support for Silverlight appears to be waning. Stick with Dart and JavaScript.

Recent Developments

It seems a rule in web technology (if not all technology) that any platform that comes to dominate a space will quickly have newcomers attempting to displace it. When it comes to JavaScript, the strategy seems to be more one of acceptance of it as a standard, while attempting to work around it. Embrace and extend if you will.

The chief JavaScript alternatives all compile to JavaScript. You obviously already know about Dart, Google’s effort which launched in 2011. Dart is an entire alternative platform. CoffeeScript is a less ambitious effort. It’s basically a set of syntactic sugar that makes JavaScript more readable and adds a few more advanced language constructs that reduce the size of an equivalent program (in terms of lines of code). Of course the benefits of a syntax change are up to the whims of an individual. Some people will prefer CoffeeScript’s syntax (which borrows from Ruby and Python) while some people will prefer traditional JavaScript.

CoffeeScript has gained some traction. It is a popular language on GitHub and was even included in the 3.1 release of the popular web development framework Ruby on Rails[5]. CoffeeScript does not represent a paradigm shift. It represents an influential direction for client-side languages as far as programmatic syntax is concerned.

Microsoft had an answer to JavaScript and an answer to Flash. Surely, it must have an answer to Dart… Of course it does! TypeScript, first appearing in 2012, is Microsoft’s player in this space. Unlike Dart, TypeScript does not represent a completely separate platform, but instead is a superset of JavaScript. In fact, many of TypeScript’s features are expected to appear in the forthcoming JavaScript standard ECMAScript 6.

Like Dart, TypeScript aims to relieve the difficulty of cleanly building modern, significantly sized applications that live in the browser. Also like Dart, it includes support for classes and optional types. That’s where the similarities end. TypeScript does not represent a new platform. It represents an improved environment for building JavaScript applications. There is no TypeScript VM. If Dart didn’t exist, TypeScript would be a more compelling pure JavaScript alternative. But, as it stands, most of the features inherent to TypeScript will be included in the near future in JavaScript anyway.

Although seldom mentioned in the tech media, Haxe is a rather remarkable language. It not only compiles to JavaScript, but also to Flash, PHP, C++, Java, and more. It’s truly a truly platform independent language if there ever was one. At the same time, it’s syntax is close to ECMAScript so it looks familiar to JavaScript and Flash developers. Haxe first appeared in 2005.

Server Side

The difference between server-side and client-side programming is delineated in Chapter 7. The diversity of solutions for server-side development far outstrips that of the client-side. The alleviating factor that makes the possibilities so much more pliable, is the lack of necessity to run in the browser. There are web frameworks available for just about every programming language in mainstream use. The job of a sever-side web framework basically boils down to receiving a request, processing it (and any user supplied parameters), and outputting HTML back to the web server ready to be served to the user. The story of server-side web development has been a story of making this (and everything that goes with the process step such as database access) process easier.

CGI

CGI stands for Common Gateway Interface. It's an interface, first developed in 1993, that allows a request sent to a web server to result in the execution of a program on the server. The content generated by the program can then be sent back to the client via the web server. A CGI program can essentially be written in any language. The interface was developed as a standard that all web servers could implement.

Although uncommon today, it wasn't unusual to see large CGI programs built in C or C++ in the 1990s. They were ubiquitous languages that offered tremendous speed at a time when computer hardware, even on the server-side, struggled to keep up with the demands that were placed on it. The problem with C/C++ is that they're memory unsafe and don't have tremendous built-in facilities for text processing, which is the purview of much web work. These points make writing CGI programs in C or C++ arguably more difficult than in other languages. That didn't stop Amazon from building a large part of its original 1995 site in C[6].

C and C++ were so widely used (outside the Web) that their syntax became the template for most of the languages used on both the client-side and the server-side of the web in the 1990s including JavaScript, Java, Perl, and PHP. Today, it's rare for a server-side web application to be developed in C or C++. However, a program built-in another language may call a C/C++ library for performance reasons. An example would be a Python based genetics research web app that calls C code for doing numerical analysis. The logic of building the app may be all Python, but the computationally intense bit will be C. For a little more information about C, see Chapter 17.

Many of the languages that became popular on the Web began by being utilized through CGI. Most of them later gained their own web server extensions that bypass CGI for performance reasons. CGI continues to be an option on modern web servers.

Perl

For many years, Perl was the glue that held together the Internet, operating through the Common Gateway Interface to power many early websites both large and small. It was the first higher-level language to be widely deployed for server-side web programming. Perl, founded by Larry Wall in the late 1980s as a scripting language, actually predates the Web. Perl has extensive capabilities for processing text – a task critical in web development (HTML is just text after all).

So, why didn't Perl maintain its popularity? One of Perl's slogans is "There's more than one way to do it." That's not always a good thing. Perl gained a reputation for being the language most likely to be used for writing cryptic, unreadable code. If everyone does things their own way, and individual style trumps common conventions, then that's a recipe for a lot of mutually difficult to read code.

Perl has been stuck in a versioning nightmare since a new redesigned version, Perl 6, was announced in 2000. Fourteen years later, Perl 6 continues to be in development while Perl 5 has diminished in popularity. Larry Wall continues to lead Perl as its Benevolent Dictactor for Life (BDFL). Several popular websites continue to be developed in Perl including Craigslist which hired Larry Wall in late 2013[7].

PHP

PHP began as a set of C CGI scripts that Ramsus Lerdorf used on his personal homepage in 1994. It evolved into a templating language, and over time a distinct programming language that somewhat resembles Perl. PHP lives side by side with HTML. It has the ability to be embedded in tags within an HTML document, which makes deployment as simple as uploading a PHP file to a web server. This simplicity of deployment is likely what rocketed PHP to become the most popular server-side web language amongst small to medium size websites. It's practically unheard of to sign up for a small business web host and not have the web server come with built-in PHP support.

PHP even powers the most popular content management system in the world, WordPress. In fact, PHP is so popular, even today, that it gets mocked by developers from other language communities for the poor quality of the code developed with it. As a popular, easy to deploy, ubiquitous language, PHP attracts a wide swath of developers including many just starting out. Naturally, if inexperienced developers make a large set of your user base, code quality will suffer. It's in a similar situation on the server-side to JavaScript on the client-side which is also sometimes mocked by other language communities.

Are these criticisms fair? The answer is largely, no. High performance, beautifully engineered code is written by top-tier talent in PHP every day. Facebook is largely written in PHP[8]. PHP is relatively high performance compared to some of the other popular modern server-side offerings. PHP may have been the accident of one man's tinkering and largely unplanned as a language, but it's clearly been successful for a reason – it's easy to get started with and high performance.

ASP

ASP was Microsoft's original entry into the server-side web technology war. ASP, which stands for Active Server Pages, could in its original 1996 incarnation most readily be compared to PHP. It had an emphasis on embedding logic in tags alongside HTML. With an emphasis on Windows server operating systems, ASP never had a fighting chance of reaching PHP's level of ubiquity given that the majority of web servers run Linux or other Unix like operating systems. ASP was replaced by ASP.NET, a version tailored for Microsoft's multi-language .NET platform. Microsoft released a paper in 2003 titled "Migrating from PHP to ASP.NET" comparing PHP and ASP.NET that may be interesting from a historical perspective[9].

Java

The big excitement when Java launched surrounded using it for building write-once-run-anywhere desktop applications and Java applets. Over the years, Java did achieve dominance across a wide array of devices from mobile phones and credit cards to DVD players, but it never achieved prominence on the desktop outside of the corporate world. It did, however, find a surprising niche as the power behind many industrial strength web infrastructures. J2EE (Java 2 Enterprise Edition), released in 1999, was the first major version of Java that explicitly targeted large scale web infrastructure developers.

Sun Microsystems, the creator of Java, created Java as an open specification that other corporations could implement. IBM, RedHat, and others created J2EE implementations that could run the same server-side programs that ran on Sun's J2EE application server. This created an ecosystem of industrial strength enterprise grade Java application servers backed by the world's biggest enterprise tech companies. Java flourished and became the preferred enterprise server-side technology.

JSP, or Java Server Pages, a part of J2EE, allows Java to be embedded with HTML similarly to PHP. Java continues to be widely deployed in the enterprise world for server-side stacks due to its high performance, maturity, and large pool of developers and advanced libraries. Newer languages that run on the Java Virtual Machine (JVM - similar in principal to the Dart VM) such as Scala, Clojure, and Groovy have their own popular web frameworks (Play is one, for example) that have the added benefit of being able to interact with legacy Java libraries. Further, versions of Ruby and Python (JRuby and Jython), two popular languages to be mentioned shortly, also run on the JVM.

For all of the reasons expounded in the last paragraph, the Java platform continues to be compelling. It probably has lost web developer mind-share, not so much because of its faults, but instead because what's come after it is so compelling. A concentration during the last decade on rapid application development frameworks with batteries included, which includes Ruby on Rails and Python with Django, has captured the imagination of the industry because they allow developers to build more quickly than with traditional solutions like Java.

Python

Python, like Perl was originally created by a single developer as a scripting language for Unix-like systems. In this case, the year was 1991 (just 4 years after Perl) and the creator was Guido van Rossum. While Perl was successful on the server-side of the Web almost from the beginning, it took until the 2000s for Python to become a mainstream server-side Web language. For more about Python, the language, see Chapter 17.

Python's clean, easy to follow syntax and batteries included philosophy makes it a great language for getting things done quickly. However, that didn't make it a great language for building web apps until web frameworks that matched the elegance of the core language became available. The most prominent Python web framework is by far Django. Django began life in 2003 at a newspaper for its internal use and was released to the public initially in 2005. Django follows a classic and powerful software development paradigm known as MVC (Model View Controller), which emphasizes the separation of data from display.

Django is not the only game in town. Python is somewhat notorious for the proliferation of so-called microframeworks. These are small web frameworks that don't necessarily include all of the features of a full service framework like Django, but make it very easy to get smaller web apps built quickly due to their logical defaults and concise setup. The most popular microframework is probably Flask. Hello World in Flask (showing a web page that displays "Hello World") is just a few lines of Python.

If Python's syntax is so praised and it has such great frameworks available then why isn't everyone using it for server-side web app development? Python's popular implementation has relatively poor performance compared to some of the other options available which makes it unsuitable for some applications. Further, Python deployment is trickier for beginners than something like PHP where a file with embedded HTML just gets dropped on a server. However, Python is still very popular today, and probably doesn't compete as much with PHP developers as it does with Ruby developers. Also similarly to Perl, Python has suffered from a botched version transition from Python 2 to Python 3 (no letters please!), although Python 3 has been gaining traction as of late, 5 years after its debut. Like Larry Wall, Guido van Rossum continues working as Python's BDFL.

Ruby

Ruby is a language first released by Yukihiro Matsumoto in 1995. Like Python it features clean syntax and a thoroughly object-oriented design. Outside of Japan, Ruby failed to gain significant popularity until the released of the web framework Ruby on Rails (also known just as Rails). Ruby on Rails led to an explosion of interest in Ruby (mostly to use Rails) due to high developer productivity in the framework.

Ruby is coupled with a popular packaging system called RubyGems that is analogous to Dart's pub. The combination of a vibrant gems ecosystem with Ruby on Rails has allowed for the rapid development of many web apps. It is a pretty common belief that an equivalent web application can be built with fewer lines of code with Ruby on Rails than with comparable web frameworks for other languages.

There's a lot of "magic" that goes on behind the scenes of a Ruby on Rails web application that allows just a few lines of code to provide an impressive array of functionality. This magic has been criticized because it is thought that it leads to a situation where novice developers build complex web applications without understanding fully what's going on behind the scenes. It is so easy with RubyGems to include an open source project that adds significant functionality to a Rails application that it is trivial. This notoriously leads to many poorly supported gems underlying the architecture of Rails applications.

Also like Python, Ruby's most popular implementation suffers from performance problems (even worse ones than Python indeed). Twitter was originally developed largely in Ruby on Rails but due to performance and scaling considerations had to move several pieces of its stack to JVM based languages (Scala and Java) as it grew[10]. Ruby on Rails development offers many similar advantages and pitfalls to Python with Django. Choosing between the two has more to do with personal preference (in regards to language syntax and how the frameworks work) than any inherent advantage of one over the other. When you don't need to worry about large scale, as most beginning developers don't, both are excellent options for modern server-side web app development.

JavaScript

JavaScript has only become a popular server-side option since the advent of high performance JavaScript VMs during the last decade. Netscape actually shipped a server-side JavaScript framework as early as the mid 90s, but it was not really until the release of Node.js in 2009 that sever-side JavaScript began to flourish. Node.js is a platform for building asynchronous web apps using JavaScript. One of the most popular frameworks for Node.js is Express.js.

Why is JavaScript on the server-side a good idea? The key benefit is the ability to use one language for both the client-side and the server-side. This familiarity arguably enables an environment where code reuse is optimized and developer skillsets can more easily span both domains.

Node.js provides not just an application server, but also a packaging environment. npm is a package manager, analogous to pub. Plain vanilla JavaScript does not provide a clear path for package management.

JavaScript on the server-side, and specifically Node.js, is seeing adoption in the corporate world. Microsoft helped port Node.js to Windows[11]. Walmart is utilizing Node.js to back its online store[12]. These are recent developments within the last three years. Clearly server-side JavaScript has momentum.

Trends

The biggest trend in server-side web development of the past ten years has actually come from the client-side. The advent of fast client-side JavaScript and the popularity of AJAX has allowed logic that was once exclusively the realm of the server-side to be pushed into the browser. This has caused the focus of server-side development to be less on building full MVC (model, view, controller) applications and more on supplying data to be displayed by complex JavaScript front-ends. It is not uncommon for a single server-side application, serving JSON, to deliver data for a web-client built in JavaScript, an iOS client built in Objective-C, and an Android client built in Java. In fact, this maybe the epitome of what's seen as a "modern" architecture.

Another clear trend is use of the same programming language on the client and server. This is most obvious with JavaScript's Node.js, but there are other examples. Dart is one. There are several projects that put Python in the browser via compilation of Python to JavaScript (pyjs, Skulpt, PyPy.js). There are similar JavaScript compilers for Haskell, Clojure, and many other languages that are also used on the server-side. The best known other-language-to-JavaScript-compiler may be another Google sponsored project, called Google Web Toolkit. Google Web Toolkit (GWT) compiles Java to JavaScript.

Finally, one more trend has been language experimentation. The number of languages with viable server-side web frameworks seems to be ever expanding. There are languages that are beautiful in their functional purity, like Haskell, and languages bent on simplicity like Go. There are languages that thrive when put to the test of concurrency like Erlang, and languages that are hyper-modern in their feature-set like F#. All of them are being used to build industrial strength web applications that would've been built with PHP or Java a decade ago.

The overall focus of all of these trends is on simplifying the toolset and letting developers work in the environment they are most comfortable with. There's an incredible diversity of options available for server-side web programming today. With a lot of choice also comes a lot of fragmentation and little fiefdoms. Do you have a big server-side web app coded in Haskell? It's going to be a very specialized (and probably expensive) set of developers that can service it.

How do you pick a server-side language/framework in such a fast moving landscape? Take advantage of these trends. If your application can move much of its logic to the client-side, do so. Then you can code it largely in Dart. If you can simplify your life by using Dart on both the client and server, go for it! If the specialization of one of the many languages that have robust server-side frameworks available is good for your application, then take advantage of it, as long as its ecosystem looks viable going forward.

Where Does Dart Fit In?

Dart emerged at the end of these timelines, both on the client-side and the server-side. It incorporates a lot of great thinking from its predecessors. It's a balanced language. It's not necessarily overtly focused on a single niche in the same way that a Haskell or PHP might be. It's most comparable to JavaScript in that it runs both in the browser and on the server. However, syntactically it shares a great resemblance with Java.

Dart is meant to be an accessible language suitable for developing both small and large web apps. It contains facilities for rapid prototyping. Yet, it also has features that make building large applications easier than with JavaScript. At the same time it's compatible with today's client-side infrastructure because it compiles to JavaScript. Dart tries to take a Goldilocks position.

Dart has many of the modern features present in languages that have emerged over the past few years, yet its syntax is reminiscent of older languages. Dart is not the fastest language available, but it's faster than JavaScript (when run on its own VM) and the most popular implementations of Ruby and Python. Is a lack of specialization a problem for Dart when JavaScript is seen as good enough by many? Only time will tell.

Evolution of the Web Browser

Alongside the ever changing landscape of client-side and server-side web programming languages has been a parallel history of browser development and enhancements to HTML/CSS. In the beginning (i.e. 1990), there was Tim Berners-Lee original Web Browser for NeXTSTEP called WorldWideWeb. The HTML spec and that original browser didn't even support images, let alone CSS. Mosaic was the first widely used multiplatform web browser, and it was released in 1993 by a team at the National Center for Supercomputing Applications (NCSA) at the University of Illinois Urbana-Champaign.

Microsoft and Netscape Duke it Out[13]

Mosaic led to two spinoff browsers. Netscape Navigator was a commercial program released in 1994 and built by a team of ex-Mosaic engineers at the nascent Netscape Communications Corporation. As a commercial entity, the Netscape team had to purposely avoid using any of the old source code from Mosaic. Netscape quickly succeeded Mosaic as the browser of choice for early Web users.

Microsoft, realizing the web platform was a threat to its dominance of desktop personal computing, licensed the technology behind Mosaic from an entity called Spyglass Inc. which in turn had licensed the source code to Mosaic from the NCSA. Microsoft released Internet Explorer 1.0 in 1995. Over several revisions during the next few years, Internet Explorer took significant marketshare from Netscape.

The period of Netscape and Internet Explorer competition (roughly 1995 to 2000) was one in which several client-side technologies previously mentioned were developed and popularized including JavaScript, VBScript, Java, and Flash. Unfortunately, at least with regards to the former three, they led to significant incompatibilities between dueling feature sets in Netscape and Internet Explorer.

A JavaScript program written for Netscape would not necessarily run unmodified on Internet Explorer. Likewise, a Java program coded for Microsoft's Java Virtual Machine (JVM) would not necessarily run correctly in Netscape/Sun's JVM. A VBScript program wouldn't run in Netscape at all.

Even the HTML spec itself was up for dueling visions. There were tags that one browser supported and the other didn't. Even more common, a tag/style displayed in one browser could look very differently on the other. Even today, it's important to check how a site looks in all of the popular browser, but back then it was also a matter of coding around the inconsistencies and building specialized versions of a program/site for each browser.

During this period there were no major platforms that mattered other than personal computers and they ran Microsoft Windows or Mac OS. Those were the main platforms that Netscape and Internet Explorer supported. There was no worry about supporting browsers popular on smartphones or tablets or game consoles (although early versions of browsers for all of these existed).

Microsoft's coupling of Internet Explorer with its dominant Windows operating system and proprietary version of the JVM led to lawsuits, but in the scheme of things they didn't really matter too much for the average web developer. By the year 2000 Internet Explorer had won. Microsoft's browser attained over 80% market share. Netscape was sold to AOL and the source code to its browser was given to a not-for-profit foundation known as Mozilla.

Firefox Emerges from the Ashes of Netscape

Mozilla released an open source browser that made little dent in Internet Explorer's hegemony. During the period of Internet Explorer's domination it was not uncommon for sites to be coded for it to such a degree that they would not work in alternative web browsers. The first significant challenger to Internet Explorer came out of Mozilla in 2002. Firefox was a stripped down, more lightweight version of the open sourced Netscape components that gained a quick following in some international markets.

The interest in Firefox coincided with a reemphasis on open standards in the industry (including specifications like CSS and HTML 4). The goal was to avoid the fragmentation of the 1990s and ease the difficulty of web developers' day jobs. It didn't happen quickly. There was little incentive for Microsoft to move quickly to adopt standards to help erode its dominant position.

In 2003 Apple released its own web browser, Safari, only for Macintosh, and based on open source technology earlier used in the Linux world. The same year, Microsoft announced it would not release any new versions of Internet Explorer for Macintosh. Although Window had over 90% marketshare amongst personal computers, this did provide a further impetus for web developers to build sites based on open standards and cross-browser compatibility.

Mobile and a Revitalized Browser Ecosystem

There were versions of Safari for Windows that didn't make much of a dent in the market, but it was the version of Safari that came with the original iPhone in 2007 that really changed the game. Mobile web browsers had existed since the 1990s, but they were limited in functionality due to the weak microprocessors and user interface technologies that existed on mobile phones up to that point. The iPhone was the first smartphone to offer a full web browser experience that made websites designed for desktop browsers easy to read on the go. And the iPhone's Safari depended on open standards.

Most importantly, the iPhone's Safari didn't support plugins. This meant no JVM (no Java applets) and no Flash. The iPhone was a sensation and if web developers wanted to capitalize on its success, they would need to code to the open web standards (namely JavaScript, HTML, and CSS) that it supported. It was also the beginning of concern for making sites that worked well on many highly different screen sizes. While the iPhone could display sites written for big monitors that accompany desktop web browsers, sites looked better when their content was responsive to different screen sizes.

Google's Android followed in 2008 and largely reinforced the changes brough about by the iPhone. And these were yet further reinforced by the iPad and Android tablets. It's unusual for a site today to not look great on both mobile and desktop.

Google also released its own desktop web browser, Google Chrome in 2008, based on the same open source project, WebKit, as Apple's Safari. Chrome's super fast JavaScript VM, V8, was a revelation. It enabled applications to be coded for the browser that were previously only done natively. It led to a arms race in JavaScript VMs between all of the major players – Mozilla, Apple, Microsoft, and Google – which ultimately pushed the state of the art on the Web forward.

Whole platforms emerged based on browser technologies. Palm launched the ill-fated WebOS which was ultimately scattered in pieces across HP and LG. Google launched an operating system called Chrome OS that has seen some success in low-end laptops. Mozilla launched Firefox OS, an operating system for smartphones targeted at emerging markets and low-end handsets.

By the mid–2010s, Microsoft was no longer dominant in the browser space. Web developers today care as much, if not more, about what Google, Apple, and Mozilla think about web standards as they do about Microsoft. On the other hand there are still many older versions of Internet Explorer floating around corporate environments that need be coded to for major applications. Microsoft, whether as a result of a change in its corporate culture, or a shifting competitive landscape, has embraced open standards in the past few years. The most recent versions of Internet Explorer are on the cutting-edge standards wise.

HTML5, the current version of the HTML specification, embraces facilities for managing the changes that have occurred over the past decade with regards to the web development ecosystem. For instance, it includes facilities for displaying rich content like video, audio, and graphics that were once the purview of Java Applets and Flash. It also has built-in support for displaying content in ways that is responsive to differing screen sizes.

Firefox and Chrome have adopted rapid release cycles that bring innovation to users as quickly as possible. At the same time, users are treated to constant upgrades with little discernable difference between sequential versions. Table B–1 summarizes the browser world today.

Table B–1 Web Browsers Today

	Internet Explorer	Firefox	Safari	Chrome
Developer	Microsoft	Mozilla	Apple	Google
First Appeared	1995	2002	2003	2008
Release Cycle	Traditional	Rapid	Traditional	Rapid
Rendering Engine	Trident	Gecko	WebKit	Blink (forked from WebKit in 2013)
JavaScript Engine	Chakra	SpiderMonkey	Nitro	V8
Open Source?	No	Yes	Engine Only	Based on open source Chromium project
Desktop Platforms	Windows	Cross-Platform	OS X	Cross-Platform
Mobile Platforms	Windows	Android, Firefox OS	iOS	Android, iOS
Other Platforms	Xbox			Chrome OS

There are other browsers too, such as Opera which has mobile versions, desktop versions, and versions for specialty markets like the Nintendo Wii. Most alternatives to the big four use the same rendering engine as one of them so can be expected to render things in a similar fashion. For example, Opera has adopted the Blink engine used by Google Chrome. Another example is the experimental browser included on some versions of Amazon's e-ink based Kindle e-readers which runs an engine based on WebKit, the same engine used in Apple's Safari.

There are differences between the mobile and desktop versions of the big four. In other words, Windows for Windows Phone doesn't necessarily support all of the same technologies as Windows for desktop computers. More and more the emphasis for new websites has been on designing mobile-first as usership naturally moves to mobile devices.

Importance Today

Why does it matter what web apps were coded in 20 years ago? It matters because there's been a clear progression, both on the server-side and the client-sider, in web technology. Each technology exists today as a response to what came before it. PHP would likely never have existed if writing web apps in C wasn't cumbersome. Dart is a direct response to the difficulty of building large scale applications in JavaScript.

The browser wars ultimately resulted in the adoption of open standards. That's arguably good for almost everybody (save the former dominance of Internet Explorer perhaps). Web developers today largely don't need to worry about coding platform specific hacks.

By understanding the history, it's possible to tease out trends that will continue to affect the industry. By understanding these trends, a developer can insure that he's riding the wave of technology instead of swimming against it. If you could see the direction the industry was going in 10 years ago, you certainly would have been careful not to code a large application in VBScript. Today that might be Flash.

There are right answers when choosing a Web technology to build with. It's important to understand what your alternatives are. It's important to code with an eye towards the future and understand the mistakes that others have made in the past. The Web can be complicated, but it's generally getting less painful with each passing year.

---

1. Oracle "The History of Java Technology" http://www.oracle.com/technetwork/java/javase/overview/javahistory-index–198355.html  ↩
   
2. Microsoft VBScript is no longer supported in IE11 edge mode for the Internet zone http://msdn.microsoft.com/en-us/library/ie/dn384057(v=vs.85).aspx  ↩
   
3. Steve Jobs Thoughts on Flash http://www.apple.com/hotnews/thoughts-on-flash/  ↩
   
4. Anthony Park and Mark Watson HTML5 Video at Netflix http://techblog.netflix.com/2013/04/html5-video-at-netflix.html  ↩
   
5. Peter Cooper Rails 3.1 Adopts CoffeeScript, jQuery, Sass and… Controversy http://www.rubyinside.com/rails–3–1-adopts-coffeescript-jquery-sass-and-controversy–4669.html  ↩
   
6. Brad Stone The Everything Store: Jeff Bezos and the Age of Amazon (Little, Brown 2013) p 36  ↩
   
7. Jim Buckmaster "Artist. Formerly known." Craigslist blog http://blog.craigslist.org/2013/10/15/artist-formerly-known/  ↩
   
8. Brian Shire "PHP and Facebook" https://www.facebook.com/notes/facebook/php-and-facebook/2356432130  ↩
   
9. Microsoft "Migrating from PHP to ASP.NET" http://msdn.microsoft.com/en-us/library/aa479002.aspx  ↩
   
10. Alex Williams "Once Again, Twitter Drops Ruby for Java" readwrite April 11, 2011 http://readwrite.com/2011/04/11/twitter-drops-ruby-for-java#awesm=~oCSaqvGb5QSBsn  ↩
    
11. Ryan Dahl "Porting Node to Windows with Microsoft's Help" Node.js Blog. June 23, 2011 http://blog.nodejs.org/2011/06/23/porting-node-to-windows-with-microsoft%25e2%2580%2599s-help/  ↩
    
12. Eran Hammer (Interview) "Node Black Friday at Walmart with Eran Hammer" The Changelog (Podcast) http://thechangelog.com/116/  ↩
    
13. For more on the early history of the Web checkout The Internet History Podcast at http://www.internethistorypodcast.com  ↩
    

Classic Computer Science Problems in Swift is Released!

Last week, Classic Computer Science Problems in Swift was released in print by Manning. It’s now in general availability from both Manning and Amazon. It’s a great book for students enrolled in a computer science program, professionals looking to learn a few computational problem solving techniques they’ve always been curious about, people preparing for job interviews, or anyone who already knows Swift and would like a very tutorial-oriented intro to some basic algorithms from AI.

The book aims for breadth instead of depth. There are chapters on search (including depth-first search, breadth-first search, and A*), graph algorithms (including Prim’s algorithm and Dijkstra’s algorithm), genetic algorithms, constraint-satisfaction problems, k-means clustering, neural networks, and more. It’s not a data structures & algorithms textbook. Instead, it’s a concise set of hands-on tutorials starting from scratch in each subject area. It’s also not an app-development book. The reader will not find any UI code. Instead, it focuses on solving several classic problems one would typically find in an undergraduate CS curriculum as concisely as possible in Swift Playgrounds.

The book assumes the reader is an intermediate Swift programmer. It is not appropriate for absolute Swift beginners. You can watch my short intro video explaining the book on YouTube and you can find all of its accompanying source code (tested against Swift 4.1 Playgrounds in Xcode 9.3) on GitHub. Most of the code will work in any Swift project, including projects for Linux.

If you read the description in the YouTube video, you will find a code to get a significant discount on the book from Manning. You can also download both Chapter 2 (Search) and Chapter 4 (Graph Algorithms) for free from the book’s page on Manning’s website. I think Chapter 4 (Graph Algorithms) is a really great chapter. In it you solve several problems related to building out a Hyperloop network in the United States while developing a graph data structure programmed in a protocol-oriented style.

Writing the book was mostly a joy. I finished the manuscript in September 2017. Delays in Manning’s production department led to the April 2018 release. I apologize to readers who pre-ordered the book and had to wait so long for the final version. I am not terribly happy with the formatting of the .mobi (Kindle) and .epub (iBooks) editions, which unfortunately is out of my control. I recommend picking up either the PDF from Manning or the print edition. When you purchase the eBook from Manning, you get the PDF, Kindle, and iBooks versions together.

Thank you in advance for reading. Feedback from readers in Manning’s early access program has been very positive. Pre-order sales of the book have also been strong. Let me know your feedback (both positive and negative) about the book on Twitter. And Amazon reviews (especially positive ones 😀) are appreciated. We are probably going to “port” the book to other programming languages, but those new books are likely a long-time away from release. I will also update the GitHub repository with an updated PlayGround when Swift 5 ships in final form.