I have lately been searching for a better C-like scripting language, so I was quite excited to see Little. STATIC TYPING! WOO HOO!
Anyway, as I said, I’ve been scouting out C-like languages such as Ch, ICI, Pawn, Pike, and S-Lang in addition to the usual suspects. In comparison to just about everything else, I found Little to have remarkably few ugly spots. Little takes C and incorporates dynamism, regexes, and Tcl/Tk interoperability with remarkable elegance. As a C guy, I really like the syntax. The only thing that makes me queasy is pattern-function calling. It feels like something Larry Wall might have cooked up.
That said, trying out Little became a bit of a downer for me. I was expecting Little to be one of those languages that gets compiled down to some other language in such a way that you don’t need to know the target language. It isn’t. Little seems to have sufficient facilities for system admin scripting, but for more general programming you have reach down and pull up things from Tcl. The Tcl stuff may be a small part of your eventual code, but you have to know what all is there for when you need it. Getting into Little, I felt like I was doing double the work, having to familiarize myself with two languages in order to use one. It felt kind of weird, too, having to keep two very different languages in mind at the same time.
There is a big market for embedded scripting languages: Lua, Squirrel, AngelScript, GameMonkey, etc. Describing Little as a C-like scripting language with static typing would attract a lot of attention from people looking for an alternative to those. But I think most would be put off by the need to also handle Tcl in a fairly sophisticated way. Making that aspect of Little more prominent in the advertized features would, I think, help people more quickly assess whether Little is for them.
Yeah, you are right, it helps a lot if you can dig into tcl because there is a lot there. That’s a double edged sword, there is a lot of useful stuff but it is tcl and you have understand it, at some level, to use it. On the other hand it means that Little has a bunch of stuff available right out of the box.
What I’d hope is that as time goes on we, and you, and whoever, build more an more infrastructe in Little itself (or in the compiler if needed).
What would you want to see to make it more appealing?
There is so much functionality in the Tcl ecosystem, it would feel kind of silly to start duplicating it in Little. So I’m thinking that the only reasonable target audience is people who have a history with Tcl/Tk, but would prefer the syntax and structures Little provides. Something I’m sure they would appreciate would be libraries that unify/replace the more messy addons for Tcl, providing a cleaner interface.
I think one of the best uses for Little would be as an app scripting language. If I were considering it for a project, I’d appreciate a detailed writeup and sample code for embedding it in a program.
Something the Little distribution really needs as soon as you can is lots of sample code. I just recently spent time with the Pawn language, which offers an exceptional example of learning support for a languge: slick IDE, extensive docs, and a really well presented set of code samples.
Agreed on the code. I’m hacking on a tool process man pages that I can add to examples, but more is better.
Right now, Little is pretty decent as a perl4 / awk replacement, the bits are there for that and you don’t have to resort to tcl, at least I don’t.
I wouldn’t want to wrap/replace all of tcl but I’d like to find some sweet spot. Ideally, it becomes sort of the visual basic for everyone (not just windows). That’s gonna require some thinking and some work, ideas appreciated.
Here’s a little code example that I like. Note the hash of hashes that is words.
Stuff like this is super pleasant in this language.
/*
* Simple search DB generator.
*
* This looks through the files named on stdin and looks at each word,
* defined as \s+ stuff \s*
* and for each word remembers the list of files that had that word,
* and spits out a sorted on the word list of lines that look like
* word file file2 file3...
*
* Doing a binary search on the resulting file is easy.
*/
void
main(string av[])
{
FILE f;
string file, buf, v[];
int words{string}{string};
foreach (file in av) {
unless (f = fopen(file, "r")) continue;
while (buf = <f>) {
v = split(/\s+/, buf);
foreach (buf in v) {
words{buf}{file} = 1;
}
}
fclose(f);
}
foreach (buf in sort(keys(words))) {
printf("%s", buf);
foreach (file in sort(keys(words{buf}))) {
// these two lines a BK specific to shrink the DB
file =~ s/^bk-//;
file =~ s/-1.fmt$//;
printf(" %s", file);
}
printf("\n");
}
}
The other thought I have is that yeah, Tcl is off-putting to a lot of people, but it shouldn’t be. The Tcl syntax is a lose, in my opinion, but the tcl ecosystem is pretty awesome. Take a look at this:
and after you go “wow, fantastic” I’ll do some truth in advertising that not all of that stuff is ready for prime time but a lot of it is. A lot. Enough that it might be worth learning a little Tcl.
We just need to figure out the sweet spot, enough wrappers around the common stuff that you can do
what you want in Little and not think about it. I think for text processing we’re there. So what are the other common things that people want to do? Networking for sure, but what else?
I going to try to explain (in my broken English) as a former Tcl user what I think
this language needs for success outside the Tcl scene.
We need to make clear for what this language is useful.
For me it seems ideal as a readable shell scripting replacement and for adding
quick and dirty user interfaces to existing commad line programs. It’s a statically typed
scripting language with a known and clean syntax and the most important thing:
it’s a little language.
It reminds me the impression I had when I read the awk man page for the first
time: you can keep a complete programming language in your mind which is an
awesome feeling.
How are we going to collaborate as open source community?
First things first. We need to standardize the way we are going to write the
documentation for this language and some orientation about layout the
libraries are going to have on github repositories. Is the file little.html
generated by pod2html.l ?. I like how the Programmer’s Reference looks in the
website perhaps we can adopt this format.
How to make this language attractive to non Tcl users?
At least we are going to need to wrap the Tcl standard library which means
writing function prototypes to get the type checking and translating the
man pages to the L language. To make the language useful for non Tcl users this
is specially important for the I/O ( puts, scan, format, encoding, channelsand sockets) and how to process errors and exceptions ( try and catch ).
Meanwhile we should put links on the website to the Tcl command man pages and explain
how to translate the commands calls in to L function calls and how to map the
Tcl data structures in to L ones. The documentation already explain all of this
but probably is hard to understand if you do don’t have experience with Tcl.
The best way to learn a new language its reading and writing examples for
common tasks. The rosettacode website is perfect for
this kind of things. We should make and new entry for this language.
I used Tcl/Tk a bit around 2000 and have periodically re-considered it for projects, so I appreciate its strengths. You mentioned Little as sort of a Perl4 equivalent and have mostly been concerned with networking. I have been thinking of Little as a cross-platform glue+GUI option. The situation for pure C, cross-platform GUIs is pretty bad. My favorite has been IUP, but it doesn’t do OS X native and on X11 you have a choice of Motif or GTK+, both of which have their problems. So, the two use-cases I’d most like to see are embedding in a C program as a scripting language and making an interface for shared/static libraries.
I’ve been looking through the Tcl/Tk docs, thinking about how much Tcl you need to know in order to use Little. My suspicion is that if you made a list of all the core Tcl commands you have ever needed to call from Little, it would come in under 50 items, and even that much just because I’m considering the many math, string, http, and file functions.
How about making a list of “Probably all the Tcl procs you will ever need”, showing how to call them in Tcl and Little? Then people can see up front that it’s not a daunting requirement. Later on, as you get feedback from more users, whatever emerges as regularly useful might then be worth incorporating directly into Little. Not that I’m pushing for making Little larger. I really appreciate the elegance of Lua resulting from their focus on minimalism.
Tk is another matter. I think there should be a complete example app to use as a template, plus code clips illustrating each widget.
For me, really, I don’t feel the need to add much to Little. Just about all the functionality I’m interested in is there. I just don’t like the feeling that I need to keep looking over my shoulder at Tcl. I just need a fully operational Windows build and plenty of sample code. As for your points:
text: If something is done a lot, it’s nice to have named functions rather than regexes. I see a few nice procs in Tcl.
math: Not everything, but I might expect to use abs, ceil, floor, max, min, rand, rand arg, and maybe pow and sqrt.
web: Wow, a lot of work to build something competetive. Also, I don’t think the type of people who love Ruby would really be excited about Little. Not sure of the target market, here.
database: For web work, going to need at least SQLite.
gui: Not sure what you mean, since you already have Tk and that’s just about the most portable thing there is. I’m not crazy about the Tcl language, but manually coding layout in Tk is a breeze.
You mentioned Little as sort of a cross-platform Visual Basic. I was thinking better analogies and target market indicators might be Xojo and LiveCode.
I agree that L is fantastic for system scripting. Although I am a sysadmin, I have never liked programming in (ba|z|k)sh to the point I lately resorted to groovy for scripting. It was good but slow and bloated like hell and not too much integrated into the Unix pipeline.
I don’t know anything about Tcl and very little about perl but so far it has not been a problem for me. I use L for sysadmin scripting and as the system() and backsticks are powerful and well integrated, it is all I need.
To me, it looks like sh, but with curly braces, semi colons, typed variables, proper functions, hashes, structs, classes… And it is quick and really easy to learn. A real treat
I just hope that L will “stick” and become successful as I am starting to replace all my sh and groovy stuff with it.
I think it will stick. Our company has about 2-3 years of money in the bank, some of that will go to Little. There are a number of us that use it like you do and we want to keep using it. So if BitMover goes away I think there will still be me and Rob and Damon, maybe Oscar, tweaking it because we like it.
That said, we need to sort out the big problems with Little and address those. Getting sucked in to tweak this and tweak that draws us away from our day jobs, those jobs pull in money that can be spent on Little. So we need to sort things, figure out what we need to do, figure out where other people can help.
We thought of one other thing that would help C people coming to Little. Over on reddit someone asked for a macro package, like C’s #define some_func(a, b) some_other_func(b, a). Tcl already has something called an alias that would work nicely for that. Well, sort of nicely, it works if the passed args and the sent args are the same. So #alias foo(x, y) bar(x, y) works (and stack tracebacks will give you foo like you want) but #alias foo(a, b, c) bar(c, b, a) is not allowed. So we could have #define foo(a, b, c) bar(c, b, a) but then the stack traceback would be bar() like C.
Details aside, we could wack a bunch of these into libl so that strlen et al are present.
Be nice to know people’s list of stuff they don’t want to have to get from Tcl.
I really miss to be able to define symbolic constants like in C with #define or enum.
In scripting languages the way of doing this is with string literals but I hate them because they usually are documented in the man pages but not in the source code.
I think is easy to make a Tcl variable behave like a constant data type using the trace command. see http://wiki.tcl.tk/1734
Yeah, we’ve been having some internal discussions about that. We already have #include so adding #define seems reasonable. Your point about trace is neat, we could add a const using trace to prevent writes.
We’re also looking at #alias as a way to alias a C like strchr to String whatever.
