Tcl.js: robust, high-performance Tcl in JavaScript
github.com
github.com
An interesting discussion here: [2]
As a different take on the same problem, I compiled Tcl to JS with Emscripten - http://aidanhs.github.io/emtcl/. I also wrote a toy DOM library (https://github.com/aidanhs/emtcl/blob/master/opt/dom.c) which plugs into it which you can see demonstrated on the page.
One of the nice things about EmTcl is that you can include arbitrary C extensions by also compiling them with Emscripten, which is how the DOM library above works. As a more comprehensive demonstration, have a look at TclDis (http://aidanhs.github.io/tcldis/). That has Tcl, a Tcl C extension I wrote for Tcl <-> Python communication, a Python interpreter and the Python script I wrote for performing Tcl decompilation all in the same page! (it probably won't work well on a mobile browser)
Emscripten truly is incredible.
I mean, TCL with js-extensions could be a game-changer.
The language looks good on paper. It's also used widely enough to hold onto "legacy but useful" status for a long, long, long time (think cobol or fortran--there are still people writing new code in these languages, but only in very narrow niches, very little general-interest code).
There's a ton of weird gotchas, though, once you start writing in it that will drive you mad. Like the bracing rules that make sense until they don't, and then you have to make a really careful re-read of the so-simple 12 rules:
proc a {} {
puts "}"
}
The regexes are also weird. Not a week goes by I don't have to wrestle with one of my legacy tcl scripts (getting close to replacing them all, after enough of this weirdness).
And don't expect Tk apps to look good anywhere at this point.
BUT....you get used to that stuff eventually. The real problem, though, is that there's just no one left to actually address any of the problems in the language. The core team is there, but they're mostly just keeping things chugging along. Very little in the way of new ideas going around.
It has a very small and shrinking community, though, which leads to a vicious circle of, almost no one uses it for cool new things, almost no one blogs or writes about it in a promotional way, so there's almost no pull for new people to start writing in Tcl. There's no "killer app" and no one doing the leg work about it to introduce anyone new. The community keeps shrinking by attrition.
The online faces of Tcl, the main site and the wiki, have also suffered from probably the worst bikeshedding and, for lack of a better turn of phrase, old fogeyism I've ever seen in any kind of project. Landing on a wiki page and finding 15 year old discussions about long-gone aspects of the language, the place is like a ghost town. Also not going to bring in a lot of new people that way.
Aaaaand...why does any of this matter? Because the standard library is small and missing a lot of useful modern stuff for the generalist. It's often not well-documented, and you won't find any example code on a blog anywhere, so you're on your own. You're going to implement a lot of stuff that, if you'd started your project anywhere else, someone else has already done and posted to Github.
I think it's admirable how the handful of remaining core maintainers have brought the language kicking and screaming into the 2010s. They're squeezing a little more life out of the ecosystem and I commend them.
A JS version of Tk could be a game changer (using CSS).
HTML and CSS is already simple. QML is simple and beautiful. Tk-style layout design wouldn't bring anything to the table in 2016 that other people aren't already doing, and doing pretty well.
http://www.mcvoy.com/lm/bitmover/lm/gui-config/gui.html
I had to stare at that to be sure which was firefox and which was tk. I agree the defaults sort of suck but you can tweak them and make it look pretty decent.
The lack of documentation, opaqueness, and complexity, all that stuff adds so much challenge, just to get to "pretty decent".
There are better options in 2016, both from a visual perspective (looks good out of the box) and a programmer-tweakable perspective (can I make changes?).
I said this elsewhere, but Tk brought something to the table a long time ago, when GUI programming was complicated. GUI programming just isn't hard, the way it used to be.
Hey, if you're used to it, great, I certainly don't want to take the option away from anyone, but it's misleading to offer it as competitive in any way with the other contemporary toolkits.
I'm honestly pleasantly surprised you assumed I was in fact a multitudinous entity. In some aspects I am, but in actual practice I am but one corporeal form containing what I believe to be one brain. Having said that, I am picking up more active tänzer maintenance as I work on a different project of mine; eventually I will be porting tänzer to C, while maintaining a Tcl wrapper with the current interface, though I would avail tänzer to other languages.
I'm curious: Is there anything in particular you'd like to see happen with tänzer, or do you have any pain points need addressing? I'm monitoring my GitHub account more keenly these days; though I always consider http://tanzer.io/git/tanzer.git to be the authoritative repository, http://github.com/xantronix/tanzer is the best place to raise issues and offer changes.
Thanks for your interest!
EDIT: It is possible I have misinterpreted your statement somewhat, but the helpful meat of what I have to offer still remains. Ask away!
As to the rest, absolutum obsoletum - "that which works is already obsolete." I flat out don't see the bikeshedding; perhaps I'm just blind to it.
Tcl is also old enough to still have an active Usenet group.
No, you really don't.
" .. absolutum obsoletum .. "
If you're still writing code to solve the kinds of problems Tcl used to be good at solving, then yeah, sure, Tcl will never go out of style. For the rest of us, there are just better languages and ecosystems for almost any kind of problem (excepting the EDA world, etc., and as far as I can tell, those people aren't generally real fond of Tcl anyway).
"Tcl is also old enough to still have an active Usenet group."
This is actually a good way to look at Tcl. Want to see what computing was like 20 years ago? Well, here you go.
That's an odd thing to say ... I've seen Tcl written last century that runs unmodified on 8.6. Why are you wrestling with legacy scripts?
EDIT: I forgot about Jim Tcl and other lighter weight implementations. I need to try those.
"Embedded" may include something big enough to run , say, Lubuntu, and in those domains, it's very nice to have. Lua is more likely to fit on a PIC ( although really, for those, low latency means 'C', usually - but the task is usually small enough not to challenge the limits of using 'C' safely).
As to "larger audience", I think Tcl benefited greatly by not having one and having some seriously heavyweight greybeards steering it. $DEITY bless Perl, but it's not been treated well by its sheer popularity.
EDIT: removed digressive paragraphs.
http://www.erikkennedy.com/wizardpeopledearreaders.html
...And out popped a bloody good summary I couldn't have written better myself. I second blacksqr's sentiment and would love to see more of the guts of this dashing, dangerous beast of a thing you have unleashed upon this planet.
What does that mean? If it's possible to write x86 that runs linux in JavaScript, why is it not possible to write a parser?
set foo set
$foo bar baz
If we revamped the tk default look and coded directly in tcl/tk "apps" would more secure by default, less costly and doing the job a tad more correctly.
Instead of using UDP like stream over HTTP (webosckets) we could even use UDP or RTP or whatever native protocol that does the job. Even TCP. We could actually do the application without frameworks, without all these stacks, and with far less interoperability headaches (like testing for all browsers) and less vulnerabilities.
Not to say js is insane.
What is the competitive advantage for the web stack nowadays compared to tcl/tk after all?
Unlike TCL/TK, web stack already installed on 99% of computers, ready to use with no explicit installation steps other than loading a page.
That counts for a lot.
Go on. I am no lemming I will watch you with all the other unicorned lemmings experience the explosion of the IT bubble while I can still adapt with 20 yo technologies.
And most people install firefox/chrome on windows rather than use IE.
Installing Tk/Tcl is easier than installing firefox/IE/chrome. Tk/Tcl does not require a lib to handle inconsistencies between different browsers and different versions of the same browsers (ff).
Btw : Tcl/Tk = 29Mb Firefox = 40Mb Chrome = 52Mb
Memory footprint: Tcl/Tk is low usable in embedded system // most browsers have memory leaks.
Tcl/Tk // browsers:
- Positioning elements: Tk/Tcl 3 geometry managers (grid, packing...) while W3C CSS box model is an inconsitent mess
- Canvas: native // can or cannot be there (old versions) requires js
- Vectorial: Native // SVG
- Async : observers on variable (bind) & is aync by nature // callback in js - Numbers : string coercion is sane // String coercion is inconsistent float by default (crypto does not like float)
- Functional : who cares? btw lists are lists not object
- Scopes : sane vs insane
- Modularity : Supports C binding AND module // $.getScript(url, callback)
- IO: accessing local files is possible // is not
- Widgets: you can make your own & reuse them by design
Tcl/Tk is way easier to learn than angular.
Why angular pop suddenly? Because angular bloated code aims at doing what tcl Tk does natively: makes UI components communicate together... without burning both CPU & RAM
So ... given the level of wtf in web development, tcl/tk seems pretty a smart choice nowadays ... if you care more about coding functionalities that works in a small footprint with less bugs than eye candying.
Edit: Bonus my C+tcl/tk code from 1996 with nice graphs still compile and work in 2016 ... 20 years stability.
It is Chrome only as it relies on access to a local filesystem, and using Native Client plugins.
(Interpret as you will)
Extremely expressive, rivaling Smalltalk?
Small, understandable core with simple semantics?
Teachable to newbies in hours rather than weeks?
Yup, definitely deserves it. /s
When I first came across TCL after years of writing C++, I couldn't believe how much lighter the mental load was (I hadn't even noticed it until then).
Anyways, I was looking at Dart a while back, and sat down in my editor and started working and quickly realized that I hold the entire program in my head but had to keep checking a cheat sheet for syntax. There's definitely something to be said for languages or tools that can alleviate that blockage.
I guess it's the level of abstraction more than anything. TCL is really neat and being that the syntax IS the code, like Lisp, there's really no difference between how a solution works in your head and how it has to be written in the editor.
So yeah. TCL's pretty dope.
Tcl is great for simple scripting and automated testing. It's also great when you want to represent small bits of data as code. Perspecta Presents[1], one of Ousterhout's first commercial ventures, used Tcl scripts as the file format for its presentations[2].
But Tcl was never intended for large programs. Ousterhout expected large programs to be written in another language with compilers, linkers, linters and other tools. Once a Tcl program gets past a certain size it becomes effectively unmaintable. Tracking down a variable name typo bug in a 100,000 line Tcl program is a hell I refuse to visit again.
1- http://wiki.tcl.tk/4191 2- http://www.rpi.edu/dept/rcs/packages/ppres/1.10/common/sampl...
That Perspecta file is not pretty to look at.