Party time Over for Rails .. It's time to Deliver !

People have increasingly started talking about Erlang and putting the concurrency-idol on the hot seat for an upcoming session of dissecting its anatomy. Possibly the fan fare of Rails has started taking a backseat. Is this a sign of maturity for Ruby on Rails ? Or a case of disillusionment ?

As Brian points out :

In terms of the Gartner Hype Cycle, Ruby and Rails are nearing the end of the "Peak of Inflated Expectations" and are moving into the "Trough of Disillusionment".

It's indeed true that Rails have enjoyed the limelight of being the darling of the community and a promise (or panacea) to put an end to the verbosity and *inelegance* of Java based Web development. It has been quite some time though, yet we hear people like Obie utter the following in the context of choosing Java over Rails in developing Big Enterprise Applications :

Like Gavin pointed out, you can't do an app with thousands of model classes in Rails. Okay, but I'm really not trying to say that you should try. Right now, I personally have no interest in working on those kinds of monstrosities, but to each his own. If that big enterprise application exposed web interfaces, I might be inclined to use JRuby on Rails to do those..

It's time to deliver for Rails ! How long will Rails shrug away from the enterprise applications branding them as monstrous ? It's time to take Rails out of the playful scaffolding model that delivers basic CRUD applications at lightening speed. To deliver complex enterprise applications, you need a performant application server with production quality deployment support, a real fast virtual machine and solid domain modeling capabilities. We all know the ActiveRecord model is never going to scale up for large complex domain models. The Rails community, till now, do not acknowledge how important it is to have a separate domain model, decoupled (or loosely coupled) with the persistence layer. And ActiveRecord will never take you towards that end. How much strong metaprogramming capabilities you may use to offer fancy dynamic finders in Rails, ultimately you need to have a strong decoupled domain model to deliver big enterprise applications. Till then, I guess, JRuby will be your best bet and Rails will remain just another Java library sucked up within a Java application server.

Domain Modeling with JPA - The Gotchas - Part 1 - Immutable Entities

Working on rich domain models, how many times have we wondered if we had a cookbook of best practices that discussed some of the common gotchas that we face everyday. With this post, I would like to start a mini series of such discussions, which will center around issues in rich domain modeling using JPA and Hibernate. In course of this series, I will discuss many of the problems, for which I have no satisfactory solution. I would love to have the feedback from the community for the best practices and what they feel should be done to address such issues.

Each installment of this series will discuss a single issue relevant only to designing rich domain models using JPA and Hibernate. With enough reader feedback, we should be able to have a healthy discussion on how to address it in the real world of domain modeling using the principles of Domain Driven Design. The topic of today's post is Immutability of Domain Entities and how to address this issue in the context of modeling persistent entities. While no one denies the fact that immutability is a virtue that a model should maximally possess, still there are practical concerns and reasons to act otherwise in many situations. The domain model is only one of the layers in the application architecture stack - we need to interact with other layers as well. And this is where things start getting interesting and often deviate from the ideal world.

Immutability (aka public setter methods)

There are two aspects to immutability of entities.

#1 : Making an Entity intrisically Immutable

An entity is immutable in the sense that *no* update or delete are allowed for that entity. Once created the entity is truly *immutable*. The Hibernate annotation @Immutable can be used to indicate that the entity may not be updated or deleted by the application. This also allows Hibernate to make some minor performance optimizations.

@Immutable
public class Bid implements Serializable {
  // ..
  // ..
}


Needless to say, we do not have any setter methods exposed for this entity.

Immutability can also be ensured for selective columns or properties. In that case the setter method is not exposed for this property and the ORM generated update statement also does not include any of these columns.

@Entity
public class Flight implements Serializable {
  // ..
  @Column(updatable = false, name = "flight_name", nullable = false, length=50)
  public String getName() { ... }
  // ..
}


For the above entity, the name property is mapped to the flight_name column, which is not nullable, has a length of 50 and is not updatable (making the property immutable).

#2 : Immutable in the domain layer

This is one of the most debated areas in domain modeling. Should you allow public setters to be exposed for all entities ? Or you would like to handle all mutations through domain methods only. Either way there are some issues to consider :

If we expose public setters, then we risk exposing the domain model. Any component in the layers above (e.g. Web layer) can invoke the setter on the entity and make the domain model inconsistent. e.g. the Web layer may invoke account.setOpeningBalance(0), despite the fact that there is a minimum balance check associated with the domain logic. We can have that validation within the setter itself, but ideally that domain logic should be there in the domain method, which is named following the Ubiquitous Language. In the current case, we should have a method named account.open(..), which should encapsulate all the domain logic associated with the opening of an account. This is one of the fundamental tenets of rich domain models. From this point of view, smart setters are an anti-pattern in domain modeling.

If we do not have setters exposed, then how will the Web MVC framework transport data from the Form objects to the domain objects ? The usual way frameworks like Spring MVC works is to use the public setter methods to set the command object values. One solution is to use DTOs (or one of its variants), but that is again one of the dark corners which needs a separate post of its own. We would definitely like to make a maximal reuse of our domain model and try to use them throughout the application architecture stack. One of the options that I have used is to have public setters exposed but control the usage of setters only in the Web MVC layer through development aspects. Another option may be to introduce public setters through Inter Type Declaration using aspects and use the introduced interface in the Web MVC layer only. Both of these options, while not very intuitive, deliver the goods in practice. You can do away with exposing setters *globally* from the domain model.

What about getters ? Should we have

Collection<Employee> getEmployees() {
    return employees;
}


or

Collection<Employee> getEmployees() {
    return Collections.unmodifiableList(employees);
}


In the former case, the collection returned is not immutable and we have the convenience of doing the following ..

Employee emp = ...  // make an employee
office.getEmployees().add(emp);  // add him to the office


while all such logic will have to be routed through specific domain methods in case of the enforced immutability of the returned collection for the second option. While this looks more ideal, the first approach also has lots of valid use cases and pragmatic usage.

Use the comments section of the post to discuss what approach you take when designing rich domain models. There may not be one single golden rule to follow in all scenarios, but we can know about some of the best practices followed in the community.

Code-as-Data, Encapsulation and the Lisp Dogma

Raganwald talks about code/data separation and encapsulation. Here he quotes Steve Yegge from one of his drunken rants, where the latter points out the virtues of using Lisp s-expressions as executable XML.



Just could not resist ruminating Douglas Hofstadter in his Metamagical Themas on the same subject in his essay Lisp: Recursion and Generality. He talks about Lisp as the medium that unifies the *inert* data (which he calls declarative knowledge) with *active* code (or procedural knowledge). He mentions ..

The main idea is that in Lisp, one has the ability to "elevate" an inert, information-containing data structure to the level of "animate agent", where it becomes a manipulator of inert structures itself. This program-data cycle, or loop, can continue on and on, with structures reaching out, twisting back, and indirectly modifying themselves or related structures.

Talking about this data-code duality he goes on ..

Moreover, Lisp's loop of program and data should remind biologists of the way that genes dictate the form of enzymes, and enzymes manipulate genes (among other things). Thus Lisp's procedural-declarative program-data loop provides a primitive, but very useful and tangible example of one of the most fundamental patterns at the base of life: the ability of passive structures to control their own destiny, by creating and regulating active structures whose form they dictate.

Steve Yegge has also expressed it succinctly in the same post (mentioned above) ..

But Lisp is directly executable, so you could simply make the tag names functions that automatically transform themselves. It'd be a lot easier than using XSLT, and less than a tenth the size.

When you have code-as-data and data-as-code, you have encapsulated the data structures in a form where they can transform themselves. While Lisp allows you to do this, is it too unnatural for a programming language that forces you to program in its native abstract syntax tree format?

Got Closures ? Have OO

In the classical object oriented model, an object encapsulates local state (instance variables) and contains a pointer to the shared procedures. These procedures are the methods, which operate on the encapsulated state, that forms the environment of the object. Each method can declare local variables as well as look up for additional state information from the shared environment based on lexical scoping rules. So we have the object as the combination of the environment and the set of methods that operate on the environment. Class based languages like Java and C++ provide another abstraction - the class, which instantiates objects by initializing the environment and setting up appropriate pointers to the shared procedures.

But what if my programming language is classless ? One of the best examples of this is the Javascript language. It is based on prototypes, without the class structure and supports higher order functions and lexical closures. How do I implement object-orientation in Javascript ? Javascript is a prototypal language without any built in support for classes. This post attempts to look into OO through a different looking glass, a quite unnatural source, a quite different language and a very much different programming paradigm. In the absence of first class support for the classical OO paradigm, this post looks at alternative means of implementing encapsulation and object-orientation while designing real world abstractions. The language used is Scheme, popularly referred to as a functional language, and the implementation addresses all issues faced by the other numerous classless languages mentioned above.

The basic theme of the following discussion is from SICP, a true classic of Computer Science in the domain of programming languages. In case you have any doubt regarding the credibility of SICP, please go through the first two customer reviews of this book in Amazon.

Object Orientation - the Scheme way !

Let us look at the following abstraction of a bank account in Scheme ..

(define make-account
  (lambda (account-no account-name balance)

    ;; accessors
    (define (get-account-no) account-no)
    (define (get-name) account-name)
    (define (get-balance) balance)

    ;; mutators
    (define (set-account-name! new-account-name)
      (set! account-name new-account-name)
      account-name)

    ;; deposit money into account
    (define (deposit! amount)
      (set! balance (+ balance amount))
      balance)

    ;; withdraw money
    (define (withdraw! amount)
      (if (>= balance amount)
          (begin (set! balance (- balance amount))
                 balance)
          "Insufficient funds"))

    ;; the dispatcher
    (define (self message)
      (case message
        ((no)         get-account-no)
        ((nm)         get-name)
        ((balance)    get-balance)
        ((set-nm!)    set_account-name!)
        ((withdraw!)  withdraw!)
        ((deposit!)   deposit!)
        (else (error "unknown selector" message))))
    self))


Every time we call make-account, we get back a dispatch function, every instance of which shares the same code, but operates on the different set of data supplied to it, which forms the execution environment.

;; creates an account a1
(define a1 (make-account 100 "abc" 0))

;; creates an account a2
(define a2 (make-account 200 "xyz" 0))

;; fetches the account-no of a1 -> 100
((a1 'no))

;; sets the account-name of a1 to "pqr"
((a1 'set-nm!) "pqr")


That is, we have two separate objects for the account abstraction and a bunch of shared methods to operate on each of them. A clean separation of code and data, a nice encapsulation of state. The arguments passed to the make-account invocation, account-no, account-name and balance are completely encapsulated within the abstraction and can only be accessed through the shared procedures.

The Secret Sauce

Lexical closures! In the above code snippet, all free variables within the methods are looked up from the environment of execution based on the lexical scoping principles of Scheme. This is exactly similar to the classical OO model that we discussed in the beginning. In the model with first class objects, we have

• the environment formed by the instance variables, encapsulating local state per object and


• the methods, which are shared across objects.

These two orchestrate the mechanism through which behaviors are implemented in abstractions. OTOH in languages like Scheme and Javascript, the corresponding roles are played by

• the execution context, where the procedures look up for free variables and


• the procedures themselves.

Hence closures play the same role in the Scheme based implementation that objects play in a classical one with Java or C++. Here is what wikipedia has to say :

a closure is a function that is evaluated in an environment containing one or more bound variables. When called, the function can access these variables. The explicit use of closures is associated with functional programming and with languages such as ML and Lisp. Constructs such as objects in other languages can also be modeled with closures.

What about Inheritance ?

We can implement inheritance in the above abstraction by using the delegation model. This is an object based implementation, similar to what we do in classless languages like Javascript. Simply incorporate the specialized behaviors in a new abstraction and delegate the common behaviors to the base abstraction. The following example implements a minimum-balance-checking-account, which has an additional restriction on the withdraw method in the form of a minimum balance check. It delegates all common behavior to the earlier abstraction make-account, while itself implements only the specialized functionality within the withdraw method.

(define make-min-balance-account
  (lambda (account-no account-name balance)
    (let ((account (make-account account-no account-name balance)))

      ;; implement only the specialized behavior
      ;; delegate others to the base abstraction
      (define (withdraw! amount)
        (let ((bal ((account 'balance))))
          (if (>= (- bal amount) 1000)
              (begin ((account 'withdraw!) amount)
                     ((account 'balance)))
              "Min balance check failed")))

      (define (self message)
        (case message
          ((withdraw!)    withdraw!)
          (else (account message))))
      self)))


But Scheme is a Functional Language

Programming without assignments is functional programming, where procedures can be viewed as computing mathematical functions, without any change in the local state. Scheme is a multi-paradigm language and the above implementation uses assignments to mutate the local states of the abstraction. The set! operation used in the above implementation helps us model local states of objects. However, it is absolutely possible to provide a completely functional-OO system implementing polymorphism using Scheme that does not have a single assignment or mutator operation. See here for a sample implementation.

Are Closures equivalent to Objects ?

This is a very interesting topic and has been extensively discussed in various forums in the theory of programming languages. While objects are often referred to as "poor man's closures", the converse has also been shown to be true. Instead of trying to mess around with this tension between opposites, let me point you to a fascinating note on this topic in one of the forums of discussion.

Do you comment your code ?

Paul Graham on comments in code ..

Incidentally, I am not a big fan of comments. I think they are often an artifact of using weak languages. I think that programming languages should be a good enough way to express programs that you don't have to scrawl additional clarifications on your source code. It would be a bad sign, don't you think, if a novelist had to print notes in the margins saying "she left without saying anything because she was angry about the trampled petunias?" It is the job of the novel to make that clear. I think this is what SICP means when they say "programs must be written for people to read, and only incidentally for machines to execute." I use comments mostly to apologize/warn about hacks, kludges, limitations, etc.

This is in the context of PG defending his claim Succinctness is Power for a programming language. Love him or hate him, you cannot ignore him. I think he is a true thoughtleader in the programming languages community ..

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.

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 ..

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 (H =:= 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 ?

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 ..

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 ..