From the "L Programming Language" PDF:

    “It’s like perl without the nastiest bits.”

I think that really does capture the spirit of what this language looks like. I'm not sure it will reach any kind of general applicability, but it seems like a tasteful nod to the extensible nature of Tcl either way. Curious to see the inclusion of PCRE over Tcl's ARE which I thought was pretty routinely trotted out as a better performing, more limited, RE engine.

I really, really like that "Why?" explanation page; I feel like many projects could benefit from copying that idea.

Frequently, the first thought I have when I see projects is, "okay, neat, but why does this exist?", and the answer takes some digging. It's wonderful that in this example the answer is made so obvious.

Thanks. Given the state of the world we felt that not answering why would just get a pile of "Neat|WTF|Huh - why did you do this?"

I should have also said in the original comment that Little, beyond the website, looks genuinely neat and I'm looking forward to exploring it further.

I just finished skimming through the paper you have linked on the site and liked it quite a bit. It directly answered another question I had, which was what would it take to implement Lisp-style syntax in the same fashion as you did for C-style syntax? I'd normally talk myself out of ideas like that, but your paper is talking me into thinking about it more.

Thanks for sharing all of this!

I really, really like that "Why?" explanation page;

Me too. Especially the comparison of tcl to their language:

  set x [expr {[lindex $red $i] - [lindex $blue [lindex $green $i]]}]

  vs

  x = red[i] - blue[green[i]]

I had to work in Tcl early in my career...80 hours a week for a straight year, so I recognized that madness immediately.

Keep in mind that this example was (presumably intentionally) cherry-picked to show off the worst of Tcl's syntax. It's not really representative of how expressive the language can be in the right context, and it doesn't show the benefits that you can get from having a very simple, regularized syntax with little added sugar.

On the topic of expr, though, it can be avoided if desired in favor of Lisp-style prefix operators: http://www.tcl.tk/man/tcl8.5/TclCmd/mathop.htm

There are things to like about tcl, but lists aren't really one of them.

Not cherry picked, an "official" page describing lindex: http://wiki.tcl.tk/1481 Objectively compare that with most any other language's docs for lists/arrays/whatever. "Everything is a string" does have some downfalls.

That example was contrived but it wasn't designed to show off the worst of Tcl's syntax. There is worse out there.

Little wasn't a slam on Tcl, if you think that then you miss the point. Little is trying to bring people to Tcl. The Tcl ecosystem has a boatload of good stuff, people should check it out.

But many people are put off by Tcl's syntax, it's fine for glue, which is what Ousterhout intended, but it sucks for 300,000 lines of code. If you want to write big programs then perhaps some type checking could help you. And perhaps some familiar syntax might help. Little is for people that have to maintain a pile of code.

Tcl is fine for big projects. Use OO as does Tk. Use namespaces. And type checking isn't exactly difficult in the language. Some combo of catch {} and scan usually does it for me.

SQLiteStudio developer here. I think it's a project which could be considered big. Version 2.x.x was written entirely in Tcl and the main problem was memory sharing with threads. There's none. Threads can communicate only by messages. Worse than that - each thread has to load very same packages and same procedure definitions (into separate memory segment) for each thread that wants to use them. Threads in Tcl are like processes that can communicate through pipe. It's a major pitfall of this language in context of more complex projects. Besides that it is a very nice language to use and read. Gives quick results with little effort. I still use it almost every day, just not for complex projects.

I'm aware of tsv package (shared variable), but this is just sharing scalar variables or arrays. You cannot share objects, procedures, namespaces, resources, etc - and that is the major reason for sharing memory across threads.

Message passing without memory sharing. Isn't that what Erlang processes are? Is it because having to load the packages into the thread makes it too large? Just curious.

I'm not familiar with Erlang. Nevertheless there are two main issues with this threading model:

1) Application memory consumption grows more than it should, because same extensions have to be loaded several times in the same application, but in separate threads;

2) Resources such as images (or any other kinds), or OO objects, cannot be transferred between threads efficiently, the only way is to serialize them to scalar representation, which then can be passed through either tsv (mentioned above) variables, or through a message to another thread - then deserialize them there. Apart from precious time which it costs, you also make a full copy of resource/object, growing memory consumption even more.

Whats the best resource for Tcl ecosystem and getting its main benefits?

We (BitKeeper folks) did our GUI interfaces in Tcl/Tk years ago because it meant we could have one gui person and get the same gui tools on Windows, Mac, Unix, and Linux.

Ok, sounds reasonable. Except... now you have to hire another person to do language development/maintenance :)

Looks like a very interesting little language, I enjoyed working with TCL a fair bit due to things like wish being so interactive. It's also interesting that they added pointers to TCL, which solves my biggest gripe with TCL.

Tcl had them already, we're just using upvar under the covers. upvar uses the variable in the stack frame you specify. Which is clever and all but sort of a pain to use so we just did the &this_is_sort_of_a_pointer thing but it's a compiler managed upvar under the covers.

I haven't tried this yet, I've just looked at the examples in the docs. However, I think this could be pretty cool.

I think the combination of the Perl influences with the possibility (which I'm interested in, but haven't proven yet) of using this with Tclkit (a statically linked version of Tcl that can just be copied over for deployment) might make this a nice cross platform replacement for the kind of things I might otherwise want to do in Awk.

Tcl itself is also certainly a good cross platform Awk replacement, but heavy regex stuff seems like it might be a bit more concise with this syntax than in Tcl itself.

Always nice to see Tcl/Tk get attention, it's a language I've often found quite useful. Seems like I'd heard of "L" before in connection with Tcl/Tk, but not sure it was the same thing as Little.

Certainly seems it could be a good alternative, a quick look at the syntax makes me think of it like a kind of typed Javascript. The ability to tap into the underlying language, e.g., event loop, Tk UI, coroutines, should be an advantage.

There probably is a way to install Little when TclTk 8.6 (and extensions) are already installed (there's a warning about trashing the pre-installed binaries), and not have problems due to moving or replacing existing libraries that applications depend on finding in established locations.

Little is L, we used to call it L and got beat up because you can't google it. Supposedly googling little-lang is better.

If you build it with our makefile then it will live next to tcltk 8.6. If you don't then it will want to dynamically link in some libs and it will get the wrong ones and barf.

I remember being interested in L when I read about it a few years ago, so it's great that it's open-sourced now. Should be fun to try it out. I'll give the makefile a whirl.

As for the name, "L" would be hard to Google, though "C" and "Scheme" are too. While I guess "little" would be somewhat easier to search for than "L", it sure isn't as obvious as "Clojure" or "fortran". Outstanding names are hard to invent.

It's not very clear from the page -- does it work on Windows at all?

Banging out GUIs in Tk is a delight when contrasted with developing in whatever javascript framework is popular this hour. Tcl itself is pragmatic to an extreme; a great framework for both organizing large projects and heaping up fast primitives written in C.

Anyway, great job! I hope Little's syntactic sugar gets more people exploring Tcl/Tk. Can't wait to give it a whirl.

You hit the nail on the head. Tcl/Tk doesn't get enough love, it's a really useful system even after all these years, it's gotten much better in terms of looks and it was always great in terms of what it could do. All Little does is make it more approachable for the 9x% of the world that prefers C, types, etc.

When people say Tk looks bad point them here: http://www.little-lang.org/gui.html

Tk can look just fine.

Have you ever had to try converting a large pile of pre-existing Tcl/Tk code to L?

Wondering how much work that would be...

Firefox vs us on Linux

That's a bit of an unfair comparison. Gtk has lots of nice themes which AFAIK Tk can't use. That dialog doesn't exist on Firefox anymore, but this is what Thunderbird's preferences look like on my machine: https://my.mixtape.moe/fggaex.png

It's true, Tk can look okay on linux, but it will still be out of place when placed side by side with Gtk and Qt apps (Qt can use Gtk themes).

I...I...still feel like this is a joke, even after reading the "why" section.

Please don't snarkily dismiss other people's work on HN.

Thoughtful criticism is fine, but it should be grounded in respect.

The vibe I got from reading the "why" section was "yeah we had some fun making this, and yeah we think this syntax is a bit better, but isn't it ridiculous our boss thought this was a good idea!" Like a wink at anybody who think this isn't needed.

So to the extent I think its a joke, I think its intentionally a joke --- and whoever made it I respect their comedic talents.

I'm the boss and I wrote the why page, I was poking fun at myself. Perhaps my sense of humor needs an upgrade.

I didn't see a LICENSE file on github. What is this code licensed under?

Edit: Nevermind - it's in the README.

Trying to figure out where the code for Little lives - is it in a fork of the Tcl/Tk repo itself?