December 2010 Archives

Say Something Nice About Every Programming Language You've Ever Used

Recently, I came across a blog post from Dave Ray talking about wanting to say something nice about every programming language he’s used, which was inspired by a comment in a recent Michael Easter post. I’ve been thinking on this topic for a while now, and I think it’s a reasonable challenge. I firmly believe that a developer should be familiar with a wide breadth of languages, though it’s highly likely the depth of knowledge will be limited.

With that in mind, I’m going to take up this challenge to say something nice abotu every language I’ve ever used, in no particular order.

  • Basic - The flavor I learned on was GW-BASIC on MS-DOS. It is a simple language, but in spite of slightly awkward syntax, it was a powerful language which was easy to remember.
  • C - The first ‘real’ programming langauge I learned, it’s Syntax has been with me in pretty much every language I’ve used since. While C has a few abusable features, it is exceptionally expressive.
  • C++ - True multiple inheritance allows ofr some exceptionally powerful class heirachies that other object-orientied languages can make difficult to model. Plus, this is the language that introduced me to operater overloading, a feature I’ve missed in a great many other languages.
  • Perl - Regular Expressions built in as a core language feature? Hell yes.
  • Python - At first, I was incredibly resistant to the idea of whitespace importance in a language, however, Python’s clean, consistent syntax and it’s incredibly complete core libraries make it a joy to work in. And Python 3k was just that much better.
  • BASH - Still the best way I know of to automate tasks on Unix, plus, every program on the OS is trivially in your tooklkit.
  • Java - It’s Virtual Machine concept was a major source of inspiration to .NET?
  • C# - Everything that was good in Java combined with the great parts of C++. Plus, it just keeps getting more and more functional, which makes it better. Also, I love that it doesn’t have primitives, but instead provides aliases to core objects.
  • Ruby - I like some of the syntactic convetions, like boolean methods ending in question marks and default method and property handlers. It’s syntax is very powerful.
  • VBScript - Direct COM integration makes the language pretty extensible.
  • PHP - An easy langauge to pick up, with a lot of potential for templating, all with a pretty strong class system avaiable to those who go looking.
  • Go - A compiled language I’m pretty excited about. Yes, it compiles fast, but I love it’s version of interfaces that don’t require decleration on the implementing classes is awesome.
  • JavaScript - Looks like C, acts like LISP. It’s easy to learn, but it is one of the most powerful languages I’ve ever seen. Plus, NodeJS looks awesome on the server.
  • Fortran - Fascinating language that’s served as the basis for a lot of what came after, plus it still has a solid following within the scientific computing community and is used to drive a lot of interesting work.
  • Lisp - In spite it’s hatred due to all the parenthesis, this language is probably the single most powerful ever created. It was just decades ahead of it’s own time.

Huh, all those languages and only one that I couldn’t really be positive about. It’s somewhat cathartic doing this excercise, and I’m positive I’ve missed a few languages, but it was just a bit of fun.

A Comparison of JavaScript Compressors

1 Comment

At YUIConf this year, I mentioned to someone that I was playing around in Node with statically analyzing YUI to aid in crafting use statements that included no more than was strictly necessary. That’s an interesting idea, but is probably not very realistic in pure static analysis, and it’s really not the subject of this post. In that conversation, I was told about UglifyJS, a JavaScript compressor written for NodeJS that works by creating an abstract syntax tree of the JavaScript before minifying it. It seemed that an AST could help in my static analysis, so I started looking at it.

In the README file, under the “Compression - How Good is it?” heading, some basic figures were provided using two libraries (DynaARCH and jQuery) and three minifiers (UglifyJS, YUICompressor, and Google’s Closure Compiler). You can go read his results there, but I took a few issues with his data. First, we were not told what versions of the libraries he used, or the compressors. Recent versions of the YUICompressor have some significant performance increases that I wanted to test as well. Second, YUICompressor was designed to make a few decisions that were meant to improve gzip compressibility of a program, so you can’t really examine the compression without considering gzip, in my opinion.

Let me first describe my methodology. For time performance tests, I ran through each compressor 1000 times using the UNIX time program to get runtimes for each run, I then took the arithmetic mean of the runtimes for each library and compressor combination to get my figures for the following charts. I also ran each compressor one additional time to save a minified version to disk, and gzipped a copy of the minified file to do the file-size comparison. This was done with the aid of a shell script. The tests were run on my workstation, an AMD Athlon 64 X2 Dual Core 6000+ running Ubuntu 10.10, but of course the more interesting part is the relationships, not the raw data.

I tested the following libraries:

  • jQuery 1.4.3
  • Mootools Core 1.3
  • SimpleYUI 3.3.0pr1

Using the following compressors:

  • YUICompressor 2.4.5pre in command-line mode (Distributed with YUI Builder)
  • YUICompressor 2.4.5pre in server mod
  • UglifyJS 0.0.1
  • Google Closure Compiler from 2010.11.10, running with the SIMPLE_OPTIMIZATIONS flag

I want to first address speed. In the readme, the UglifyJS author says that Uglify is about twice as fast as YUICompressor and more than four times as fast as the closure compiler. One of the largest criticisms of closure compiler is it’s speed, and YUICompressor definitely suffered a similar reputation. However, in recent builds, Reid Burke of Yahoo! modified YUICompressor to run as a server that you could POST files up to using cURL, meaning you don’t need to pay the Java startup costs on every invocation. This has dramatically improved the performance.

Time to Compress Data

UglifyJS’s speed is very impressive, given that it’s a pure-javascript implementation. Anyone who thinks JavaScript is too slow now? However, when you take out the startup overhead by running YUICompressor in server mode, it destroys UglifyJS. And Closure is just slow, but everyone knows that. There is one fascinating anomaly in the above data, and that is jQuery. Now there are those who argue that jQuery’s code standards are somewhat shoddy, and that makes minifying it properly difficult, which may account for why YUICompressor takes so long to compress it. And Reid tells me that YUI Compressor uses a slightly different set of defaults in server mode as command-line mode. It would be interesting to see what about jQuery’s source hits this awful regression so hard.

Uglify’s process of building an AST of the program seems to be fairly resilient against poorly formed inputs, which is why it’s compression time seems to be more variable on file-size than anything else. While this means that Uglify is consistent, it does raise a few questions with me about it’s resilience. But I’ll do more on that later. For now, let’s look at compression.

File Size Comparisons Data

This comparison is going to be a lot more relevant for most users, since minification is something that is done rarely, where serving the files is done often. Again, the raw data is linked, but what is more interesting is the comparisons visible in the bars above. Closure and Uglify are pretty similar, with Closure usually taking the uncompresed file size, and Uglify being better once gzip is applied. YUICompressor definitely falls short here, coming in roughly 20% less efficient before gzip, and ~15% less efficient after gzip.

I am not saying not to use YUICompressor. Hell, I am looking at integrating it into our build process at work. Unlike Closure and Uglify, YUICompressor can do CSS, so you have one fewer applications to keep around for minification. There is a far more important point: YUICompressor is more conservative, and it changes less frequently. Closure is known to break code under certain circumstances, Uglify is not covered by as many tests as it’s creator would like.

Will Uglify break your code? I’m not sure. It’s mechanism and process look fairly safe, but it remains untested as far as many are concerned. I am interested in working on a set of Compressor test inputs which will verify the code is still functional and behaving consistently after compression, but haven’t begun that project yet. If these tests show anything it’s that YUICompressor should be used in server-mode if you care about it’s speed, and that it can definitely improve it’s minification ratio, and Uglify may be a good place to look for inspiration.

In the future, I hope that a set of confirmation tests for JavaScript minifiers will be available that ensures that the code they output behaves as expected.

Adding Columns to a YUI2 DataTable

In the new Schedules of Classes at Washington State University, I recently added Google Maps integration for showing where buildings are located on our campuses. One of our pages is simply a list of the buildings that are in our system. However, I wanted the mapping code to use progressive enhancement based on whether or not Latitude and Longitude data is available, and if the user is using a browser that will support the APIs that I’m using.

In the first version of the Buildings page, I had decided to use YUI2 DataTable, since YUI3’s was not available when I began, and it doesn’t yet support progressive enhancement as I would like. Using DataTable provided me with the ability to sort the data based on user preference, and should enable me to add filtering code in the near future trivially, though I am evaluating different YUI3 DataTable implementations to see if they’ll work for my needs.

The raw HTML table the datatable is based on doesn’t include the Latitude and Longitude data, nor do I think it should be, which means that once that data becomes available (either downloaded from the server or pulled from the browser’s local storage), I need to add that data to the table, and show the user an indicator whether or not building data is available. A YUI2 DataSource does not provide, as far as I can tell, a trivial way to add a column to it’s internal storage, which in my case was an HTML Table.

My source data was a simple JavaScript object, keyed off the first column in my table. Adding the rows required simple DOM manipulation, though for my example, I have wrapped the DOM TR Node in a YUI3 Node instance to get access to YUI3 sugar.

new Y.Node(source.liveData.tBodies[0]).get('rows').each(function(row) {
    var
        // Get the trimmed value of the Abbreviation
        abbr = row.one('td').get('text').replace(/^\s*([\s\S]*\S*)?\s*$/, "$1"),
        latlong = data[abbr], 
        // Test if latlong exists, and that it defines a Longitude and Latitude
        value = latlong && latlong.Longitude && latlong.Latitude;
    row.append("<td>" + value + "</td>");
});
source.responseSchema.fields.push({ key: "map" });

After the above code runs, there is a new column in all my data that is either ‘true’ or ‘false’ depending on whether or not the ‘data’ object contains latitude and longitude data, and the data will be available under the ‘map’ key on the datasource. Next, I need to add this column to the DataTable.

datatable.insertColumn({ key: "map", label: "Map?", formatter: function(el, oRec, oCol, oData) {
    if (oData === "true") {
        el.innerHTML = "<img alt='Map Available' src='/images/map_available.png' />";
    } else {
        el.innerHTML = "<img alt='No Map Available' src='/images/map_unavailable.png' />";
    }
}, sortable: true});

Running this will immediately add the column to the datatable, but the column will be blank in every row, becuase it the datatable hasn’t reparsed the datasource. This is where things got more difficult, as I could not locate an ‘updateData’ method (or analogue) on the DataTable prototype. Solving this required me to dig into the source for DataTable to see how it processed the source table on the initial load.

source.sendRequest(null, {
    success: datatable.onDataReturnSetRows,
    failure: datatable.onDataReturnSetRows,
    scope: datatable,
    argument: datatable.getState(),
null});

The first argument to sendRequest can be null, because I simply want to re-parse my liveData I updated earlier, while the second argument contains the methods on datatable that will cause my datatable to properly update, and making sure the execute in the proper scope. The final arugment has been replaced by the ‘scope’ decleration in the second argument, and should remain null in current and future YUI2 datatable code.

I hope that YUI3 DataTable will have an easier way to force a refresh of the DataSource after I’ve modified the data, whether that is via a ‘changed’ event on the DataSource or just a simple method which will perform the update. These may already exist, but without PE support, I haven’t really bothered to investigate it.