Joose blog

If the the previous (practical) answer on the question “Why Joose?” doesn’t sounds convincing for you, here is the philosophical (aka meta-physical) variant. Yes, we like the “meta” word :)

Abstraction layers

Lets start with the following – why we all are programming anyway? Obviously to solve some real-world tasks. And we solve them, by translating the behavior of real-world systems into machine code. Such translation can’t be direct yet, as the computers are presently “dumb” and it has to be performed in the layered fashion.

That is, the first, outermost abstraction layer is the “user story”, written in the natural human language by the end-users.

The further level will probably be a technical specification, written by software analyst, or (in the agile methodology) a set of tests, representing the data-domain knowledge in the programmer’s head.

Yet another level will be the actual program, most probably written in some high-level language like JavaScript, Perl or Java (we treat everything except the assembler as high-level language here).

There will be also a byte-code layer, etc, the chain ends at the actual bits dancing on the silicon chips.

Complexity

Ok, now lets take a look from another (quite abstract) side. That real world task can be characterized by its “complexity”. This term is somewhat close to the “entropy”, may be its even a synonym.

We can say that each abstraction layer, we’ve used during translation, absorbs some part of that complexity. Like the sponge.

To solve the task, it’s whole complexity should be absorbed. You can’t leave some of it un-absorbed, as that will just means that some aspects of the system weren’t addressed.

So, the whole point is that, if you’ll be used “poorly absorbing” layers as tools, you’ll have to absorb the remaining complexity somewhere else, either in the code or in your head :)

Examples

Imagine you need to analyze some text file and extract repeating patterns from it, using C/C++ string manipulation capabilities. Compare with the same task for Perl/JavaScript style regular expressions.

Imagine you need to write the image recognition program in assembler.

Imagine you need to refactor the complex system and you don’t have the full and complete test suite (outer abstraction layer). Compare with the same task, when you have it. This is an example of poorly absorbed complexity.

Compare the implementations of quicksort algorithm in C and Haskell: http://haskell.org/haskellwiki/Introduction This is an example of layers with different absorbing capabilities.

Joose

So what’s special about the Joose and complexity? Its that Joose has meta-layer, which allows you to modify the behavior of your code (not the system being modeled).

And, modifying the behavior of the code, you can absorb any boilerplate you usually had to write. Moreover, you don’t just reduce the number of lines, you free your mind from that boilerplate. For example, consider this common pattern:

getSomething : function () {
    if (typeof this.something == 'undefined') {
        this.something == //something calculation
    }
    return this.something
}
How you’ll read this code? “If we have that `something` undefined,  then we calculate it, and store, we always return `something`” Lots of  words isn’t it? And the nature of `something` is still unclear..
In Joose land, you can just say that `something` is a lazy attribute:
has : {
    something : {
        is      : 'rw',
        lazy    : function () {
            return //something calculation
        }
    }
}
As you can see, the complexity of that pattern was absorbed by Joose and don’t pollute the code and programmer’s mind.
Conclusion
Enough of vacant advocacy. In the next post we’ll demonstrate, what  all these words means in practice, and how Joose makes your code simpler  and more robust.
Stay tuned!
P.S.
Oh, and we forgot to answer on one very important meta-physical question – “Does Joose works with NodeJS?” It does: http://samuraijack.github.com/Task-Joose-NodeJS/
:D