Comment by antirez | Hacker News Reader

Comment by antirez | Hacker News Reader

Btw, I would like to introduce this very related argument at this point.

At some point Redis will get scripting. It will take time, we are just entering 2.0 feature freeze, and later the priority will be redis-cluster, but we'll get scripting soon or later probably. Now I happen to be the original author of Jim, a small embeddable but fast enough (using an objects specialization technique) Tcl implementation. It's just a single .c file with 10k lines of C that is albe to run many Tcl programs unmodified if they don't tak with the "outside world" (that is no files, no sockets, no everything). It is really designed to be embedded, check it here:

http://repo.or.cz/w/jimtcl.git

Jim Tcl is actively developed, and used in OpenOCD (http://www.amontec.com/openocd/doc/About-JIM_002dTcl.html), in eCos environments and so forth.

But what I think is that users may get upset if I don't use a different language. The problem is, I don't know any single-c-file easy to embed, fast enough, interpreter for a language that will be more welcomed (I would like Javascript, for instance).

Also Tcl happens to be perfect to write Redis scripts, as they will look like commands issued with the redis-cli, like that:

    register-command GETDEL key {
        set result [GET $key]
        DEL $key
        bulk-reply $result
    }

I wonder what will happen, if I'll go ahead or if there will be an alternative. I can't see how Lua is more elegant or better than Tcl, and while not hard to embed definitely not as simple and self-contained as Jim Tcl is. Also Lua is far from being a well known language.

I really think that the right thing to do is to embed Jim Tcl, but there is a cultural barrier preventing me from doing this.

Btw, Lua is absolutely the best among all the JS / Ruby / Python / ... implementation I saw.

Without configure, and with a "Make ansi" target that is suitable to be used with the zero-configuration environment of Redis. So actually if it will not be Jim, it will probably be Lua.

Speaking of Lua - I wrote an alternative Redis library for Lua, Sidereal (http://github.com/silentbicycle/sidereal). I haven't posted it to the Redis list yet because it's still a bit young* , but the big feature is that it supports non-blocking operation via an arbitrary defer hook and async socket IO, for easy non-blocking / event-driven operation. (I have a project quite similar to node.js in the works, and Redis and non-blocking socket IO fit great with Lua's coroutines.)

* Most notably, the code to auto-reconnect while pipelining needs work, and I just finished moving, so it probably won't get touched for a week or two.

It has a translation of the entire official test suite into Lua (which was an ... interesting ... way to learn Tcl :) ), plus some other extensions for idiomatic handling of sets, lists, and zsets in Lua. (They're translated to tables with {key=true} for sets, {key=score} for zsets, and {key1, key2, key3, ...} for lists.) Also, the other Lua Redis library feels a bit more Ruby-ish to me.

I never got into Tcl, but that or Lua seem like the clear frontrunners as embedded config/scripting languages go. I'd prefer Lua, but it's your project, and I trust your taste.

First off let me say that I think this deserves a dedicated discussion on the mailing list or even on HN. I fear this thread will not be seen by most redis users, unless they also happen to be interested in TCL (selection bias).

However:

I really think that the right thing to do is to embed Jim Tcl, but there is a cultural barrier preventing me from doing this.

My datapoint as a happy redis user would be: Please don't. I have used TCL but don't like it. I also think there are rather few users who are versed in it and the obscure syntax would become a barrier to redis scripting gaining popularity.

My vote absolutely goes to Lua. That's still nowhere near as popular as javascript, python, ruby et al. But I think it's a much more accessible choice to people coming from the aforementioned languages (read: most people).

Well what I think is that Lua is not nice and clean either for most users.

It's silly that there isn't a clean compact implementation of a strictly algol like language. Imagine C at higher level, or the basic PHP constructs without the stupid parts. This one:

    function sum(a,b) {
       return a+b;
    }

No OOP, Data types: arrays, hashes, bool, integer, ... the obvious things, with operators to manipulate this stuff for the most boring tasks, and functions for all the rest.

The lingua franca for scripting, as all the other languages will be bised in a way or the other.

The problem is that clean, compact, strictly algol-like languages tend to snowball into hairy, ad-hoc languages.

Thing is, it wouldn't be that hard. How many compiler textbooks involve writing a minimal language like that? Tiger or Oberon, for instance. It's just that people don't stop at a tiny-but-sufficient, because they usually have a completely freestanding language in mind. Embedded languages need restraint to be useful. (Incidentally, I'm hoping to write a Prolog-ish language with embedding in mind this summer, but I already have a bunch of projects going.)

Lua is one of few cases where the authors have placed such a high priority on embedded use that the language has been kept small, even when it meant (gasp!) leaving things out of the standard library. It's more like a sane Javascript than an algol-like language, though. (I love it, but it's not everyone's style.)

That function is valid Lua.

No, the curly braces have a different meaning (lists and tables, what JavaScript calls "object literals"). In Lua, it'd be

    function sum(a,b)
       return a+b
    end

Close, though. (The semicolon is optional, and typically only used with multiple statements on one line.)

i am pretty sure the number of new uses of lua way exceeds the number of new uses of tcl, and i suspect the number of deployed lua instances exceeds tcl instances (there are a lot of games out there...).

i think you being author of jim is biasing you hugely in this. lua is the obvious solution here, not tcl.

yep this is a good point. But indeed I don't like Lua nor Tcl too much for this task. I would simply love to have an easy to embed Javascript implementation, but that does not exist.

If nothing will change under the sun I think I'll use Lua even if I don't like the language too much, but sounds like the sanest thing to do.

At a language design level, what in Javascript do you prefer to Lua? I know Javascript has more familiarity (no doubt due to this "web" thing I keep hearing so much about), but Lua seems to me like a far cleaner iteration of the same kind of language. Circumstance froze Javascript's design before it could have some major issues worked out, while Lua was able to develop more organically. They have a lot in common, though, particularly what Crockford calls JS's "good parts".

Everyone tells me that spidermonkey is actually an independent library. They could be wrong, though :P

What's wrong with Spidermonkey and V8?

On the other hand, Tcl is extremely easy to learn. Like Lisp, the language barely has syntax. You need to grok 11 rules and you're done. Here: http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm

That page describes the language in its entirety :)

Most people wouldn't consider it, but what about TinyScheme? It's small, around the 5000 line mark, a single C file, and an init.scm file, and hackable.

I would love adding something like Scheme.

The reality is that 95% of the programmers are not ready to such a choice :)

And this is sad. I realize that there's a reluctance of programmers to learn scheme, but someone needs to step forward and help people see the light!

What about defining a simple LL(1) grammar on top of tinyscheme and allowing both scheme and the Algol like language. Semantics would be scheme, syntax then is the choice of the programmer.

I tried learning Scheme, and it is like a foreign language. Everything is so different: the idiomatic style, constructs of choice, manner of solving problems. It's not just the parenthesis that throw me off. Plus, I don't like how the core language and library are organized at all. I think clojure got it much better in that regard. In the end, I don't feel it's necessarily worth it.

Scheme's primary advantages are that it has the most powerful compiler plugin framework which includes the most powerful macro system of any language, and it has the best language support for continuations. However, those two things alone have not been able to convince me to bite the bullet and force myself to code in Scheme for a year or more to really learn it, which is at least how long I think it would take to be comfortable in it.

I disagree, an I think the PLT scheme people who are teaching programming via scheme to high schoolers and college freshmen would disagree as well. Scheme is fundamentally simple. There is virtually no syntax. Scoping is lexical, and makes obvious sense, and there are really only a few "keywords". In no time a programmer should be able to pick it up and write simple programs with it. It does take a while to truly master however, but you can get away without continations and macros for quite some time.

One of my professors is one of the maintainers of Scheme and one of the authors of DrScheme, and he's made us aware of their education efforts. One of the interesting things about those education efforts is that they compare the results of teaching people Scheme to teaching them C++. I certainly would rather learn programming with Scheme than with C++ as well! C++ is a horrible language to teach beginning programming.

However, you can talk to me all you want about how easy Scheme is and may be for people new to programming, but that doesn't change the fact that I have a hard time learning it well enough to get things done as productively as I can with other languages and I've genuinely spent time trying. I've also learned plenty of other languages and learn them more thoroughly than most programmers I know, so I certainly am not incompetent. Therefore, I stand by my previous assertions.

I encourage you to take a step back then, and read The Little Schemer. It focuses not on the high level cool things in Scheme, but instead putting forms together to create things you find in every implementation out there.

Ah, that is why you really want Guile, which will allow your users to choose their extension language!

Heh, OK, Guile is not quite there yet. You can stop laughing now :)

What do the overlords say?

I learned Just Enough TCL for some Expect scripts, and anyone who is working on problems that need the features Redis has aren't going to sweat a little TCL, IMHO.

re: Jim or Lua - Another possible option would be Io (http://www.iolanguage.com/).

IO is awesome.

Antirez, it would be interesting to read the thought processes you run through as you come to a conslusion.

Reply on news.ycombinator.com