Hold the whole program in your head, and you can manipulate it at will

"Your code is your understanding of the problem you're exploring. So it's only when you have your code in your head that you really understand the problem."

"Distractions are bad for many types of work, but especially bad for programming, because programmers tend to operate at the limit of the detail they can handle. The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds."

"The more succinct the language, the shorter the program, and the easier it is to load and keep in your head. You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above."

While all Helma related patches that were pending at the time have been committed to Rhino 1.6R6 in June, there since has been
one more Helma related patch
that didn't make it into the Rhino 1.6R6 release version.

So, here's a version of the Rhino 1.6R6 containing that E4X fix and the pending Helma related patch:

With that patched version placed at ./lib/rhino.jar of your Helma installation, you can now enjoy E4X in your server-side Javascript and for example turn your skins into XML objects. With the code below, you could then access a skin "foo.skin" as XML object using this syntax: this.views.foo

Many web developers that have only worked with Javascript on the client-side seem to forget that the limitations they are used to inside the web browser and the DOM, do not apply when using Javascript on the server-side. For example, with Helma on the server-side, you can make use of any Java libraries. There is probably no language that has a wider range of available libraries. To instantiate an object from a Java class in Helma you could simply use something like:

On the server-side you are in control of the environment in which your application runs, which means you do not have the compatibility issues you are used to from the web browser. Also, you do not need to wait for new technology to be adapted by the user community. So, on the server-side you can always make use of the latest Javascript features. For example, you can use E4X because you would know that your server-side environment supports that.

Another example is being able to extend the Object and Array prototypes without worrying about breaking for/in loops, like is currently the case on the client-side. That ability alone allows you to bend Javascript in the directions of your preferred coding style and makes it incredibly flexible.

What you cant change, of course, is the curly braces syntax. But I think the fact that it shares that syntax with the two big languages C and Java is ultimately Javascripts big advantage that makes it a good companion in these environments.

In his
JavaScript as a Language
blog post, John Resig writes that Javascript is ready for its next phase, breaking out from its traditional habitat inside the web browser. In this regard, he thinks two projects have really stood out as having a lot of potential.
Rhino on Rails
and Helma.

John says about Helma: "This web application framework is a long standing stalwart of server-side development with JavaScript (again, using Rhino). Surprisingly, its managed to fall through the cracks with just about every JavaScript developer that I know. I recently noticed it, and after some startup friends of mine revealed that theyre developing an application based on it, I became convinced that well be hearing about this little framework in the upcoming months."

Of course, Javascript has been used on the server-side in many products ever since Netscape used it in its server-side offerings. What makes Helma special, is that it is for "Javascript as a Language" what Django is for Python and what Rails is for Ruby. In fact, Helma probably was the first Rails-ish web framework, offering an agil development approach and code-less mapping of objects to database tables, long before there even was such a thing as Rails.

Back then, I thought that Javascript was so much stuck in browser-centric preconceptions that we could never redefine what "Javascript" was perceived as and that we should switch to using the language's original project name "Mocha" when talking about it outside the web browser. Later, the Ajax hype came along and proved that it is possible to redefine the way the language is perceived. Generally, Javascript is still seen as a client-side language, but I think we know now that this can change quickly :-)

Your email address:
The "Decentralize" Newsletter
Exchanging ideas for building a
decentralized fabric of society.
Making true democracy work on a larger
scale while decentralizing "everything",
benefiting from local diversity and
global synergies at the same time.
http://tinyletter.com/zumbrunn