What's the draw, other than having some existing code written in the language? Gems like the `upvar` command? (http://wiki.tcl.tk/1508)
Is there something special about Tcl that makes it a joy to use?
- easy to write interactively because there's no fiddling with the parens, quoting, or commas you find in JS, Ruby, or Python
- uses [ and ] for subexpressions instead of ( and ), which makes typing easier
- "command" oriented, instead of "expression" oriented
- saner than shell while having many of the same advantages
I would like to point out that in several non-US keyboard layouts, [ and ] are harder to type, not easier. For instance, on German keyboards, they are mapped to Right-Alt (AltGr) + 8/9, which is quite annoying to type compared to normal parentheses (which are mapped to Shift+8/9, with Shift being better placed and available on both the left and right side of the keyboard).
AltGr + a -> ä
AltGr + o -> ö
AltGr + u -> ü
I'm Polish and I'm very glad that our most common layout is like that for ąćęłńóśźż (with AltGr + x for ź). Currently I'm in Germany and I wonder if there is similar layout for German umlauts.
I used to get laptops and keyboards with the US layout on them, but stopped since the resale value in Sweden drops sharply because of it. Thankfully, I've touch typed since forever so I rarely look at the keyboard anyway. (Unless, of course, I have to type with the Swedish layout.)
I miss some features of more modern languages though. TclOO (object-oriented extension) is minimally useful but lacks GC, so you have to keep track of all objects to manually destroy them when you are done. I miss easily passing around functions (procs), and saner local namespacing for functions (ie like in python). Exception handling is also a bit of a pain.
A lot of these things are addressed in Jim Tcl, but it hasn't seen much adoption.
Say you want to write an app to rename files in batch, or a wrapper for Ghostscript that automates certain tasks. With Tcl/Tk you can immediately run it on most Linux distros and with Freewrap you get a Windows executable that's a few MB+your source (it's a lot better than having your users install Java).
Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps.
With mxe+qmake it's one command to cross-compile from Linux to a Windows binary.
I like Lazarus a lot. I am not a fan of Pascal though, and Red is under 1 MB batteries included. I like how it seems a cross between Lisp, Forth and other languages.
Eventually that got fixed, but we were already busy with other languages.
It was also very easy to embed inside a C application for a user facing scripting capability.
That wasn't my experience. At least in tcl/tk 8.5 things like zooming in/out of a tk canvas or updating a progress bar were a real pain.
For example, tk canvas has this nice, seemingly simple subcommand called "scale" that looks like it does exactly what it's called with a tag and two double-precision floats. Apply it and all the relevant tk items are scaled accordingly. It even has a predefined tag called "all" that applies to all current tk canvas items. Trivial. Awesome.
Except text items don't get scaled. And font sizes are limited to integer pixel/point sizes. So zooming is actually non-trivial. Not awesome.
There are a sufficient number of such idiosyncracies that if you want to make a clear, usable interface you end up battling the toolkit.
Also, on the tcl language level I felt the "everything is a string" feature gets in the way. I'd much rather have implicit expressions and explicit string declarations.
For example: Qt was released around the same time. Do you know if the first version included QGraphicsView? Because it has features we still associate with a modern 2d graphics API-- affine transforms, opacity, grouping of primitives, arbitrarily complex paths, and decent performance even with event handlers and many items being animated on the canvas.
When GP says "one of the first scripting languages with a GUI toolkit", he is talking about the early 1990s. Before even python's first release. In fact, python ended up with Tk as it's stdlb GUI package because that was what was available.
Sure, Tk will never live up to Qt, but in 1991, I bet it was quite impressive to have a relatively simple yet expressive language like Tcl that shipped with a cross platform GUI toolkit, all under a very permissive license.
For most Tcl/Tk usage at the time the same, unchanged, no "ifdef"'s present Tcl/Tk script would run identically on the various environments that it supported.
* the everything is a string, mantra
* meta-programming possibilities
* tcl wiki ( http://wiki.tcl.tk/ )
I think if someone can rewrite tcl or a tcl like language, as the top level language, using a more modern low level language, like Rust or Go ... it will be a very nice combo, I think Tcl can serve as a really nice declarative language
If you look at Sqlite, it really is the perfect example of an offspring of the tcl community, a declarative solution for a complex problem , written in C ... a perfect tcl
I stopped following Tcl a long time ago, so I have no clue where it is at now ... but i hope it is still being used, for the super nice community .. it had/has
Why would someone rewrite Tcl in another language? That is just an immense amount of work and would (re)introduce bugs that have been found and fixed in Tcl over the last 3 decades.
Just the fact that Tcl is old doesn't mean that it is dead. It is actively developed and used, although mostly hidden (its not that kind of hype around as with Python or Ruby).
That Tcl is old does in fact imply that the code base is mature and reliable, its well documented and doesn't come with surprises. Which in turn means that your code is almost never broken with a new Tcl version. In fact, scripts and extensions written for 8.4, 15 yrs ago, are mostly still functional in 8.6 without modifications.
Yet Tcl does come with pleasant surprises that don't break old programs, as can be seen with the new features in 8.6 (TclOO, coroutines, tailcall, try/trap ...)
we program at two layers, high level, and low level
features needed or preferred in low level programming, may not be required in high level programming and vice versa
there are several ways to work like this, and many people do
for example, many developers use lua or python with c/c++
the effort needed to make the two language interact vary
another approach is to use one language with optional features, like optional typing or optional garbage collection, a language i believe is adopting this approach is red
have a programming framework, where two languages optimized for the two different layer use each others entities (names, objects, values, interfaces) seamlessly is in my opinion a super good approach for most programming
tcl + c .. are not exactly that and i believe a more modern combo will be better
I believe in this too. Not only two layers, if necessary there can be more.
For that to work, well designed interfaces are quite necessary.
"tcl + c .. are not exactly that and i believe a more modern combo will be better"
You don't necessarily need to reinvent Tcl in another "more modern" language to achieve that. You can compile Rust crates to dynamic libraries (.dll, .so) and use c types, or ffidl in Tcl (http://elf.org/ffidl/) to call the functions in your DLL-crates. Or write a small Tcl C extension to wrap function calls in the Rust code. That will do, without rewriting Tcl in Rust. For the other way around you can always call the Tcl library via its DLL interface in the same manner (which is the way to embed Tcl interpreters in other programs).
First you use it because it is simple to learn. Then you outgrow it and blame its weaknesses. Then you remember its strengths from a different perspective and pick it up again :)
So there isn't a direct path to WASM for many dynamically typed languages. Tcl can get by without all that because it's small enough to just port the whole C interpreter instead of trying to have tcl compile down to wasm. That would be very large, slow, and tricky for Perl, Python, etc.
It shouldn't, GC is a level above Wasm and would complicate languages that don't use it.
> or direct DOM integration
You mean like this: https://github.com/tcr/rust-webplatform ?
The problem with most dynamic langauges you listed is they do things that the web doesn't allow or do them in ways that aren't friendly to a browser.
Oh, and on direct DOM access. You presented a link to an implementation of indirect DOM access. They have an open issue you might find interesting: https://github.com/tcr/rust-webplatform/issues/20
I don't get this kind of complaint. It seems to completely miss the point that webassembly is a compile target, like arm or x86.
Without those things, languages like Perl or Python aren't practical, because you would have to download the whole interpeter runtime. That's not a complaint, it is an observation.
Those things are on the WASM roadmap. So this isn't just me going off on a tangent. https://github.com/WebAssembly/design/blob/master/GC.md
- translate MoarVM bytecode to WASM
- add WASM as a Rakudo target
- write yet another Perl6 compiler that targets the WASM just as niecza targets the CLR
You can do it man.
See this for more on that: http://www.perlmonks.org/?node_id=663393
Many (though not all) of these distributions contain XS, which is a type of glue between perl and C. Most of these XS distributions are there to link to some library -- Math::GMP, for example, lets perl code use the GNU gmp multi precision math library.
Without some way to make use of distributions with XS parts, then a perl to $other_language_here transpiler is not going to be very interesting.
It would be neat if there were credible alternatives to the DOM.
In the very early days of the web, I used to fantasize - naively - about the whole undignified html hodgepodge never having happened, and the entire web just running on served-up tcl/tk.
How is tDOM supposed to work if WebAssembly doesn't have access to the DOM?
- guy who used Tcl in like 1992 and helped write a 'compiler' for it, etc.