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:
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.)
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".
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.
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.
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.
Was old and ugly. It's getting better, but that doesn't matter, because people are firmly convinced that it is old and ugly, no matter what the developers have been up to. This is precisely the sort of marketing problem I'm referring to: once you create an impression in people's minds, it takes a hell of a lot of work to correct it, even if the actual problem has largely gone away. The impression remains...
> > Lately, there has been a lot of work to update the Tk look and feel, and it has finally started to bear fruit. However, in terms of marketing, the damage has already been done: the image of "old, crufty Tk" has been firmly planted in countless developers' minds, and no amount of facts are going to displace it in the near future.
> Also, Python is the winner for me because it's syntax resembles C but is a lot easier to write.
Yes, I covered that aspect too:
> > The syntax, for your average programmer who doesn't want to go too far out of their comfort zone, is perhaps a little bit further afield from the C family of languages than they would prefer. Still though, a "human" problem, rather than a technical one. Perhaps, sadly, the message is that you'd better not "scare" people when introducing a new language, by showing people something that doesn't look at least a little bit familiar.
You are apparently one of the many who is a bit scared/confused/whatever by a seed that has fallen a bit farther from the C tree.
As far as the syntax, Tcl is quite elegant, in reality, once you take the time to understand it (which is not much time, as it's also very simple).
This is true. I was starting work on a cross platform project with a friend. The question of which GUI toolkit to use came up. He wanted to use QT, I wanted to use TK. I had to show him a recent TK project of mine before he would believe that TK wasn't ugly on X11.
If Tk doesn't look old and crufty anymore, you wouldn't know it from the official website: there are no screenshots to be found. I spent five minutes trying to see what a modern Tk GUI looks like then gave up.
Ah yes, this is another problem. I hope things are better now, but I was writing a UI a while back, and the TK documentation was like this: tcl.tk had a 1 line description of every command that's not really useful, and tkdocs.com was missing documentation for half the widgets!
Most of the actual material is Clif Flynt's though. It's not perfect, but at least it's a starting point that's widely visible to people getting going with the language.
And, of course, it's Tcl, whereas you're asking about Tk. Definitely something that would have been useful.
Actually if you look at the syntax from a mathematical point of view, Tcl synax is much simpler.
Also behind the clean Python look (that almost seems pseudo code in simple programs) the Python semantic is really complex compared to the one of Ruby for instance.
That doesn't refute the statement that the semantics behind the simple looks of python are complex. All that the simple grammar shows is that python looks simple. That was a given.
Claiming that python semantics were more complex than ruby semantics just makes no sense to me when the difference is even clearly stated in their respective design goals.
The point is that the diagrams you linked to don't tell you anything about the semantics. For example, according to the python diagram, there is absolutely no difference except for the parameter definition between what is allowed in a normal function definition and a lambda expression. The subtlety that a lambda can only be a single line is lurking in some surprising and dark corner of the language semantics. That is what makes a language difficult: arbitrary and subtle differences between things that should be the same.
Not that the three sligthly different types of callable objects/blocks/watchamaycallits in ruby are a shining example of elegant design. I don't know if ruby or python is simpler (I don't care, scala is even more baroque around the corners than both and I still prefer it), it is just that your syntax diagramms add nothing to a discussion about semantics.
"according to the python diagram, there is absolutely no difference except for the parameter definition between what is allowed in a normal function definition and a lambda expression"
They both point to the parameter definition, but lambda sits under "test" and refers back to "test" while the normal function definition sits under "compound_stmt" and also points to "suite."
Those are rather big differences, and reflect rather well that while perhaps semantically they are similar, syntactically speaking they are very different.
The point is that the diagrams you linked to don't tell you anything about the semantics
Well, I'd say they do provide a strong indication at least.
arbitrary and subtle differences between things that should be the same
It seems Python would need quite a truckload of such subtleties to make up for the complexity difference reflected in the graphs alone. And since one of its core design-goals is to avoid subtleties like that I think the graphs were a valid vehicle to illustrate my point.
Lambda is ofcourse a well-known wart in Python, but honestly, if we start wart-counting here then I think the comparison would end even worse for Ruby.
For the record: I'm obviously a python guy but have also used rails and sinatra before. I'm by no means a ruby-hater. It's just that I couldn't let the statement "Python more complex than ruby" pass without speaking up. Because, as I tried to illustrate, I can not imagine a metric by which that would be true.
Yep, the 12 rules and that's all there is to the language. Tcl is really well designed and elegant. It's almost a Lisp, but one that has the libraries and installed base that it can be used for production work.
e.g. it's easy to add your own control structures to the language
>It's almost a Lisp, but one that has the libraries and installed base that it can be used for production work.
>e.g. it's easy to add your own control structures to the language
Huh? You obviously don't know Lisp. Between PLT Scheme and Common Lisp you have several metric tons of libraries. And Common Lisp is certainly used for serious production work.
And finally, Lisp like freaking invented adding your own control structures to the language.
I've used more than few languages professionally or academically (C, C++, Objective-C, Java, JavaScript, Python, Scheme) and it still seems to me that most languages are still trying to catch up. This isn't to say I don't enjoy these languages.
But to say that things have moved past Lisp, that's laughable really. I mean, I don't even have garbage collection on my iPhone (and I really dig Objective-C).
One thing that Tcl, Perl, Python, Ruby, et al have going for them is that they are "promiscuous" in that they tend to play well with C, and other systems. Lisp and Smalltalk are capable of doing that, of course, but there seems to be much more of a culture of "turtles, all the way down", where that sort of happy-go-lucky interaction with the rest of the world is not always looked upon positively.
C and its "undefined behavior" are behind most of the litany of security disasters and unstable apps we have all endured. It can be expedient to reuse C code, but in the long run we're better off replacing it with something more reliable.
The uncomfortable trade-offs involved in working with what's available vs. replacing the whole stack with something done right are the heart of the "worse is better" paper.
For better or worse, if you want to replace C, you have to dig deep.
But if you look at it from the point of view of say, having to count from 1-10 the syntax is horrible.
The real killer for TCL initially was having to build extensions into the binary. If a lib needed BLT you had to rebuild TCL with BLT, then another library need a conflicting add-in you ended up with multiple TCL installs and a dll-hell of trying to get the right libs to play nicely. Don't know if thats fixed.
I remember thinking of learning Tcl for a project. I bought a book (this was practically pre-web) and very early on it said not to use arrays, as they were O(n) access time. So I gave up.
"arrays" are hash tables. You'd use the built in lists where you'd use an array in C. In 8.5, Tcl has "real", first class hash tables, "dicts", which, as I mention in the article, took too long to show up in the language.
I read the article more as "Things to consider if you don't want to run your really great technology into the ground". It shows how a community that has a great thing can sit on it's laurels and let the rest of the world pass them by.
It happened to Common Lisp. I personally think PLT Scheme rebooting itself as Racket is just the kind of break-with-the-past mentality more projects should embrace.
With respect to the language: having strings as the only data structure (everything is a string) and the developers stance on OOP (we don't need that) didn't help either and made way for python & ruby. With respect to the WWW, there was ACS/OpenACS, which even the author doesn't mention.
Tcl is one that I kind of want to learn but can't find any excuse for. I came to the party too late, I guess - Python does just as well for my scripting tasks, and "EIAS" scares me away from trying it for a substantial application.
The EIAS thing is not really that bad in practice, since you get lists and hashes and numbers, which can be used to build a whole lot of things. You also have namespaces to help organize code, and an OO system is on the way.
The things that come to mind where Tcl might be worth trying as opposed to Python are fairly niche:
* Tcl still handles threads a bit better than Python, IMO.
* "Starkits" are kind of cool if you want to distribute a single executable. Don't know what Python has in that department or how easy it is to use. http://wiki.tcl.tk/3661 . To tell the truth, though, "distributing" a web app is way easier than even starkits.
* Tcl, for some things, might still make a better "embedded" language because of its extensive C API.
That said though, Tcl isn't too different in its "ecological niche" from Python/Ruby/Perl, so I think if you know one of those, you'd probably be better off with something "further afield" like Erlang or Scala.
BTW, some shoots off the Tcl tree are worth looking at if you want to play around with a relatively smaller codebase: antirez' Jim Interpreter, at http://jim.berlios.de/ and my own Hecl, at http://www.hecl.org
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:
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.