Nov 10 2009

Don’t — in Scala

Category: Ideas, UncategorizedAleksander Kmetec @ 9:49 am

While browsing Reddit yesterday, I came across this thread on Perl’s Acme::Don't module. The Acme::Don't module is a joke module which adds support for “don't“, the opposite of the “do” command. The “don't” construct accepts a block of code and then DOESN’T execute it, no matter what. Now, lately I’ve been playing around with Scala and I know that thanks to its flexible syntax it’s possible to create functions which look and behave just like control structures. This got me thinking… could I implement a useful version of “don't“?

After a couple of minutes I came up with the following 2 use cases (in addition to the original standalone don’t block):


dont { ... }
dont { ... } unless (condition)
dont { ... } until (condition)

Implementing the dont { ... } part is easy. The only thing needed to make this work is a function which accepts a block of code and doesn’t do anything with it.

Adding support for the unles/until part is a bit trickier, but still easy. For this to work, the dont function must return an object which contains methods named unless and until. These methods then evaluate the condition passed to them and execute the original block of code if/when the condition is true.

It’s probably best if I just show you the code:


def dont(code: => Unit) = new DontCommand(code)

class DontCommand(code: => Unit) {
    def unless(condition: => Boolean) =
        if (condition) code

    def until(condition: => Boolean) = {
        while (!condition) {}
        code
    }
}

Now there’s nothing else left but to use it in an example:


/* This will never be executed */
dont {
    println("Hello? Can anyone hear me?");
}

/* This will only be executed if the condition is true */
dont {
    println("Yep, 2 really is greater than 1.")
} unless (2 > 1) 

/* Just a helper function */
var number = 0;
def nextNumber() = {
    number += 1
    println(number)
    number
}

/* This will not be printed until the condition is met. */
dont {
    println("Done counting to 5!")
} until (nextNumber() == 5) 

Runnig the above code should print:

Yep, 2 really is greater than 1.
1
2
3
4
5
Done counting to 5!

Tags: , , , ,


Nov 08 2009

Predictions on the future of NoSQL

Category: Ideas, UncategorizedAleksander Kmetec @ 12:02 pm

These days new NoSQL databases are springing up faster than URL shorteners. Even incomplete lists are likely to mention over 50 of them, most of them never heard of before. But even though they’re all being lumped together under the same name, they are so different from each other that there’s still a dilemma how to come up with a name which would describe them for what they are instead of describing them for what they’re not.

Nobody knows for sure what the future of NoSQL will be like, which way the development is most likely to head and who the winners will be, but we can still try and make some predictions. Here are mine:

Several subgroups will emerge
This is not as much a prediction as much as it is an observation of already visible patterns. At least two main groups will emerge from the NoSQL movement: networked data structure servers (key/value stores, queues, …) and databases for working with structured data.

The data structure branch will remain very diverse
Typical software in this category is rather minimalistic, both in terms of functionality and in terms of code size. Thanks to this the threshold for entry of new players is rather low; also low is the price paid by users for switching between competing implementations.
Various players will likely specialize in some technological niche and they will continue to be used mainly as means of speeding up applications and not as fundamental building blocks.

Relational databases will fight back
Some databases already have support for storing, manipulating and indexing structured data in the form of XML. I have a feeling that JSON support can’t be far away. For most users this will be enough to stay with the established players in the database field instead of choosing a strictly document oriented database.

Document oriented databases will morph into graph databases
Implementing cross document referencing will take them half way there. Pressure from the relational databases, as described above, will push them the rest of the way.

SPARQL will become the query language of choice
SPARQL is a query language for RDF1; in other words: a language for querying graphs. It supports querying multiple data sources at the same time (federated queries) and there are projects underway to make it work with Hadoop clusters.
I’m not saying that alternative methods of querying will disappear completely! I’m just trying to say that the key players most likely to be used by the average developer (the next generation graph database equivalents of MySQL and PostgreSQL and similar) will end up standardizing on SPARQL instead of inventing yet another language.

Software will gain weight
Reading about NoSQL databases gives me a feeling of deja-vu. Most of it reads almost exactly like articles about MySQL from the beginning of this decade: “We’re better than competition because we don’t have transactions/triggers/datatype checking/guaranteed consistency/fulltext search/…”. MySQL now has all of those features and NoSQL databases will follow in the same path. Most users will start hitting walls due to lack of features, not due to performance issues and when that happens having features will become more important than being lean.

The cycle will repeat itself
After a decade or so a new class of players claiming that their lack of features is their strength will emerge once again

  1. RDF is an extremely simple format wrapped in a metric buttload of mystery in misunderstanding. But more about that some other time.

Tags: , , , , ,