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: , , , , ,


Jul 04 2009

Advertising overload

Category: UncategorizedAleksander Kmetec @ 11:27 pm

I followed a link to Forbes today and this is what I saw:

Advertising overload

There’s an article hidden somewhere in that screenshot. Can you find it?

Content is no longer king. It is now a third-rate citizen; a stinky bait used to lure in visitors; a parasite eating away at precious advertising space.

Tags: ,


May 16 2009

A proposal for symbiosis between Wolfram Alpha and Wikipedia

Category: Ideas, UncategorizedAleksander Kmetec @ 9:30 pm

Attention, please!

Wolfram Alpha is not a Google killer!
Wolfram Alpha is not a Wikipedia killer!
Wolfram Alpha does not want to dismember any company and bathe itself in its blood!

Please ignore unimaginative claims made by linkbait authors. Let’s forget the 1999’s prehistoric “me kill” mentality and focus instead on more peaceful opportunities. We now live in the age of mash-ups, so here’s my modest proposal for symbiosis between Wolfram Alpha and Wikipedia.

The opportunity for symbiosis comes from their different strengths. Wolfram Alpha’s FAQ section gives a very clear description of how it compares to Wikipedia:

Wikipedia gives you pages of narrative about topics. Wolfram|Alpha computes answers to specific questions you ask, just giving facts, not narrative. Wolfram|Alpha often includes sidebar links to Wikipedia.

Wikipedia describes a concept; Wolfram Alpha gives you the ability to try out that concept in practice.

And because everything needs a car analogy…
Wikipedia is like a car magazine and Wolfram Alpha is like a car simulator. You can open a magazine and read more about a car you just took for a virtual test drive, or start with the magazine and go for a ride in a car you just read about.

You can see in the above quote that one-way links from Wolfram Alpha to Wikipedia already exist. What’s still missing are connections from Wikipedia to Wolfram Alpha, which might one day look like this:

A hypothetical Wolfram Alpha / Wikipedia mash-up. Click for full size.

A hypothetical Wolfram Alpha / Wikipedia mash-up. Click for full size.

There you have it. Wolfram Alpha and Wikipedia can not olny coexist peacefully, they can help each other. No need to argue about who is going to kill who.

Tags: , , , ,


May 07 2009

The future is in the ability to ignore

Category: UncategorizedAleksander Kmetec @ 7:18 am

“It’s time to get completely off RSS and switch to Twitter. RSS just doesn’t cut it anymore.”, says Steve Gillmor in his Techcrunch post titled “Rest in Peace, RSS“.

While most commenters see his rant as a sign of the old man slowly losing his mind, it is also a sign of another thing: filter failure. Filter failure is what causes information overload and was also the topic of Clay Shirky’s Web 2.0 Expo keynote in NYC, which you can watch below:

So what’s happening here?

RSS readers are partially recreating the conditions which make reading email such a chore. They require you to check them every so often, read all the messages and make sure that the number of unread messages goes down to zero and stays there! But it never does. Every time you check your reader, there are new messages waiting and demanding your attention, even though they don’t really need it. Posts worth reading are lost among dozens which are not. After a while you start drowning in a flood of content you’re not interested in, you become overloaded and you don’t even bother unsubscribing from the feeds, you just stop checking your RSS reader altogether.

You switch over to twitter where all the links you see are already pre-filtered by other people. Think about it – in order for a link to end up in your Twitter stream, somebody must have already read the article and decided it was worth sharing. In addition to this, your previous experience tells you whose links are worth clicking and whose not. And yes, there is a new lump of messages waiting for you every time you log into Twitter and their number is very likely to be overwhelming, but Twitter has no “unread count” which would force you to check every single tweet and doesn’t have a “mark all as read” button which would make you feel like you were missing something every time you used it. It allows you to check as many messages as you want to and doesn’t demand anything from you.

Or as Stephen Baker puts it:

On Twitter, each of us can recommend a link. If you have 500 followers, maybe 50 of them see it. Maybe five of them take a look. Let’s say two appreciate it. The other three may be less likely to open your links in the future. Maybe one will “unfollow” you. But that’s ok. Each of us finds our own audience. But the key is that there’s little guilt or obligation associated with Twitter. It’s a managed pool of serendipity.

In some cases filters alone are no longer enough to avoid information overload. We also need a way of ignoring what can safely be ignored.

Tags: , , , , , ,


Apr 11 2009

Reinventing the wheel: the fluent interface design pattern

Category: UncategorizedAleksander Kmetec @ 4:56 pm

What’s the fluent interface design pattern? It’s a design pattern which became very visible in recent time, mainly due to jQuery, which was designed around it. In this pattern, class methods return the same object they were called on (they end with “return this;”), which makes it possible to chain them. It also makes it easily spottable in code, due to the distinctive outline created by chained methods.

Let’s have a quick look at what I’m talking about.

If Java Swing libraries supported this kind of coding, then the following block of java code, copied from a random blog post, could be rewritten from this repetitive sequence:


JFrame mainFrame = new JFrame("Hello World");
mainFrame.add(label, BorderLayout.CENTER);
mainFrame.addWindowListener(new MainFrameListener());
mainFrame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
mainFrame.pack();
mainFrame.setLocationRelativeTo(null);
mainFrame.setVisible(true);

…to this chain of methods:


new JFrame("Hello World")
    .add(label, BorderLayout.CENTER)
    .addWindowListener(new MainFrameListener())
    .setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE)
    .pack()
    .setLocationRelativeTo(null)
    .setVisible(true);

It’s amazing how much cleaner the code looks just by eliminating all those mainFrame references.

But wait… doesn’t this look familiar from somewhere? Doesn’t it remind you of a certain language feature you may have used years ago?

Yes, you’re right! It looks remarkably like the “with” control structure available in Delphi/Pascal and VisualBasic! If Java also supported it, the above example could be rewritten like this:


with (new JFrame("Hello World")) {
    add(label, BorderLayout.CENTER);
    addWindowListener(new MainFrameListener());
    setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
    pack();
    setLocationRelativeTo(null);
    setVisible(true);
}

It looks almost almost exactly the same as the one using the fluent interface, doesn’t it?

The main difference is that such a built-in construct works with any object you happen to throw at it, doesn’t require any additional effort from the library designer, and doesn’t require you to write repetitive code or wrapper classes if the library author failed to include the fluent interface pattern into the library in the first place. It also doesn’t interfere with the command-query separation principle and is perfectly compatible with step through debuggers.

But the fluent interface pattern does make it possible for us to have a special name for a simple concept, a Wikipedia entry for it, and dozens of blog posts about a solution to a problem that’s been solved, in a better way, decades ago.

Tags: , , ,


Next Page »