Friday, December 11, 2009

Clojure is a multi-paradigm language. It is mix of imperative, functional and object-oriented programming. The parser, compiler/interpreter and runtime uses the Java Virtual Machine. Let me not get into any more details. The Clojure site is the best reference.

Functional programming finds its best implementation in the homoiconic language family. Clojure being a LISP (there is the LISP family and dialects like Scheme, Common Lisp, now Clojure) is homoiconic. The syntax in the LISP world is based on s-exprs; for the unitiated and haters it means the program looks like a big list of matching curly braces. Unlike Scheme, which strives towards minimalism, Clojure embraces expressionism. Traditional LISPs provide data structures as macros, functions or libraries. Clojure provides all this and in addition wraps them in syntactic sugar. I am biased towards Scheme's minimalism, but that is just me, and my fellow ivory tower academic hard-heads. This is not a shortcoming of Clojure. The goal of Clojure was to provide practical constructs for data structures and not just s-exprs.

There are however, a couple of idiosyncracies in Clojure which are distracting. Some of them create the feeling that "there is something wrong". Similar to Trinity fearing Neo's deja-vu on seeing the cat. I believe that these idiosyncracies need to be ironed out, maybe even eliminated. That will make the language mature. More important, it will make Clojure accepted outside of its niche community.

The attitude of the language and to a certain extent the language community is to be a better Java with functional forms. In this respect one will not appreciate Clojure for being a better LISP. Instead Clojure tries to be a better Java with LISP syntax. The documentation, the Clojure book (Programming Clojure) are never aimed towards a developer who wants to program. Instead it is addressed towards specifically Java developers, selling them the features of Clojure which is better when compared to Java (though the book says it can be used by experienced Python, Ruby, etc developers). Yes, this will help in attracting people who are Java cats who are searching for an ideal functional programming language. No, this will not make the language popular. If you look at Python or Ruby which also have Java based environments, the first class citizen is the language of Python or Ruby itself. Java is for performance and its large library. In Clojure it sometimes feels the other way around. Please note that I am not complaning about the language design here. I point at the attitude and the stance of the community.

Owing to the above attitude, many of the language constructs exist so that one can do what Java cannot do. The language introduces constructs because it cannot be achieved in the Java VM. For e.g. tail calls cannot be optimized in the Java, so we have recur and trampoline constructs. Obviously us Java developers will buy into it. But functional developers will never buy into that. Any programming language should have its own identity. In Clojure this identity is lost, because practical implementation difficulties are put ahead of clean design.

There is the PERL philosophy of "There are many ways to do it". And there is the Python philosophy of "There are many ways to do it, but there is one right idiom (pythonic)". Clojure is a mixed bag. There are many constructs - functions and macros - which achieve the same thing and you are encouraged to do; there you have the PERLish influence. However the functional programming principles of Clojure state that you should avoid direct recursion, or recur in place of sequence api; which is a pythonic attidute. Definitely the language community should have a stronger philosophy of their own.

I have read elsewhere Rich Hickey's comments on SICP. He says

And I don't think the core of Clojure is appreciably bigger than
Scheme's. What do Schemers think?

A lot of Schemers (including me) will have to spend a lot of time evaluating Clojure before we come to that conclusion. If the Clojure community can re-arrange their thoughts, as well as make those thoughts explicit, maybe then Clojure will be appreciated as being minimalist. Until then someone looking at the language will come away with the feeling that it has a very large core. That will definitely drive people away. (BTW Rich the only reason I was able to understand Clojure is because I know Scheme. I think others will agree.)

In summary if Clojure

• Tries to break away from being a better Java
• Establishes its own identity in the design of the language
• Improves its documentation, so that it can talk to everyone and not just seasoned Java developers
• Popularises the scaffold on which the language is designed - a small core, special forms, macros, the rich Clojure library, the Java interop and using Java libraries

it will definitely go mainstream. Not just Java developers looking for an alternate language, but Python/PERL/Ruby programmers, the newbies, and finally the enterprise developers/architects will give it a serious look, discover its merits and adopt it. I for one would surely be thrilled with this new LISP with the vast library of Java.

Disclaimer:
I am not a clojure developer. I am a programming language enthusiast and have learnt multiple languages with different programming paradigms; just for the fun of it. Programming languages which I know are Java, Python, Scheme, okie-dokie PERL, C# which for me is Java with a different library and idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely because it was in my syllabus, Javascript both in its prototype and functional forms. I have tried to be unbiased; if it exists it might be due to my stronger background in Java, Python, Scheme.

I have reserved my analysis to the language and the language "attitude". I might post more on the libraries, concurrency, macros etc once I trudge through them.

Friday, July 17, 2009

I am reading The language instinct from Steven Pinker. Some of the examples he has are very familiar to compiler construction.

Shift/Reduce conflictis a conflict in LALR grammars (most programming languages) where in the parser has to decide between shifting a new token for a rule or reducing the rule. Quoting Stephen C. Johnson from the YACC paper

As an example of the power of disambiguating rules, consider a fragment from a programming language involving an ``if-then-else'' construction:

stat  :  IF  '('  cond  ')'  stat
|  IF  '(' cond ')'  stat  ELSE  stat ;

These two rules form an ambiguous construction, since input of the form

IF  ( C1 )  IF  ( C2 )  S1 ELSE  S2

can be structured according to these rules in two ways:

IF  ( C1 )  {
IF  ( C2 )  S1
}
ELSE S2

or

IF  ( C1 )  {
IF  ( C2 )  S1
ELSE  S2
}

The second interpretation is the one given in most programming languages having this construct.

That is during a shift/reduce conflict, LALR parsers chose shift over reduce, implying that clauses are always associated with the innermost clause.

On the human side of the equation, Steven Pinker talks about Chomsky's classic illustration of turning a declarative sentence into a question

A unicorn is in the garden
-> Is a unicorn    in the garden?

This is done by taking the auxiliary "is" and moving it. However, this is not a simple move as illustrated in the below case

A unicorn that is eating a flower is in the garden
->    Is a unicorn that is eating a flower    in the garden?

Chomsky argues that our mental algorithm does not pick words by their linear positions, but does so by grouping it into phrases, implying that during a conflict the mind chooses entire units together.

Does this mean that the designers of LALR were goaded by their mintal algorithm to chose shift instead of reduce? Or does this mean that language is an algorithm (albeit more powerful than any parser) that is wired into our brain - and evolution chose shift over reduce because that is the easier one to implement?

Wednesday, May 27, 2009

These days I have been thinking of why there is no framework which helps me develop a web application in its “natural state of being”.

Let me explain the natural state of being for a web application. First the browser is no more just a html display engine. Instead the browser has emerged to include user interaction (read javascript) and html display engine. No more is it taboo to have javascript in web applications. In fact web applications say good bye to anyone who has not turned on javascript. Even the html display features have upped the ante. No more table wrangling and poor UI design. The DOM has matured and CSS can do wonders. Grid based CSS frameworks have put web design on par (at least notionally) with print based design.

What about web frameworks? Have they acknowledged the fact that html and javascript have matured. That, it is no more the forgotten child in the family of enterprise frameworks from Java and .NET or web oriented frameworks from LAMP, with P fulfilled by Python, PHP, Ruby! I would say yes and no. Yes, because many frameworks natively support and integrate with a javascript framework, or provide components based UI, etc. But mainly No, because all the action is in the rear (no pun intended). Html generation, UI interaction is all in the web application logic which is never executed by the browser but executed by the server. You might point out GWT and its ilk, but I have a mixed feeling about GWT. I like the concept and architecture of GWT. It is one of the rare breeds which acknowledge the power of the browser. However I don’t like the fact that everything is java.

So what do I want from a new age web app framework? Here is my wish list

1. Allow development of html in ahem html. Yes, no fancy wrappers frameworks. Plain html is good enough.
2. Allow layout definition, color and fonts in CSS. Web designers like CSS. There are javascript frameworks which do layout management, CSS, etc, but doing it is CSS's raison d’être , and does a good job.
3. Allow development of user interaction using javascript. User interaction includes visual interaction like drag-drop, open-close, etc. It should also include functional user interaction (which we come to next).
4. Allow integration of functional user interaction with the server using javascript. I don’t want a component tree to be manipulated on the server. The UI is on the browser, let the browser take care of handing UI.
5. Allow development of the html, css and js as we saw in 1,2,3 in an easy to understand manner. Maybe go back to VB, Swing or even Small talk. Designing a UI and interaction for the web should be no different from designing it for a desktop application. I shudder at the thought of developing a tree table control using only server logic.
6. Allow development of business logic on the server using insert java, python, ruby, etc. No brainer. Javascript from the browser requests something from the server, and the server dispatches it.
7. Have features which can glue the disconnected html, js, css and backend server. For e.g. login state management, history, etc.

One might think that my wish list is a manifestation of NIH or even Can your language/framework do this syndrome. It is not. A web application is created by several thinking hats. First is the graphic designer hat where you do not care about the interaction or functionality. Second is the user interaction designer hat where your intent is to do both visual interaction and functional interaction. Third is the business logic designer hat where your intent is to fulfill business requests in the form of an API. My wish list is to

• Let each hat use the language best suited for the purpose. Do not force a new language and framework unless it is a DSL.
• Let simple things be simple and complex things possible.
• A web applications’ UI is on the browser. So, let the VC (capital C) of MVC be on the browser and let Mc (a small C) be on the server.

Should we build a new framework or stack to support such kind of development? I don’t think so. There are tons of libraries. A nifty way to glue them is what we need. We need to do what Maven did to Ant build scripts (I know I will be flamed for that). Eliminate ctrl-c ctrl-v and introduce macro'ish way of doing things.

Html and CSS do not need anything new. CSS frameworks are the new kids on the block, but I don’t know much about graphic design to comment on them.

jQuery and other DOM manipulation libraries can provide the user interaction we want. Yes, DOM manipulation libraries have a lot more features; they can create the whole html, CSS etc. But like I said let html be done in html, CSS in CSS.

Functionally user interaction is fulfilled by Ajax modules in DOM manipulation libraries.I feel that Ajax API do not have good semantics. For e.g. in relational theory and SQL, a SELECT does projection, FROM does joins and WHERE does selection (sic!). Something akin to that is needed in Ajax APIs (I hope I explained what I mean). Also, I don’t think you need to hide the fact that the server is remote. EJB did that for many years and then introduced local and remote interfaces. Programming to an interface and not an implementation is always better.

Server frameworks are dime a dozen. A simple one which functions like an API sending only data in the form of json, xml, yaml, is more than sufficient. Almost all the frameworks qualify, but they need to be stripped of all the excess fat.

The biggest job is creating a neat pattern which can glue all these different components, provide necessary and sufficient (i.e. orthogonal) helpers, provide a good set of defaults and extension points. I consider documentation to be as important as the framework. Documentation should teach usage of the framework and provide details on the design of the framework.

I love programming. I hope that someone (or me) develops something which brings the same joy to web programming.