Modern JavaScript

Image via Wikipedia

These are exciting days for JavaScript, my note in Google Reader:

Crockford's _JavaScript: The Good Parts_ + jQuery + Google's Closure Library + Compiler = the best of modern Javascript

Very interesting article by Michael Bolin that shows what Google's Closure Library + Compiler bring to the table, and how you might change your clean JavaScript coding style:

Inheritance Patterns in JavaScript: "The Closure Library makes use of the pseudoclassical inheritance pattern,which is particularly compelling when used with the Closure Compiler.Those of you who have read JavaScript: The Good Parts by Douglas Crockford may use the functional pattern for inheritance that he espouses.

Cover of JavaScript: The Good Parts

Crockford appears to object to the pseudoclassical pattern because: 'There is no privacy; all properties are public. There is no access to super methods ... Even worse, there is a serious hazard with the use of constructor functions. If you forget to use the new prefix when calling a constructor function, then this will not be bound to a new object ... There is no compile warning, and there is no runtime warning.'

This article discusses the advantages of the pseudoclassical pattern over the functional pattern. I argue that the pattern used by the ClosureLibrary paired with the Closure Compiler removes existing hazards while I also examine the hazards introduced by the functional pattern (as defined in The Good Parts)."

Voidspace Techie Blog - storage.py

My comment on Fuzzyman's 'storage.py' module.

Image by lukedbaker via Flickr

Voidspace Techie Blog - Comments: "your 'storage.py', backed by a native file system for persistence, could solve a lot of problems with untrusted users supplying filepath input. Twisted's 'filepath' module tries to do this http://glyf.livejournal.com/75142.html on a limited basis, but your storage.py as a level of abstraction between the untrusted user filepath input and the actual native file system would do this more comprehensively. Also, persistence backed by Google BigTable, etc. Great work!"

Why Dynamic Languages? Why Strongly Typed Languages?

From Reddit commenter "munificent", the best analogy of why productive coders use Dynamic Programming Languages and Strongly Typed Programming Languages (best analogy I have ever seen...):

> > So, the problem is that software developers have poor foresight and a complete lack of self-awareness? No, the problem is that the success of most software projects can not be predicted.

Image via Wikipedia

When you go camping, you just pitch a tent. When you're moving, you build a house. With many software projects, it's impossible to tell beforehand if you're just going camping or will be taking permanent residence. It doesn't make sense to spend a month building a new house every time you go somewhere, if 90% of the time you end up leaving after a couple of days. What does make sense, and is becoming a common pattern is this: 1. Stake out a new territory and pitch a tent (v1 in a dynamic language) 2. If it turns out to be a hospitable place, start building a new house next door (migrate back-end services to more strongly-typed languages). 3. Once that's done, ditch the tent and move in (move the production system over to the new back-end). See: twitter (Ruby -> Scala), Facebook (PHP -> Erlang), etc.

Image by ThaRainbowRaider. via Flickr

Yes, a lot of academic computer science completely ignores the economic constraints of software engineering.

Python's user class implementation, and GIT

Image via Wikipedia

Comment to Guido's post "The History of Python: Adding Support for User-defined Classes"

I like dictionaries/namespaces better than objects. For me, your accomplishment with Python's implementation of user classes is on a par with Linus's insight to base a DVCS on a "mere" filesystem that only tracks content based on cryptographic hashes. A single idea, very simple but not _too_ simple, implies everything else, to great success.

Image by palewire via Flickr

Computer science is too important to leave in the hands of people who are not implementors.