Reading the Classics: JavaScript – the Good Parts

I read Douglas Crockford’s JavaScript: The Good Parts over the long weekend. My interests were partially pedagogical. A huge part of my current job involves mentoring more junior developers and helping them to learn. One of my interests was whether Crockford’s book would be a good resource to pass along. It seems like a silly question. The book is still the book best known for putting JavaScript on the map as a quasi-respectable language. I learned JavaScript the way I have learned most languages which is to say, in the school of hard knocks. I had learned most of the good and bad parts of JavaScript through trial, error, Google and JSLint. The book wasn’t a bad refresher, but there weren’t a lot of new insights, either.

The timing makes the question genuinely difficult. ECMAScript 6 is out and some of the features are available now, more are available through polyfill and most of the rest could be acquired through Babel (https://babeljs.io/).

The book is, in a sense, almost obsolete. Almost. A good example of what I mean is prototypical inheritance. Crockford spends a lot of time explaining how class-based inheritance is different than prototypical inheritance. This is still relevant. JavaScript has remained a prototypical language. He also shows several techniques to make the meaning of JavaScript programs more clear to those used to classical object-oriented programming. This part is less relevant. Today, I would reach for the ES6 class syntactic sugar (via Babel for the browser) or CoffeeScript rather than layering some manual code over the prototype.

Similarly, Crockford discusses variable scoping at length. Again, this is partially relevant. The base scopes haven’t changed and they still easily trip up many programmers (I have used questions about JavaScript scopes to trip people up on interviews). These things need to be understood. However, the let statement in ES6 does provide some clearer semantics and its use should be encouraged as ES6 becomes widely available.

There are also new parts which, good or bad, require some level of explanation. Generators and promises will require explanation and, of course, categorization as either good or bad parts.

This sort of thing leaves me in a place where I want to recommend Crockford, but I feel the need to add some general commentary. Hopefully, a second edition of JavaScript: The Good Parts will come out in the next few years and make these little oddities of time go away.

Weighing in on JavaScript Package Managers

I have quite recently begun work on an open source project with a node back-end and front-end work planned to be done in React. This is my first full effort to work with the latest and greatest in JavaScript tooling. We use Ext JS and Sencha Cmd at work and, whatever else you want to say about that stack, it is different. My last full blown front-end development was before the real Node boom and I pretty much did it the old fashioned way — namely, downloading minified JavaScript by hand and referencing it in my markup (shaddup ya whippersnappers).

JavaScript saw a real explosion in package managers a few years ago, which was a natural place to go from a growing ecosystem to have none. Market forces naturally took over and many of the earlier examples have been culled out of existence. There are really two main options at this point: NPM and Bower. Bower has enjoyed a healthy following, but (by my entirely unscientific survey), it appears as though the NPM uber alles faction within the JavaScript world is growing stronger.

The sentiment is echoed in other places, but http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging gives a good overview of the fundamental syllogism. It basically goes that package management is hard, NPM is large and established, so you should use NPM everywhere rather than splitting package managers.

The argument has a certain intrinsic appeal – after all, the fewer package managers, the better, right?

The real problem is that it is possible to use NPM as a front-end package manager, but it is deeply unpleasant. Systems like Browserify and Webpack are needed to prepare dependencies for usage on the front-end. These are complex and, to a degree, brittle (I ran into https://github.com/Dogfalo/materialize/issues/1422 while attempting to use Materialize with an NPM application).

Even if one assumes that every package can ultimately be Browserified (and it doesn’t seem like an overly-optimistic assumption), the effort seems to be pure waste. Why would I spend time writing complex descriptors for modules on top of their existing packages? For it’s shortcomings, Bower seems more robust. I spent a few hours fiddling with Browserify and Materialize without much success (although I think I do see how browserify would work now), but mere minutes wiring up Bower.

This does not get into the fact that Browserify/Webpack require additional information to extract CSS, images and web fonts. Even when things are working, it would require constant effort to keep it all up to date.

At the moment, NPM, even NPM 3, simply does not have good answers for setting up front-end development. The NPM proponents really, in my opinion, need to focus on making front-end modules more effective rather than pushing tools that are little more than hacks, like Browserify and Webpack. At this point, I am just going to rock out with Bower. Maybe someday I will be able to trim out Bower — but I would rather spend time coding my application than giving NPM some TLC.

Putting it all Together: Reverting a Single Commit in Git

First, we locate the patch number with git log.

Then we dump it out as a patch

git format-patch -1 05bc54585b5e6bea5e87ec59420a7eb3de5c7f10 –stdout > changes.patch

(note that the -1 switch limits the number of patches…by default, git-format will pull many more.)

Once we know that we have the patches that we wish to roll back, we run this command:

git apply –reverse –reject changes.patch

Finally, we commit the reverse-changes.

The big thing is the -1 switch on git format. Many of the articles I found were pulling a large number of patches and I did not need it.

A Quick Note on Building noweb on Cygwin

My laptop has bitten the dust. Until I have the chance to open it up and see if the damage is fixable, I have been borrowing my wife’s computer to tinker (to her annoyance, I’m sure, but she used my laptop until we replaced the desktop so all’s fair). I was going to install noweb on cygwin, and hit the following error on build:

In file included from notangle.nw:28:
getline.h:4: error: conflicting types for 'getline'
/usr/include/sys/stdio.h:37: error: previous declaration of 'getline' was here
getline.h:4: error: conflicting types for 'getline'
/usr/include/sys/stdio.h:37: error: previous declaration of 'getline' was here

As I had built noweb before, this error struck me as a little strange. It turns out, that in stdio.h, Cygwin includes its own definition of getline, unlike on standard Unix-likes. A quick googling turned up that this was not unique to noweb, but that other packages had encountered similar difficulties. The answer that worked for me is here:

http://ftp.tug.org/mail/archives/pdftex/2006-February/006370.html

In sort, all one has to do is open /usr/include/sys/stdio.h and comment out the line that reads:

ssize_t _EXFUN(getline, (char **, size_t *, FILE *));

For safety’s sake, I reinstated the line after installing noweb and everything seems to be running fine.

Literature Review: PEGs

Parsing Expression Grammars, or PEGs, are syntax-oriented parser generators, meant to ease the task of building rich programming languages. I had had the opportunity to tinker with PEGs sparingly and, finally, I got around to reading the original paper (available here: http://pdos.csail.mit.edu/~baford/packrat/popl04/). My reading notes from the paper can be downloaded here:

http://www.mad-computer-scientist.com/blog/wp-content/uploads/2011/06/peg.html

I am fully aware that this is not, as it were, a new paper. It came up originally in my searches for a good parsing library in Common Lisp. For the project that it was intended for, I ultimately moved on to using Ometa. While Ometa is a fine system, it actually did not win on power grounds because, quite simply, I do not need the extra expressiveness for what I am working on. It won out because the implementation was better than the PEG library I had tried.

As it is kind of old territory, my review has little to say. In reality, when I first ran across PEGs I felt strangely out of the loop, but here goes anyway:

PEGs are a powerful mechanism for defining parsing grammars. The form of the language itself is similar to standard EBNF in its general layout, but allows native creation of grammars. It avoids the ambiguities inherent to Context Free Grammars by using prioritized selection of paths through the grammar. As a result, it is actually more powerful than traditional CFGs while being simpler to use.

While PEGs seem to have also caught on a lot better across than its predecessors (discussed in the paper), the seem to receive less notice than Ometa, which further builds on PEGs.

How WPF gets GUI programming right

WPF is another in a long line of Microsoft UI related technologies, each promising more than the one before. WPF is basically Silverlight for the desktop (or, if you prefer, Silverlight is WPF for the web). We have been building an application in WPF as of late at my place of employment, and I’d thought I’d post what I thought that WPF does right.

The biggest thing is that WPF builds UIs declaratively. I cannot stress enough how important I think this really is. The biggest pain about using Java’s Swing framework was writing long sequences of code that initialized controls in a form’s constructor. Under the hood, Windows forms works pretty much the same way. The biggest difference is that Microsoft ships a nice designer with Visual Studio, so the raw kludginess of the approach is hidden from most programmers, since they look at everything through the lens of the designer.

The declarativeness goes beyond simply allowing one to declare that widgets will exist to their layout (via the Grid mechanisms–really, these should be used by default and the designer left on the shelf) and their data flow. The latter is particularly interesting. ASP.NET has data binding, but the version employed by WPF is far more sophisticated. When I jumped back to an ASP.NET project, I immediately found myself missing the power of WPF databinding, but to add it to a web framework would unquestionably require a continuation based framework like the one employed by Weblocks or Seaside.

The importance here is that both the interface and how it interacts with data can be declared. Many GUI designers and markup languages have come along that allowed one to declare the layout, but few, if any, mainstream GUI designers have allowed so much expressiveness.

The hard part about all this, is that C# is a statically typed language and, as a result, a lot of these features are based heavily on reflection which is a performance hit, due to the fact that the JIT compiler cannot really optimize these things. Perhaps it was just my imagination, but I feel pretty sure that WPF applications lag behind their windows forms cousins in terms of speed.

All in all, though, WPF is a fine framework, though.

Polymorphism, Multiple Inheritance, & Interfaces…Pick 2.

The title for this post comes from a statement that was brought up by a  coworker as having been said to him. The overall point of this post will be simple: given that choice, your answer should be obvious: you want polymorphism and multiple inheritance, because there is nothing that you can do with interfaces that you cannot do with multiple inheritance.

Interfaces provide two things, depending on their use: a form of multiple inheritance in languages that do not otherwise support it and design-by-contract capabilities. Clearly, in the former case, you are better off with multiple inheritance, as you receive the full power of the feature. In the latter case, it is trivial to create an almost-empty class that acts as an interface, if that is the effect you are after.

The main objection raised was the counter example: what if you have a class Animal and another class Plant. Surely you do not want a programmer to inherit from both? That would not make sense. To which I would answer Why not? If it makes sense to whomever wrote it, why prevent it? They might, after all, be creating something for the little shop of horrors.

Largely, I  think the thinking that interfaces are somehow superior to multiple inheritance comes from never having used multiple inheritance in a system built from the ground up to support it (like CLOS in Common Lisp) as multiple inheritance strictly supersedes interfaces.

The Literature

Looking back at my last few posts, something occurred to me: a lot of the more exotic focus of this blog has been lost. While I enjoy examining MVVM and QuickBooks, one of the whole points of this blog was to offer a fusion between useful code monkey concepts and computer scientist (hence, the domain name of this site). Lately, there has not been much “scientist” at the mad computer scientist.

One of my new series of posts is going to be literature reviews. I have a massive reading list of computer science papers queued up as well as some other materials. In these posts, I will read a journal article or watch a lecture and post my notes and thoughts about it. The first one will be coming soon, so look out for it.

More on Microblogging and Programming

I had been rolling around some thoughts on microblogging and programming since my last blog post. First of all, I found it interesting that Twitter started life as an internal project before getting VC funding. This reenforces, to me, the value of what I as saying, which is that microblogging for more limited audiences and topics is more useful than the present day and age where we have people microblogging about brushing their teeth.

I have also been interested in doing more work on Sheepshead. According to gitorious, my last commit was over a month ago. Such are the results of having a family, a job, and a life–but I really want to get back to working on it. As I start gearing it all up again, I have decided to try a little experiment. Instead of simply waiting on someone else to try out microblogging for a small development team, I am going to try to bootstrap a small team while microblogging. As I develop Sheepshead and push it forward, I am going to try and use microblogging to mull over design decisions and announce progress.

The service I have decided to use for this endeavor is Identi.ca (you can see the stream here), rather than the more ubiquitous Twitter. I did this for a few reasons, chief among them being that I expect there to be more engineering types as well as more open source-minded individuals on Identi.ca. Another important consideration is that Identi.ca allows its users to export data. My intention is to keep backups of the information on the feed, so that if something were to happen to Identi.ca and the project attained a meaningful size, a StatusNet instance could be setup, even if only as a stopgap.

We will see how this all goes (or if it does–I can definitely see how Sheepshead is sort of a niche development). In the mean time, I am going to try and get some code written.

Linq to Sql is not fit for GUI Applications

The title is a little incendiary, I admit, but I think it is a good place to start.

We are building a database-driven application with WPF (using MVVM) & Linq to SQL and, in the process, a few caveats about Linq to SQL have come out in a truly fine way.

The issues all revolve around that little innocuous thing known as a DataContext. For those of you who may not be familiar with the idea, in Linq to SQL a DataContext is “the source of all entities mapped over a database connection. It tracks changes that you made to all retrieved entities and maintains an “identity cache” that guarantees that entities retrieved more than one time are represented by using the same object instance.”

Further down the reference page for the DataContext we read that

In general, a DataContext instance is designed to last for one “unit of work” however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations.

so the most logical place to create and dispose of our DataContexts is in the methods that implement the business logic. This works perfectly well for retrieving data, and for updates on entities that have no relationships, but fails with a

Cannot Attach An Entity that already exists.

exception when an update is made to entity relationships. The problem is that Linq to SQL cannot move objects between DataContexts, so if one context was used to lookup the object in question and another was used to lookup one used in a relation (say, to a lookup table), then Linq throws the fit seen here. In a web application, it is much easier to keep this from ever happening, as a single DataContext will likely be used to do the work from a BL call (or, at least, the calls will be sufficiently separate as not to trod on each others’ feet).

If the context is moved up to the business object layer (i.e. as a static member), the problem is partially alleviated and partially aggravated. It is somewhat alleviated in that all of the objects of a certain type will, at least, have been pulled from a central DataContext and so will have no issues amongst themselves. However, there is still the issue of when an object is set (via databinding) from a list that was pulled by another datacontext. An easy, and genuine example, is where one entity (call it A) has an attribute named “type”, which must be one of the entries in a lookup table (which we will call entity B). If a drop down list is databound to the entries in the lookup table are pulled by entity B (the most logical choice) the same error message as above is hit–unless, of course, all of the entities are repulled by entity A’s datacontext before saving. A labor-intensive, innefficient, and maintenance heavy process. At any rate, the application could be written this way, but not without a great deal of effort to repull and remerge data with a single context.

Finally, one could move the context up to the application layer–the entire application shares a single datacontext. The problem with this is that, in an application where multiple tabs or windows can be open, if any single object attempts to save its changes via SubmitChanges, the pending changes for all windows will get submitted, even if the user comes back and hits “Cancel”. The result in this scenario is utter and complete chaos.

Ultimately, what we did in this scenario was to create a single DataContext per ViewModel (where we experienced issues with this, not universally) and pass it through all of the data fetching operations. The bookkeeping was certainly a little tedious to write, but it worked. From a conceptual standpoint, this is very dirty as it makes the presentation layer aware, even in a limited sense, of what is being done by the data access layer. While Linq to Sql is very nice, it has some very bad shortcomings when used in GUI applications.