Friday, August 24, 2007

Why do they call it Javascript ? It's not Java and it's way powerful for a scripting language!

A couple of days back, I was enjoying Steve Yeggey's keynote on Software Branding at the OSCON 2007. Talking about the negative aspects of branding, he mentioned about Javascript, a name which never helped the growth of the language. Glenn Vanderburg, another noted Ruby convert, says in his NFJS writings:
I still think that naming decision was a bad idea. It caused no end of confusion. Many nonprogrammers never figured out that Java and JavaScript were two different things.

In an earlier post, I had mentioned how the Rhino scripting engine and externalized business rules in Javascript saved us the day in one of our client engagements. That experience had me thinking about the virtues of polyglot programming, usefulness of embeddable scripting engine in Java 6 and the essence of the JVM as the next ubiquitous computing platform. However, it took me some more time and a couple of more blog readings to realize the power and elegance of Javascript as a language. Indeed all the capabilities of Javascript within the browser are add-ons to the simple virtues that the language imbibes.

In gensym.org, David mentions about the following Scheme implementation of a snippet that picks up the maximum salary of a programmer amongst a collection of employees having various roles:


(define (salary-of-highest-paid-programmer records)
  (accumulate
      max 0
        (map salary
          (filter programmer? records))))



He observed that the normal Java implementation will be much more verbose compared to the Scheme one. I tried out a Javascript implementation for the same problem ..


maxProgrammerSalary = function() {
    return {
        maxSalaryFun : function(emps) {
            return reduce(
                Math.max,
                0,
                map(pluck('salary'),
                    filter(
                        callMethod('isProgrammer'),
                        emps)))
        }
    };
}();



The code looks wonderfully similar to the Scheme implementation in structure using the functional paradigms. I really feel bad now that I have chosen to ignore this language so long. Like Glenn Vanderburg, this is my personal story of coming full circle with Javascript.

Of course the above implementation uses a couple of functions, which we have to define today or get it from libraries like prototype. With Javascript 1.6 Array extras and the new features in progress for Javascript 1.8, almost all of them will be part of the core language.

Javascript as a language

Being a prototypal language like Self, Javascript's tryst with OO principles are very much different from the classical strongly typed model of Java or C++. Prototype based inheritance was made hugely popular by frameworks like prototype and enthused many UI folks to the world of practicing OO programming.

A language does not necessarily have to preach OO in order to be beautiful - Javascript supports encapsulation and separation of concerns in its very own way, as has been amply demonstrated by the Module pattern all across YUI. I can have my properties declared at the appropriate level of abstraction without polluting the global namespace. In case of the above function for computing the salary of employees, if we were to fetch the employee collection from some data source and need to define some helpers for the computation, we can have a nicely defined module that encapsulates the whole computation model in a separate namespace:


maxProgrammerSalary = function() {

    // this is not exposed to the global namespace
    var getEmployees = function() {
        // get the employee list
    }

    return {
        maxSalaryFun : function() {
            return reduce(
                Math.max,
                0,
                map(pluck('salary'),
                    filter(
                        callMethod('isProgrammer'),
                        getEmployees())))
        }
    };
}();



A Growing language

One of the definite indications of the growing popularity of a language is the growth rate and increasing rate of adoption. While I do not have any concrete figures on the latter, there have definitely been lots of buzz in the blogosphere about the increasing importance of Javascript as a language. We have started seeing frameworks like jQuery, with its own programming patterns and DSL based approach. jQuery custom selectors, along with chaining gives you the programming power of using FluentInterfaces - here is an example from recently published Jesse Skinner's article ..


$('form#login')
    // hide all the labels inside the form with the 'optional' class
    .find('label.optional').hide().end()

    // add a red border to any password fields in the form
    .find('input:password').css('border', '1px solid red').end()

    // add a submit handler to the form
    .submit(function(){
        return confirm('Are you sure you want to submit?');
    });



This snippet is a succinct one-liner that selects the login form, finds some stuff, repeatedly going back to the form after each find, makes some changes to them and finally adds a submit event handler to the form. All the complexities of query optimization and DOM scripting are taken care of by the jQuery engine. When we see lots of programming idioms being discussed actively amongst the experts, it is the sign of a growing programming language. In my short stint towards loving Javascript, I discovered great idioms for lazy function definition, memoization, currying and other functional programming patterns being discussed vigorously in the community. In an earlier post, I had also discussed about the plethora of developments going on in this space.

Thoughtleaders of the programming language community think that Javascript 2 is one of the contenders for NBL. It has lots of features which will delight you as a programmer. It is succinct, it is functional with full support of closures, it is prototypal and it is dynamic. You can add methods to classes even after instantiation. It's a different paradigm altogether from the noun-land of Java. And it's also the most natural glue to the browser. Learn to love it now or ignore it at your own risk.

Monday, August 20, 2007

Learning a programming language can be fun

Giles Bowkett makes a great point about how one-liner code snippets often make a great idiom in a programming language. It is always worth learning the idioms of a language than memorizing the syntax, and, as Giles mentions, a good one-liner compresses syntax down to idiom. Reading his blog, I instantly remembered the first one-liner in a programming language that gave me my first Aha! moment while learning C. The K&R bible, in Section 5.5, builds up the various versions of the C library function strcpy() that improves in conciseness and succinctness in every iteration and ultimately culminates into this power-packed one-liner ..

void strcpy(char *s, char *t) {
    while (*s++ = *t++);
}


In the very next paragraph, the authors mention ..

Althought this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs.


So true!

If you want to learn a programming language, invest most of your time learning the idioms - that's where you will discover the densest knowledge about using the language in the best possible way. As Giles mentions ..

But the act of compressing code into a one-liner is like the act of creating slang, and if you understand how slang comes into being, you understand how to make new words.


During my learning years of C++, one book that stood out in teaching the idioms of the language was Coplien's Advanced C++ Programming Styles and Idioms. The book was written way back in 1992, but remains my #1 recommendation for someone learning C++ even today. Many of the design patterns so popularized by the celebrated GOF book had already been beaten to hell in the Coplien book.

Often there is a fine line of misunderstanding between a syntax and an idiom ..

Many years back, in an interview for hiring a C++ developer, I had asked one candidate to explain the function prototype of a typical assignment operator overloading function. I believe that a candidate able to explain the nuances of the assignment operator overload function prototype in C++ has a good understanding of the basics of the language. Specifically I wanted him to explain the return type and value of the usual assignment operator overload function of a class in C++.

Foo& Foo::operator=(const Foo& right) {
  // ..
  // ..
  return *this;
}


  • Why does the function return *this ?

  • Why does the function not return right ?

  • Why does the function take a reference-to-const-Foo ?



I felt this is an important idiom of C++ that developers should be thorough with, and a correct explanation by a person reveals a good understanding of multiple aspects of the language - variable lifetime, temporaries, idiomatic usage of assignment etc. Unfortunately the candidate was furious with me and complained that he does not memorize syntaxes - what are manuals for ? What he did not realize is that a proper understanding of the idiom of how assignments can be chained through references in C++ obviates the necessity of syntax memorization.

Learning a new programming language can be fun

This thread in the discussion of Lightweight Languages has an interesting list of the available options .. Amongst all of them, the most interesting one suggests to (t)ry to identify and concentrate on features of the language that are absent from other languages you know. I am sure this is a very effective way to know the idioms of a language and how to make new words with the language that you are trying to learn. Try implementing map/reduce in Javascript, lazy data structures in Erlang, Lisp like macros in Ruby - apart from the loads of fun that you will be having, you will learn the new language as well.

Every language has its own form - a Ruby program has to look like Ruby. The moment your Ruby code starts looking like Java, then you are no longer thinking in Ruby. This is the essential difference between idiomatic and non-idiomatic use of a programming language. Try exploring the following one-liner in Ruby ..

Account = Struct.new(:account_no, :account_name, :account_type)


and see how concise you can do for an equivalent Java snippet. Now that's hell of a one-liner in Ruby! And an important idiom too ..

Monday, August 13, 2007

Collector Idiom in Scheme - Is this a Design Pattern ?

As a newbie into the world of functional programming (one of my new year resolutions for 2007), I started my venture to learn the skills of constructing recursive processes and manipulating recursive data structures with Friedman and Felleisen's The Little Schemer. I am now into Chapter 8, Lambda The Ultimate, sailing through The Ninth Commandment (Abstract Common Patterns with a new function) and into Page 137 of the text. And here I meet multirember&co(), destined to be my thought-process-companion for the last one week. It took me quite some cycles of stepping through the debugger of DrScheme to figure out the actual computation process going on inside the stacks of lambdas that the function defines.

Here is a copy of the function for those uninitiated to the amazing text ..

(define multirember&co
  (lambda (a lat col)
    (cond
      ((null? lat)
       (col (quote()) (quote())))
      ((eq? (car lat) a)
       (multirember&co a
                       (cdr lat)
                       (lambda (newlat seen)
                         (col newlat
                              (cons (car lat) seen)))))
      (else
       (multirember&co a
                       (cdr lat)
                       (lambda (newlat seen)
                         (col (cons (car lat) newlat)
                              seen)))))))



What does this function call (multirember&co a lat f) do ?

In the words of the authors ..
It looks at every atom of the lat to see whether it is eq? to a. Those atoms that are not are collected in one list ls1; the others for which the answer is true are collected in a second list ls2. Finally it determines the value of (f ls1 ls2).

The statement of work is quite straightforward. I tried implementing the same in another functional language, Erlang, and it did not take me too much time to come up with a supposedly meaningful Erlangy implementation ..

filter_atom(A, L, Col) -> filter_atom(A, L, [], [], Col).

filter_atom(A, [H|T], Has, NotHas, Col) ->
  case (=:= A) of
    true    -> filter_atom(A, T, [H|Has], NotHas, Col);
    false   -> filter_atom(A, T, Has, [H|NotHas], Col)
  end;

filter_atom(A, [], Has, NotHas, Col) ->
  Col(Has, NotHas).


The Erlang implementation looks simple enough and does not have the accidental complexity that we find in the Scheme implementation.

Honest confession : I am also a newbie in Erlang - any suggestions for improvements towards a more Erlangy modeling is welcome!

Why does the Scheme implementation look so complex ?

Coming back to the Scheme implementation, I am not sure if this is the most idiomatic implementation of the solution. But it definitely is an ample demonstration of the power of closures (lambdas). The inner lambdas build the new collectors by getting stuff from the enclosing scope and constructs values that are handed over to the next collector in the stack. This is precisely what the Tenth Commandment preaches - Build functions to collect more than one value at a time.

Is this a Design Pattern ?

The idiom of using the Collector for building up values has been used in subsequent function implementations as well - refer to multiinsertLR&co() and evens-only*&co() in the same chapter of the book. Given a list, and some predicate, the Collector idiom uses continuation passing style (CPS) to create closures that successively collects multiple values from the list. Is there a design pattern lurking around ?

I am not qualified enough to comment on the virtues of the above Scheme implementation. One great thing about it is that the above implementation is tail recursive. I can come up with an accumulator based implementation, which is not tail recursive, but possibly has less of an accidental complexity.

What do the experts have to say about the collector based idiom ?

Wednesday, August 08, 2007

Is the Java Culture changing ?

Came across a reference to this slightly old artima post through an unlikely source - a posting by Paul Graham in a discussion thread on lightweight programming languages. The weblog quotes Gilad Bracha defining Java Culture in the context of explaining why hygienic macros should not be added to the Java programming language ..
The advantages of Java is that it easily serves as a lingua franca - everyone can read a Java program and understand what is going on. User defined macros destroy that property. Every installation or project can (and will) define its own set of macros, that make their programs unreadable for everyone else. Programming languages are cultural artifacts, and their success (i.e., widespread adoption) is critically dependent on cultural factors as well as technical ones. .. Most Java developers are happy to have dedicated, narrowly focused solutions that are tailored to a specific problem. I am keenly aware of the drawbacks of such an approach, but I don't see it changing very quickly.

Does this mean lesser power in abstraction and dumbing down programmers in an attempt to get a wider audience for your language (aka Language For the Masses - LFM) ? Paul Graham, in one of his rants against OO, mentions about the pack-programming world of discipline-imposing languages being oriented to social packs.

Do you think we are going through a change in the Java Culture and that Sun has changed its position on LFM over the last couple of years ? And how much it has got to do with the Ruby (r)evolution ? We have had the whole slew of features in Java 5 and now we are talking about adding on closures in the language and tail calls and tuples in the VM ..

Monday, August 06, 2007

Befriending Javascript

Jerry Seinfeld had once said that according to most studies, people's number one fear is public speaking. I am not very comfortable speaking in public, but as far as Web application development is concerned, my numero uno fear factor was Javascript. Since then I tended to avoid this beast like anything and promptly started proclaiming myself as the server side guy.

Days have changed, positioning of Javascript as the ubiquitous computing runtime for the Web has started getting more traction. We are seeing more standards evolving, Rhino bundling with the JDK has given the server side guys more options towards DSL based designs. Lots of stuffs are happening in the scripting world, in general, and Javascript, in particular. In one of my earlier posts, I had described how we used server side scripting to externalize business rules from a business application. This post is a continuation of my belated attempt at befriending Javascript, with a special mention about the functional programming capabilities using the language. Have a look at the following snippet :


map(compose('+1', '*2'), [1,2,3])



which produces [3, 5, 7]. This is Functional Javascript.

In one application, I had to do some list processing as part of client side validation in a financial application and get counts of tax/fees which exceeded a predefined max. I started the usual imperative way using the nuts and bolts of if-then-else and for loops. Things looked ok initially, but started getting clunkier when lots of similar variants in processing logic came up and the code started looking boilerplate. Some googling pointed out that with Javascript's functional power you can kick it up another notch. You can program to the map-reduce paradigm and make full use of Javascript's higher order functions to carve out your client side validation library.

Here are some snippets using Oliver Steele's functional Javascript ..


count_grt_max = function(array, max) {
  function count(total, element) {
    return total + (element > max ? 1 : 0);
  }
  return reduce(count, 0, array);
}



And when the validation logic gets more complicated with more and more clauses being added, use the full power of functional Javascript ..


// get the sum of tax fee values which pass the
// minimum and maximum criteria validations

reduce('x y -> x + y',
    0,
    select('>' + max,
        select('<' + min, tax_fee_values)));



While this may seem an unnecessary functional engineering at work for a seemingly trivial task, there are situations where you surrender yourself to the temptation of beauty and sacrifice an element of utilitarianism. And, of course there are use cases in every application, which do not need the raw harness of your favorite performant enterprise language. Use the many functional javascript libraries to spruce up your client side scripting - remember you can use the same scripts for server side validations as well (wow! Rhino!).

The Language

Douglas Crockford notes that
... JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.

all the spices to spruce up your lambdas and closures ..

Erik Kidd is working up to a Ruby esque metaprogramming library for Javascript including porting of RSpec, and Steve Yeggey has butchered Rails into Rhino. Prototype has added lots of Ruby features into Javascript, which are now being used as the base to implement ActiveRecord like features in TrimPath. After a two year hibernation, it is good to hear that TrimPath is being defrosted. With TrimQuery, you can write the following query on the client side for structured Javascript data records ..


// First we precompile the query language object with the schema...
var queryLang = TrimPath.makeQueryLang(columnDefs);

// Next, we do a SELECT statement.
var statement = queryLang.parseSQL(
    "SELECT Customer.id, Customer.acctBalance, Invoice.total " +
        "FROM Customer, Invoice " +
        "WHERE Customer.id = Invoice.custId " +
        "ORDER BY Customer.id ASC");

// Here we run the query...
var results = statement.filter(tableData);
//..



And none of the above is strictly about the Web - there is a growing community enriching the usage of Javascript as a language.

Google Gears - another reason to learn Javascript

Talking about client side persistence, Gears offers a framework for creation of offline browser applications with an embedded SQLite relational database system. Gears offers Javascript APIs for creation of databases, manipulating data and processing resultsets.


var result = db.execute(
    "SELECT * FROM persons"
);
var fieldCount = result.fieldCount();
while(result.isValidRow()){
    for(var i = 0; i < fieldCount; i++){
        var value = result.field(i);
    }
    result.next();
}
result.close();



And Gears is a framework which works offline without the server connection - it is meant to develop applications for the browser, not only for the Web. The rich set of Javascript APIs allows us to build client side persistence on top of a database service. Javascript is no longer the lingua franca for the Web only - it is turning out to be a rich platform for client applications in offline browsers as well. In the server side, as well, Javascript is making an emphatic comeback. Projects like Helma is an ample testimony towards this. For more news on advancement of Javascript as a language, have a look at this document.

Is the browser going to be the next ubiquitous computing platform ? I need to do a lot of catching up ..