Hello, I'm Nick Fitzgerald. This is my weblog. You can also check out my shared items from Reader, moments on Twitter, and code on GitHub. Feel free to contact me about whatever.
August 2nd, 2010
ParenScript is a small, Lispy language that compiles to JavaScript. So says the the project's page. But it is very small. So small, I don't consider it a language that compiles to JavaScript, but an alternate syntax for JavaScript.
With (((parentheses))). Just like other dialects of Lisp. If (((parentheses))) bother you, I posit that you don't "get" Lisp and, more importantly, Lisp's macros and metaprogramming facilities. But this is a non-issue, so I suggest you read the following and continue:
Vladimir Sedach, maintainer of ParenScript, comments on Hacker News:
[...]
The entire point of programming is automation. The question that immediately comes to mind after you learn this fact is - why not program a computer to program itself? Macros are a simple mechanism for generating code, in other words, automating programming. Unless your system includes a better mechanism for automating programming (so far, I have not seen any such mechanisms), not having macros means that you basically don't understand why you are writing code.
[...]
I love ParenScript. I truly feel that "ParenScript is an Acceptable Lisp".
ParenScript is practical. You can use it anywhere: server-side with
CommonJS, client-side with <script> tags, as a database query language with
CouchDB. And it's fast. Maybe not as fast as the code generated from the popular
Common Lisp compilers, but JavaScript's implementations are only getting
faster. Faster than Python's or Ruby's implementations. Deployment is like
JavaScript: very easy. Deploying Common Lisp? For the web, it is very hard. I
tried for a long time to use CL and Hunchentoot as the backend for
TryParenScript.com. Hell. I was up and running within minutes when I decided
to use ParenScript and NodeJS instead.
ParenScript is simple. It maps one-to-one with JavaScript. A single expression in ParenScript will create a single JavaScript expression. The generated code is easy to read; variable are names preserved; code is indented. Unlike Common Lisp, ParenScript isn't bloated: just stick to The Good Parts.
ParenScript is powerful. JavaScript is already dynamic and powerful: lexical closures, first class functions, lambdas, simple and flexible objects. All that's missing are metaprogramming and macros to extend the language and syntax. This is the single most important thing that ParenScript provides. It is worth it. I never realized how much I missed macros in everyday JavaScript code until they were available.
Module system missing from JS and everything is global? Write macros. Don't like
prototypes and want class-based OO? Write macros. Want Python's with statement
in client side code? Write macros. Browser inconsistencies cluttering your
logic? Write macros. Haskell/ML style pattern matching and destructuring? Write
macros. Asynchronous timeouts and callbacks becoming a mess of confusion? Don't
make me repeat myself.
People love to gripe about JavaScript. Every single gripe can be fixed with macros. Douglas Crockford said that JavaScript is Lisp in C's clothing and that statement is repeated so often it has lost all meaning. (Man|Woman) up and use JavaScript in Lisp's clothing.
In the foreseeable future, I will continue using JavaScript instead of ParenScript for the majority of my new and existing open source projects.
The sad fact is that I won't reap the benefits of open source using ParenScript. Contributors won't come; developers won't read my source. The ParenScript community is very friendly, but very small. I could rewrite wu.js to be more concise, straightforward, and maintainable with ParenScript, but if any other developer found a bug or wanted to add a new feature, they wouldn't want to learn ParenScript (and probably Lisp as well) just to contribute.
Opportunity cost is a bitch.
When I want to Lisp, ParenScript will be my go-to dialect. When I want to be social... well, ParenScript's day hasn't come.
Yet.
Source Map Specification Discussion Mailing List on February 28th, 2013
Regarding "Dynamic Source Maps" on January 22nd, 2013
Update on Firefox and Source Maps on July 30th, 2012
Source Code Cartography on December 23rd, 2011
Pycco Needs a Loving Home on August 17th, 2011
Operational Transformation Part 2: Operations on April 5th, 2011
Operational Transformation: An Introduction on March 26th, 2011
JavaScript Timer Congestion on March 8th, 2011
OOP The Good Parts: Message Passing, Duck Typing, Object Composition, and not Inheritance on December 31st, 2010
Pythonic JavaScript Methods on November 16th, 2010