>xan 2014-10-12: It sure is named after Dancer! However, one of the big draws of tanzer is that it doesn't expect a request handler to read the entire request nor response in one single go, which should hopefully allow for much better performing web applications without standing in one's way much.
Forwarding for xan due to HN new account comment limits:
Yes indeedy! Although as my rather more florid verbiage points out, I do endeavor to make it as anti-framework as possible and more like a library. But then I suppose the only difference between a framework and library, one might posit, is often the presence of an event loop or some damned thing.
As part and parcel to a super ultra mega marketing blitz to remind people of the existence of Tcl and indicate to the world that it never really died, it is my solemnly sworn duty to help plant the seeds of a small ecosystem which unifies the divergent elements of the Tcl web framework ecosystem into one that rather more resembles Perl, in that there are so many wonderful middlewares to bridge gaps everywhere.
I developed tanzer to try to be the least common denominator of them all, and to somewhat offend (but in a polite way) Node.js' dominance by forcing the agenda of a language that already has a quite nice event loop and asynchronous I/O built in, thank you very much. :D
How prevalent is Tcl usage in the real world? You don't hear much about it, are there any new startups adopting it? Or is it only used in legacy projects at large companies?
It's definitely not the 'in' thing these days, but it's a very solid, robust bit of code that still makes for a nice language for creating certain kinds of systems.
I know a couple of startuppy companies that are still using it, but it certainly feels like a language in decline. There's a lot that's elegant about it, but the syntax is awkward in practice, and compared to e.g. Python there are fewer libraries available and no really compelling advantage, IMO.
It's a language that deserves better than it got - it should've become the standard for *nix config files (thanks RMS for the mess we have now). It should've been the language Sun pushed to run everywhere (it even supported java-style applets in web pages, without the slow vm startup). It should've filled the Lua niche (to a certain extent it did) as an embeddable scripting language. It should've filled the perl niche - it had good support for invoking external executables in a shell-scripting role, and could even be used as a login shell; it had good regex support, and was a first-class programming language that could be used for web backends. Heck, it even did reactive I/O in the very early days (IIRC there was a fantastic server product that was caught up in the demise of Netscape or AOL or some such) - it should've been Node too. But it always felt a bit unloved at Sun, especially post-Java (and to be fair, who can blame them when Java was that popular?), and it somehow never seemed to reach critical mass.
> IIRC there was a fantastic server product that was caught up in the demise of Netscape or AOL or some such
I believe you're referring to the ArsDigita Community System, which was written in Tcl, and which ran on top of AOLServer, a web server that supported Tcl as a scripting language.
(ArsDigita's rise and fall was a classic dotcom bubble story, complete with Aeron chairs, fancy cars, greedy VCs, founders with big egos, lawsuits, etc.)
ProjectOpen [1] could be an example. But from my experience it is basically a legacy project used in (large) companies, because it filled a gap 15 years ago when web based PM software was still rare.
The funny thing is, that the use of Tcl is explicitly advertised as security through obscurity:
"The combination of AOLserver and the TCL programming language is not commonly found in the Internet, so a potential hacker will need to expend a considerable amount of criminal energy in order to reverse-engineer the application stack." [2].
It's my first choice if I have to build a standalone app with GUI. With freewrap you can build an executable for Windows and the same source works for Linux.
I certainly don't think it's terribly common anymore, but there's still a bunch of stuff out there that uses it. I've seen it most often as a scripting extension to some larger software package (e.g. visual molecular dynamics: http://www.ks.uiuc.edu/Research/vmd/). OpenACS is also built on tcl/aolserver and was an early framework for building community web sites that's still around and still getting updates: http://openacs.org/ The "expect" program is a handy thing to have in your toolkit as an easy way to automate things and is implemented in tcl.
I use it in little ways, here and there. Its syntax inspires any tool-command syntax I write (see http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html). I have a few Tk scripts around to launch tasks (generate a new data repo, run various forms of regression tests, etc.); nothing beats Tcl+Tk for "build your own tool" GUIs. When experimenting with C code, it's useful to just embed a Tcl interpreter to run bits of it. Sure, I could use Lua, but Tcl's even easier.
None of those are legacy projects, but none of them are the primary focus of my work, either.
Tcl was at the core of StoryServer (aka Vignette, aka OpenText) - a Web Content Management System. Some large enterprises were (maybe still are) running their Web sites on StoryServer 4.2 (Tcl) until a few years ago. It was certainly quite popular in early 2000. Then StoryServer was renamed to Vignette, then they added ASP support, after that JSP, after that outsourced everything and that was the end of it. An elegant, small and fast engine turned into a mountain of jar files and APIs that take 200 man/hours to add 2+2.
Tcl is a beautiful language, very easy to learn and very powerful. I remember reading an article by the creator of Tcl where he was amazed that Tcl is used in very different way from what he envisioned. He meant to have Tcl as a glue, high level logic layer, while low level performance-critial stuff would be done in C. That is why Tcl (1) has great support for C and (2) has ugly way of doing arithmetic (e.g. [expr $x + 1]). Truth is that Tcl was never meant to add numbers. But instead people started writing all kinds of software in it, that went far beyond glue layer.
* Tcl has exceptional testing capabilites -- tcltest drives a lot of the tests for SQLite for example, and is the core of dejagnu, the test harness that drives gcc testing (probably among other things).
* Tcl is at the core of high-end Cisco products... and on and on and on...
I think this[0] really sums up "where is Tcl these days"... it reallyisoutthere, if that makes you feel better about using it. If that doesn't matter -- the sheer joy of a solid, battle-tested, fun-to-use language/framework might be enough to draw you in. Try it. You'll like it.
From what I've heard, most of those tools are not really the best of poster-boys for Tcl in that they're kind of old and crufty and probably not a lot of fun to work with.
Usually, the tools themselves aren't built in TCL (they're usually C/C++), but the interface is in TCL (and some other proprietary languages, depending on which tool you're using)...
And yes, unfortunately the tools end up being old and crufty, and that was my impression of TCL.
I did a bunch of TCL while working at one of the aforementioned companies, and I got to use it enough to see the lisp-y awesome parts (if you squint hard, [ ]s are just oddly shaped parenthesis), and the smalltalk-y stuff, but I still would have preferred using a different scripting language as my interface.
Try again! Given that this thing is very much a work-in-progress, and I certainly wasn't ready to submit to HN (don't look at me like that! It wasn't me), I suppose one can forgive a little web framework that could of this sort of thing.
I've got lighttpd in front of the site for now until I figure out what broke. :)
I was wondering why I woke up to a 500 Internal Server Error, and why I had ran out of fds. That explains it!
Having said that, I'm very keen these days on the idea of implementing usage of libevent into core Tcl 8.6, which would be a fact that tanzer itself would be entirely oblivious to.
I'll have you know tänzer is a lady! And a very improper one, at that.
In lieu of answering a more technical inquiry, I shall iterate my reasoning for being so persistent in cranking out this piece of software. Quite frankly, it's on account of me becoming quite ROYALLY PISSED with dealing with Impostor Syndrome all these years; it was such to a crippling degree that only today have I bothered even considering getting a Hacker News account. I felt I was a nobody, that I could NEVER possibly belong in the pantheon of bearded programming gods and shiny, happy goddesses, so I lurked.
Until this year, wherein I got a proper bonk on the head from a very lovely handful of people in the Perl community who encouraged me to make an ass of myself on stage with a talk on Filesys::POSIX (which I wrote). And I may have pooped out a blag post on Impostor Syndrome along the way, on http://xantronix.net/.
Anyway, pursuant to the idea of utterly crushing and subsequently extinguishing Impostor Syndrome inasmuch as I possibly can with my available wherewithal, I wrote tänzer as a labor of love to myself, and as a tribute to the concept of minimalistic antiframeworks (like antimatter, but antithetical to bulky frameworks instead). So far I think I've succeeded, given that I wasn't quite ready to blast this to the world yet (at least not without some really good profiling and a quite requisite, complete testsuite), people thought it good to release this to the hordes anyway.
Such is life. Consider writing software as a love letter to yourself occasionally. It's like taking a bath with candles and some real lovey-dovey music on in the background.
I have just took a quick glimpse and the source seems to be written very clearly. It is an excellent example of how coding in tcl looks like. Perhaps this could be used as an example when you are learning to program in tcl.
I don't use tcl neither I know what the actual state of available libraries the performance is, but tcl honors its fame as an easy to read language, this is not Perl.
One feature I like a lot is the ability to create secure interpreters that bypass military specifications.
Perhaps some benchmarks could give us an idea of what is the current state of affairs in the tcl world, but sometimes the bottle neck code just recurs to calling C libraries. I didn't see that ffi calling here.
One of the things that keeps my heart beating and my pulse flowing is knowing that one day, maybe ONE DAY Tcl can take the limelight again on the stage of web application development and maybe even curl up into a cozy little niche in the ever privacy-abrogating cabal of IoT stuff, too.
My choice of language for implementing tänzer is not just due to my love for Tcl's minimalist syntax, but also, as you intimate upon, Tcl's quite lovely FFI. I mean, that's what it was meant to do from the get-go, amirite??? Anyhow. I'd like to rewrite tänzer's guts in C, in a very mongrel2-like fashion, but perhaps less featureful but just as kind to binding by other language FFIs as itself.
"One of the thins that keeps my heart beating and my pulse flowing ...". If you code the way you write anyone could fall in love with your code. Readability and power, passion when coding, that's a very magical and powerful tool.
Well now I feel old. I remember writing a web app in Tcl way back in 2000 or so right after I graduated. From what I recall, AOLServer was not as fun to program as this appears to be.
It still is =) And I hope to spread that love as much as possible by carefully cultivating a tiny, cute little ecosystem of lovely tools on top of tänzer, and help foster the idea of making wonderful web framework middlewares for Tcl to make it a much easier proposition to proliferate our wares to the masses.
I joined a Portuguese startup in 1999 that had an in-house Apache module for TCL, an application server similar to AOLServer in design.
With an abstraction layer similar in capabilities to what people know Rails for. With lots of C plugins as well.
Being part of the core developers meant I was a regular reader on tcl/tk forums, eagerly looking for the upcoming TIPs, following ActiveState work in the community and so on.
It was also the last time in my career that I used C on the job, instead of my then favourite C++.
I learned lots of stuff while there, but two important things in terms of programming languages were:
1 - scripting languages are great for prototyping
2 - if you ever plan to scale, use a compiled language for the get go instead (JIT/AOT)
On our case, due to certain circumstances, we were part of the .NET alpha program and started moving part of architecture to C#/Managed C++.
> 2 - if you ever plan to scale, use a compiled language for the get go instead (JIT/AOT)
Like Facebook?
I don't think that's good advice, for several reasons:
* Everyone dreams about scaling. For most, it's just not a pertinent reality. It's easy to prematurely optimize.
* Scripting languages will let you iterate faster, and find some kind of product-market fit. Think about Twitter: I love Rails, but ... no, Rails is not a good fit for what Twitter is. And yet they managed to right the ship and move on to more appropriate systems. If you've got a viable business, you can find the money to improve.
Many of the improvements Facebook has brought into PHP eco-system is because the code base is so big, that it is worthwhile to invest so much money into research about PHP native code generation that re-write the whole stuff.
I get your point, but there are many languages that offer the rapid iteration of dynamic languages, while offering native code.
And monkey patching just doesn't scale across teams.
Don't feel old! Tcl is only two years younger than me and three years older than Python, and hardly anyone considers Python a relic. One day I shall adequately understand why it is that Tcl fell out of favor. The core language was never bad nor yucky, but things did improve quite a bit when Tcl 8.0 came along, with internal typed representations and whatnot. However, I finally decided this was the year I "put up or shut up" and prove to myself an interesting theorem that language adoption is mostly marketing. Here's to hoping the quirky little devil known as Tcl shall usher in a newfound hipster resurgence of joyful web software!
Part of my reason for being so hellbent upon proliferating tänzer is to improve the state of affairs for Tcl's perception by the wider community. It's a beautiful language, and a well-considered ecosystem. It never really ceased being that as it aged ever so gracefully, so I figure I shall become some larger-than-life PARTY HARD AND LISTEN TO BEAUTIFUL MUSIC! figurehead to spread some cheer and joy in the community and inspire some newfound personal pride in people's works.
It's astounding the crap [upvar] lets you get away with, ESPECIALLY making your own loop constructs. I'd be boned without it for doing request parsing without the ability to share a string buffer by name, for instance.
>Part of my reason for being so hellbent upon proliferating tänzer is to improve the state of affairs for Tcl's perception by the wider community. It's a beautiful language, and a well-considered ecosystem.
After being impressed by the "GopherJS" golang to js transpiler, I would love to see a corresponding Tcl/Tk to js transpiler, particularly one with Tk supported as transparently as possible in a browser canvas (or whatever). Greater than 90% of the GUI utilities I write can be handled using Tk's stock widgets. The ability quickly mash together a Tk interface in Tcl/Tk and compile it to js would be a productivity multiplier.
It's almost 2015 and front-ends are still a bear to write and maintain and keeping up with the js framework fads is exhausting. GUI development can and should be as easy as Tk made it ~20 years ago.
set HOME [pwd]
set DATABASE [lindex $argv 0]
set DIM 10000
proc CalcLine {line} {
set termData [lindex $line 1]
set termDataLength [llength $termData]
foreach {x y} $termData {
set score1 0
set score2 0
set score3 0
foreach sData [split $y {:}] {
set sd [split $sData {,}]
set score1 [expr {$score1+[lindex $sd 0]}]
set score2 [expr {$score2+[lindex $sd 1]}]
set score3 [expr {$score3+[lindex $sd 2]}]
}
lappend newLine "$x [format %.4f [expr {($score1+$score2)/$score3}]]"
}
set returnVal "[lindex $line 0] [list [string map {\{ "" \} ""} [lsort -real -index 1 -decreasing $newLine]]]"
}
proc Invoke {} {
global HOME
global DATABASE
set lCount 10
set wCount 0
set wData ""
set f1 [open $DATABASE "r"]
set f2 [open ${DATABASE}.j3 "TRUNC CREAT RDWR"]
while {[gets $f1 wordByte] >= 0} {
incr wCount
append wData [CalcLine $wordByte]\n
if {$wCount >= $lCount} {
puts -nonewline $f2 $wData
set lCount [expr {$lCount + 10}]
set wData ""
}
}
puts -nonewline $f2 $wData
close $f1
close $f2
AI preprocessing ai priori code. I found that Tcl is the best for this. It includes some efficient structures acute to Tcl. I use Tcl as a rapid application programming and proof of concept language. I find it to be the best at it. Used to use it for chip design too. After that at Berkeley Lab for knowledge discovery and gene discovery.
Tcl is pragmatic. I still use it for one-off projects with simple GUIs via Tk. I get grief from co-workers for the language, but my projects are typically done and correctly functioning in a fraction of the time it takes our Java and C# devs to even prototype a utility.
Below is a walkthrough of Tk which compares identical implementations of examples in Pearl, Ruby, Python, and Tcl. See if you can spot which of the scripting languages are more concise. Hell, I'd even call Tcl more readable in most of the cases:
The problem with humble and beautiful people and things is that, being of such a disposition, one is often not wont to market and self-promote, something I find to be quite endemic of the ever decreasing Tcl community. However, since I've decided to crush my Impostor Syndrome with a pointy heel, I've determined that there's no reason to be shy any longer.
Nothing good comes of faulty and detrimental meekness. Therefore I am creating this grandiose and megalomaniac caricature of myself and a web server framework to show the world that, just because a thing isn't well-marketed, that it doesn't deserve to exist, by, well, solving the bootstrapping problem of insufficient marketing. And maybe making some lovely software in the meantime.
I think I could go on and on for hours about the technical benefits of Tcl, and even make a non-ironic shit-eating grin through an explanation and ownership of some of its flaws (for instance, lack of garbage collection in TclOO), but I'd like to think this whole hootenanny makes a good object lesson in uniting people and spirits in joyous community and technical excellence.
TkDocs.com is a great resource, by the way, and is something I'm taking cues from for writing some more in-depth tutorials and "Getting Started" guides and cookbooks for tänzer. Speaking of which, if you or anyone else you know have any interest and time in helping me with my honey-do list (because "issue tracker" doesn't have that "je ne sais quois" I'm looking for here), that'd be absolutely bloody brilliant.
That's cheating a bit, since it's comparing the other three languages via their binding to Tk, and bindings always introduce impedance mismatch. Tk was built and designed to bind to Tcl.
For instance, in one example I happened to look at, the article discusses how to create a text widget that binds to a string. Since Python strings are immutable, in Python you have to create an extra StringVariable and pass that in, whereas in Tcl it's just a single line that binds a variable. But the fact that Python is a bit klunkier on this specific task hardly says anything about the relative strengths of either language in general.
tänzer also listens to loads more industrial music than Perl's Dancer, but will often be caught listening to Björk when she's hiding.
One thing I'm particularly keen on, with tänzer, is making it possible to easily swap in any ol' static file filtering mechanism by way of ::tanzer::file::handler callbacks. Without even necessarily having to write one's own request handler, one can simply filter the files before serving without any heavy lifting. A few examples would be transparent static asset minification, and template processing. Speaking of which, one of my next priorities is finishing up code and docs for teaspoon (whose file extension is .tsp; HA! HA!) so we can have a demonstrably straightforward set of swappable, pluggable web components in our little Tcl world.
Thanks! You are very sweet. I sincerely hope tänzer sets the right tone for not just the Tcl community, but also so many others that appear to be aging only on account of lacking an influx of new (young) developers. Writing quality code seems to be a pleasant side effect of that.
And now, to have a celebratory time over some beer and Dr Pepper and Cajun-flavored wings.
80 comments
[ 4.0 ms ] story [ 150 ms ] thread>xan 2014-10-12: It sure is named after Dancer! However, one of the big draws of tanzer is that it doesn't expect a request handler to read the entire request nor response in one single go, which should hopefully allow for much better performing web applications without standing in one's way much.
Yes indeedy! Although as my rather more florid verbiage points out, I do endeavor to make it as anti-framework as possible and more like a library. But then I suppose the only difference between a framework and library, one might posit, is often the presence of an event loop or some damned thing.
As part and parcel to a super ultra mega marketing blitz to remind people of the existence of Tcl and indicate to the world that it never really died, it is my solemnly sworn duty to help plant the seeds of a small ecosystem which unifies the divergent elements of the Tcl web framework ecosystem into one that rather more resembles Perl, in that there are so many wonderful middlewares to bridge gaps everywhere.
I developed tanzer to try to be the least common denominator of them all, and to somewhat offend (but in a polite way) Node.js' dominance by forcing the agenda of a language that already has a quite nice event loop and asynchronous I/O built in, thank you very much. :D
It's a language that deserves better than it got - it should've become the standard for *nix config files (thanks RMS for the mess we have now). It should've been the language Sun pushed to run everywhere (it even supported java-style applets in web pages, without the slow vm startup). It should've filled the Lua niche (to a certain extent it did) as an embeddable scripting language. It should've filled the perl niche - it had good support for invoking external executables in a shell-scripting role, and could even be used as a login shell; it had good regex support, and was a first-class programming language that could be used for web backends. Heck, it even did reactive I/O in the very early days (IIRC there was a fantastic server product that was caught up in the demise of Netscape or AOL or some such) - it should've been Node too. But it always felt a bit unloved at Sun, especially post-Java (and to be fair, who can blame them when Java was that popular?), and it somehow never seemed to reach critical mass.
Don't you like the language (TCL) or the way how GUIs are created? You can also code in C++/Tk for instance.
http://cpptk.sourceforge.net/
I'm unfamiliar with the history you're referencing. Was it being anti-executable configs?
http://www.vanderburg.org/OldPages/Tcl/war/0000.html
I believe you're referring to the ArsDigita Community System, which was written in Tcl, and which ran on top of AOLServer, a web server that supported Tcl as a scripting language.
(ArsDigita's rise and fall was a classic dotcom bubble story, complete with Aeron chairs, fancy cars, greedy VCs, founders with big egos, lawsuits, etc.)
[1] https://en.wikipedia.org/wiki/ArsDigita_Community_System
[2] https://en.wikipedia.org/wiki/AOLserver
The funny thing is, that the use of Tcl is explicitly advertised as security through obscurity:
"The combination of AOLserver and the TCL programming language is not commonly found in the Internet, so a potential hacker will need to expend a considerable amount of criminal energy in order to reverse-engineer the application stack." [2].
[1] http://www.project-open.com [2] http://www.project-open.org/en/project_open_architecture
Not sure if they're 'new' anymore but definitely 'startup'.
I wonder why it isn't more popular.
(I guess this has been at least somewhat remedied in later releases, but that doesn't necessarily have people taking a second look)
None of those are legacy projects, but none of them are the primary focus of my work, either.
Tcl is a beautiful language, very easy to learn and very powerful. I remember reading an article by the creator of Tcl where he was amazed that Tcl is used in very different way from what he envisioned. He meant to have Tcl as a glue, high level logic layer, while low level performance-critial stuff would be done in C. That is why Tcl (1) has great support for C and (2) has ugly way of doing arithmetic (e.g. [expr $x + 1]). Truth is that Tcl was never meant to add numbers. But instead people started writing all kinds of software in it, that went far beyond glue layer.
Anyways, yet another great forgotten language.
* F5 and A10 front-end traffic management use Tcl at their core -- here's an interesting article from F5 about re-visiting that design decision: https://devcentral.f5.com/articles/irules-concepts-tcl-the-h...
* Tealeaf (http://www-01.ibm.com/software/info/tealeaf/) uses Tcl at the core of its capture appliances.
* Tcl has exceptional testing capabilites -- tcltest drives a lot of the tests for SQLite for example, and is the core of dejagnu, the test harness that drives gcc testing (probably among other things).
* Attempts to replace Tcl at NBC (http://www.researchgate.net/publication/247290458_Prototypin...) have apparently gone on for years -- but nothing has managed to do it.
* Tcl was used in prototyping mars rover work (http://wiki.tcl.tk/13456)
* Tcl is used in chip design (http://wiki.tcl.tk/12897) and other CAD work
* Tcl is at the core of high-end Cisco products... and on and on and on...
I think this[0] really sums up "where is Tcl these days"... it really is out there, if that makes you feel better about using it. If that doesn't matter -- the sheer joy of a solid, battle-tested, fun-to-use language/framework might be enough to draw you in. Try it. You'll like it.
[0] http://www.reddit.com/r/programming/comments/1a1ynm/tcl_the_...
It was made to tie together IC tools after all (at Stanford, if I remember correctly).
And yes, unfortunately the tools end up being old and crufty, and that was my impression of TCL.
I did a bunch of TCL while working at one of the aforementioned companies, and I got to use it enough to see the lisp-y awesome parts (if you squint hard, [ ]s are just oddly shaped parenthesis), and the smalltalk-y stuff, but I still would have preferred using a different scripting language as my interface.
FlightAware.com: One of the busiest sites on the Web. Uses Apache/Rivet and a lot of Tcl-based utilities for backend information management.
500 Internal Server Error The server was unable to fulfill your request.
I've got lighttpd in front of the site for now until I figure out what broke. :)
Having said that, I'm very keen these days on the idea of implementing usage of libevent into core Tcl 8.6, which would be a fact that tanzer itself would be entirely oblivious to.
Site's back online with lighttpd for now.
And now it seems the world deems it necessary for me to have an HN account!
I'll be here all day, try the veal.
I'll have you know tänzer is a lady! And a very improper one, at that.
In lieu of answering a more technical inquiry, I shall iterate my reasoning for being so persistent in cranking out this piece of software. Quite frankly, it's on account of me becoming quite ROYALLY PISSED with dealing with Impostor Syndrome all these years; it was such to a crippling degree that only today have I bothered even considering getting a Hacker News account. I felt I was a nobody, that I could NEVER possibly belong in the pantheon of bearded programming gods and shiny, happy goddesses, so I lurked.
Until this year, wherein I got a proper bonk on the head from a very lovely handful of people in the Perl community who encouraged me to make an ass of myself on stage with a talk on Filesys::POSIX (which I wrote). And I may have pooped out a blag post on Impostor Syndrome along the way, on http://xantronix.net/.
Anyway, pursuant to the idea of utterly crushing and subsequently extinguishing Impostor Syndrome inasmuch as I possibly can with my available wherewithal, I wrote tänzer as a labor of love to myself, and as a tribute to the concept of minimalistic antiframeworks (like antimatter, but antithetical to bulky frameworks instead). So far I think I've succeeded, given that I wasn't quite ready to blast this to the world yet (at least not without some really good profiling and a quite requisite, complete testsuite), people thought it good to release this to the hordes anyway.
Such is life. Consider writing software as a love letter to yourself occasionally. It's like taking a bath with candles and some real lovey-dovey music on in the background.
I don't use tcl neither I know what the actual state of available libraries the performance is, but tcl honors its fame as an easy to read language, this is not Perl.
One feature I like a lot is the ability to create secure interpreters that bypass military specifications.
Perhaps some benchmarks could give us an idea of what is the current state of affairs in the tcl world, but sometimes the bottle neck code just recurs to calling C libraries. I didn't see that ffi calling here.
One of the things that keeps my heart beating and my pulse flowing is knowing that one day, maybe ONE DAY Tcl can take the limelight again on the stage of web application development and maybe even curl up into a cozy little niche in the ever privacy-abrogating cabal of IoT stuff, too.
My choice of language for implementing tänzer is not just due to my love for Tcl's minimalist syntax, but also, as you intimate upon, Tcl's quite lovely FFI. I mean, that's what it was meant to do from the get-go, amirite??? Anyhow. I'd like to rewrite tänzer's guts in C, in a very mongrel2-like fashion, but perhaps less featureful but just as kind to binding by other language FFIs as itself.
Edited: Grammar.
http://aolserver.github.io/
TCL was actually a pretty OK language. I do remember that aolserver was a major improvement over CGI scripts.
It still is =) And I hope to spread that love as much as possible by carefully cultivating a tiny, cute little ecosystem of lovely tools on top of tänzer, and help foster the idea of making wonderful web framework middlewares for Tcl to make it a much easier proposition to proliferate our wares to the masses.
With an abstraction layer similar in capabilities to what people know Rails for. With lots of C plugins as well.
Being part of the core developers meant I was a regular reader on tcl/tk forums, eagerly looking for the upcoming TIPs, following ActiveState work in the community and so on.
It was also the last time in my career that I used C on the job, instead of my then favourite C++.
I learned lots of stuff while there, but two important things in terms of programming languages were:
1 - scripting languages are great for prototyping
2 - if you ever plan to scale, use a compiled language for the get go instead (JIT/AOT)
On our case, due to certain circumstances, we were part of the .NET alpha program and started moving part of architecture to C#/Managed C++.
Like Facebook?
I don't think that's good advice, for several reasons:
* Everyone dreams about scaling. For most, it's just not a pertinent reality. It's easy to prematurely optimize.
* Scripting languages will let you iterate faster, and find some kind of product-market fit. Think about Twitter: I love Rails, but ... no, Rails is not a good fit for what Twitter is. And yet they managed to right the ship and move on to more appropriate systems. If you've got a viable business, you can find the money to improve.
I get your point, but there are many languages that offer the rapid iteration of dynamic languages, while offering native code.
And monkey patching just doesn't scale across teams.
Part of my reason for being so hellbent upon proliferating tänzer is to improve the state of affairs for Tcl's perception by the wider community. It's a beautiful language, and a well-considered ecosystem. It never really ceased being that as it aged ever so gracefully, so I figure I shall become some larger-than-life PARTY HARD AND LISTEN TO BEAUTIFUL MUSIC! figurehead to spread some cheer and joy in the community and inspire some newfound personal pride in people's works.
+ It combines macro ish text substitution with really, really, really good scoping and loop constructs.
+ A built in event handler is awesome.
+ Tk widgets look just fine for the one off GUI that routinizes a single repetitive task.
+ (Surprisingly) I almost never need float math in a script, one of the things it's not good at.
+ Tcl doesn't try to provide what should be done in C anyway (Python, Perl, Ruby I'm looking at you....)
Wait, you like the upvar stuff?
Also, i know of no other language with macro like substitution along with real local variables.
After being impressed by the "GopherJS" golang to js transpiler, I would love to see a corresponding Tcl/Tk to js transpiler, particularly one with Tk supported as transparently as possible in a browser canvas (or whatever). Greater than 90% of the GUI utilities I write can be handled using Tk's stock widgets. The ability quickly mash together a Tk interface in Tcl/Tk and compile it to js would be a productivity multiplier.
It's almost 2015 and front-ends are still a bear to write and maintain and keeping up with the js framework fads is exhausting. GUI development can and should be as easy as Tk made it ~20 years ago.
https://github.com/aidanhs/emtcl
Drop in on #Tcl on freenode and say hello!
set HOME [pwd] set DATABASE [lindex $argv 0] set DIM 10000
proc CalcLine {line} {
}proc Invoke {} { global HOME global DATABASE
}Invoke
Below is a walkthrough of Tk which compares identical implementations of examples in Pearl, Ruby, Python, and Tcl. See if you can spot which of the scripting languages are more concise. Hell, I'd even call Tcl more readable in most of the cases:
http://www.tkdocs.com/tutorial/
Kudos to the author of Tänzer for doing his part to keep the oft-overlooked Tcl alive.
The problem with humble and beautiful people and things is that, being of such a disposition, one is often not wont to market and self-promote, something I find to be quite endemic of the ever decreasing Tcl community. However, since I've decided to crush my Impostor Syndrome with a pointy heel, I've determined that there's no reason to be shy any longer.
Nothing good comes of faulty and detrimental meekness. Therefore I am creating this grandiose and megalomaniac caricature of myself and a web server framework to show the world that, just because a thing isn't well-marketed, that it doesn't deserve to exist, by, well, solving the bootstrapping problem of insufficient marketing. And maybe making some lovely software in the meantime.
I think I could go on and on for hours about the technical benefits of Tcl, and even make a non-ironic shit-eating grin through an explanation and ownership of some of its flaws (for instance, lack of garbage collection in TclOO), but I'd like to think this whole hootenanny makes a good object lesson in uniting people and spirits in joyous community and technical excellence.
TkDocs.com is a great resource, by the way, and is something I'm taking cues from for writing some more in-depth tutorials and "Getting Started" guides and cookbooks for tänzer. Speaking of which, if you or anyone else you know have any interest and time in helping me with my honey-do list (because "issue tracker" doesn't have that "je ne sais quois" I'm looking for here), that'd be absolutely bloody brilliant.
Thanks for your love!
For instance, in one example I happened to look at, the article discusses how to create a text widget that binds to a string. Since Python strings are immutable, in Python you have to create an extra StringVariable and pass that in, whereas in Tcl it's just a single line that binds a variable. But the fact that Python is a bit klunkier on this specific task hardly says anything about the relative strengths of either language in general.
Since we've gone off-topic I thought it might be good to post the same Rebol code from that old thread but updated to use the new R3-GUI dialect:
One thing I'm particularly keen on, with tänzer, is making it possible to easily swap in any ol' static file filtering mechanism by way of ::tanzer::file::handler callbacks. Without even necessarily having to write one's own request handler, one can simply filter the files before serving without any heavy lifting. A few examples would be transparent static asset minification, and template processing. Speaking of which, one of my next priorities is finishing up code and docs for teaspoon (whose file extension is .tsp; HA! HA!) so we can have a demonstrably straightforward set of swappable, pluggable web components in our little Tcl world.
http://tanzer.io/git/teaspoon.git
And now, to have a celebratory time over some beer and Dr Pepper and Cajun-flavored wings.