7 ms·
I can’t believe I’m praising Tcl
- lucian1900 14y agoTcl is an interesting beast indeed, since it takes its extreme love for strings so far, it's actually homoiconic.
- stcredzero 14y agoWhat would you get with the choices set as: - everything is a literal - everything is an expression Is there a Tcl variation that's a functional language?
- gchpaco 14y agoYou can do that in base Tcl; the libraries won't exactly help you and unless they've fixed the dynamic scoping problem it had a decade ago when I last looked at it closures would be obnoxious, but the language itself is really clean and simple, very nice. The implementation is horrible and the original designers didn't really understand what they had, which is why you have really weird libraries like Tk that don't compose especially well (briefly: in Tk essentially every GUI object has global scoping and are named; the naming reflects the scope. It's possible to write GUI libraries for it but it's not trivial).
- Avshalom 14y agoForth or Factor perhaps
- stcredzero 14y agoThat's way off base. Wrong language family.
- adestefan 14y agoTcl was lua before there was lua. It pops up under the cover as the scripting language of so many useful tools.
- mhd 14y agoWhat's often not as exposed is that Tcl was node.js before there was node.js (or, well, Twisted, POE etc.) . It has a pretty powerful event loop (moved out of Tk into the core language originall, if I remember correctly), and it's very easy to tie in scripts to add functionality. So it became quite popular for system that had to communicate with lots of different devices, gathered information from a lot of sources etc., centralized information processing hubs. Nevermind that it was very easy to add GUIs to monitor it or enter information. Back in the days, quite a few companies had pretty huge Tcl-based infrastructure, and despite the lack of support for "programming in the large", they were surprisingly easy to decipher and extend. I still don't know why Tcl had problems entering the WWW age. It started out pretty well, the aolserver was/is a pretty capable and performant system and they even had browser plugins (i.e. as a Java rival), but once the plethora of web services hit the landscape and we all went "Web 2.0", the lack of a proper CPAN equivalent and the slightly outdated Tk look caused some exodus to more hip scripting languages. The sad thing is that since quite a while Tcl overcame all those troubles (modules, packages, native look and feel), but probably a bit too late.
- blacksqr 14y agoI also wish I understood why Tcl was not more widely used in the early days of the Web. HTML is a string-based protocol, and Tcl is optimized for handling strings -- it's an absolutely natural fit. Bugzilla, for example, was originally written in Tcl; but for reasons I have never been able to discover, it was completely redone in Perl. Anybody here know why?
- mhd 14y agoWell, Tcl enjoyed a bad reputation for a while, mainly due to the "everything's a string" mantra leading some to believe it's not much use beyond that, RMS's flame war against it (which is why we're all using Guile now), and mostly the simple, but slightly odd syntax (expr, array and list functions). Then you've got to remember that for a while, Sun owned Tcl. Pretty much the same period when they were hyping Java… Also, the core Tcl distribution was still focused on scripting (embedded or not) and GUI programming with Tk. Modularity back in the days often involved separate interpreters with added featurs (TclX for example). Compare that to PHP: Basically the same situation regarding additional modules, but they had everything related to simple web development in one package - parsing requests, handling pictures… You could use PHP to do scripting and even GUIs, and you could use Tcl to do web development. But once you're written off as a niche language, it's hard to escape that trap. We've got a whole bunch of interpreted languages out there, but only a few of them are considered all-purpose languages. Ruby and Python mostly, even Perl has to fight a bit against the Unix scripting preconceptions. Tcl wouldn't be the first scripting language of that period "lost". Anyone remember Pike or Icon?
- febeling 14y agoI think it was antirez who said that Tcl had one of the best C codebases he had ever seen. Since then it's on my code reading list.
- rimantas 14y agoWould you mind to share the entire list?
- febeling 14y agoI don't have a proper list, it is more in the back of my head. I did read some of these each: * Erlang VM * sqlite * Linux kernel * Clojure functional data structures That list may look very pretentious, but I don't try to fully understand the packages. What interests me is (1) the style, and (2) the larger strokes. What kind of idioms are there, and how does it fit together. I think it is pretty hard to get the idea of a software package from reading the code. For that some higher level description or book makes more sense. Generally I think reading source code is very helpful in becoming a better programmer. I don't think the above list is anywhere near a general recommendation. I did rather pick a domain that was intimidating to me, and the reduce ignorance there.
- DavidChouinard 14y agoYes, it was antirez: https://twitter.com/antirez/status/210633349436407808 https://twitter.com/antirez/status/210633349436407808
- 14y ago
- cturner 14y agoYou can get lisp to interact more like a console language. Write a parser to accept python-ish whitespace syntax (whilst still allowing parens syntax), and transform that s-expressions so you can pass to the interpreter To imply: (define (fn a b) (list (car a) (car (car b)))) You could type: define: fn a b list: car a car (car b) As it's a console, in practice you'll mostly be typing commands like this: load x y z but you have good mechanisms for going deeper. And if you just want to write in s-expressions you still can.
- akkartik 14y agoI actually have a toy interpreter that does this: http://github.com/akkartik/wart#readme http://github.com/akkartik/wart#readme
- silentbicycle 14y agoThe aside in the linked article about avoiding shifting and parens just to type a simple command is even more true once a command spans multiple lines. Say what you will about syntactic attempts to remove the parens from Lisp, I think it's a secondary issue for a command language. There are some good observations about design pressures on command languages vs. programming languages in Olin Shivers's "A Scheme Shell", as well.
- gaius 14y agoTcl is a bloody good language+ but seems to have languished in obscurity. I can't count the number of times I've heard people in the Python and Ruby (and Lua and Processing, and node.js, for that matter) communities announce some wizzy new thing that Tcl had 5 or 10 years earlier. I've never understood why that is. The problem with the computing community in general is that it can't see over its own shoulder. Every few years, we reinvent the wheel. + By this I mean you can get a lot done, in not very much code, and maintain it afterwards, and read and modify other people's code easily.
- pacala 14y agoProductivity is highly valued. It's easier to be highly productive at reinventing wheels than it is to figure out which existing wheel fits a given problem.
- adestefan 14y agoIt seems to be trivial productivity. People like to say they've contributed and it's easier to port trivial libraries to new frameworks. I'm amazed everytime I see XYZ ported to framework de jour so celebrated.
- pacala 14y agoCopying is the foundational intelectual activity. Arguably copying enables natural language and culture. The world wide human network is engaged in a large scale genetic algorithm founded on copying. Porting successful features serves as an effective filter for bad ideas. Good ideas thrive and are copied everywhere, bad ideas get few copies and eventually die in obscurity.
- SkyMarshal 14y agoYou're preaching to the choir, comrade. My first professional manager back '99 taught me the same thing - programming is trendy, the same concepts keep showing up in new languages and packaging. Learn the concepts and you'll be set for as long as you stick with this career. Even Alan Kay has been complaining about it since 1997 [1]. Looks like even our complaints get recycled. 1. http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521
- mih 14y agoIf one looks at the EDA industry you will have to appreciate the breadth of applications Tcl is used in. Usually there is a Tcl interpreter with custom commands written in C for optimization. The ease with which one can quickly create interfaces between different tools I think is one of the contributing factors to its success. That and of course, the legacy codebase.
- forinti 14y agoIMHO, nothing beats Tcl/Tk when you need to write a small distributable application with a GUI. The last ones I wrote were for purging files acording their date and for compiling Forms/Reports. With freewrap I can build an executable with no effort at all.
- cafard 14y agoIsn't that what Ousterhout and his students designed Tcl for? I fooled around some with AOLServer years ago, and have used it with Oracle's "Intelligent Agent". But I didn't know how much I liked it until I Googled for "PHP upvar" and found a forum thread with bunch of people telling some guy that he was a language fascist for wanting such a thing.
- systems 14y agoI used to really like Tcl and it have one the nicest communities but I think it needs two things 1- a CPAN 2- Killer app (and no aolserver or openacs are not)
- yashchandra 14y agoI did my first professional programming in Tcl/Tk used by a trading system. It was awesome and even though most people have not heard of it when I talk to friends/clients, glad to see this post.
- chengiz 14y agoCirca 1999, I wrote a simple reminder script - which I still use - that brings a popup on the desktop, in like 3 lines of Tcl/Tk using the wish shell. I shed a tear at how easy it was compared to anything else at the time. I am not even sure if it's that easy with anything else today.
- antirez 14y agoAbout Tcl and the embedded world, a few years ago I wrote a single-file Tcl interpreter that is mostly compatible with current Tcl implementations (something is missing like namespaces, something was added like anonymous functions): http://jim.tcl.tk/index.html/doc/www/www/index.html http://jim.tcl.tk/index.html/doc/www/www/index.html (source code is here: https://github.com/msteveb/jimtcl https://github.com/msteveb/jimtcl) Now maintained by Steve Bennett, and actively used by some embedded folks.
- jostmey 14y agoI love the TCL foreach loops. TCL is the only language that lets you iterate through multiple data structures with the same loop. It is actually really useful. Just try this statement with any other language: foreach animal { "dog" "cat" "bird" } color { "brown" "black" "red" } { puts "See the $color $animal?" }
- eurleif 14y agofor animal, color in zip(['dog', 'cat', 'bird'], ['brown', 'black', 'red']): print 'See the %s %s?' % (color, animal)
- jostmey 14y agoI never knew about this zip command. I guess it brings the same utility offered by the TCL foreach loops to python. Still, I wish more languages directly imitated the TCL foreach loop. I've found that when I code, I wish I could just do some simple task 3-4 times. I am always tempted to create a little function, and to call that function repeatedly. But that seems like overkill. With TCL, I just write a simple loop statement instead of the function. I've found that my code is more compact, and the number of functions that I declare is reduced.
- thomc 14y agoRuby too: ['dog', 'cat', 'bird'].zip(['brown', 'black', 'red']).each {|animal, color| puts "See the #{color} #{animal}?"}
- thomc 14y agoI'm fairly certain you can do it in other languages, unless I didn't understand what you mean. In Python it would be something like: for animal, color in zip(['dog', 'cat', 'bird'], ['brown', 'black', 'red']): print 'See the %s %s?' % (color, animal) edit: eurleif beat me too it.
- silentbicycle 14y agoIn k (kona): a:`dog`cat`bird c:`brown`black`red {`0:,//("See the ";$x;" ";$y;"?\n")}'[c;a] The string formatting is a bit ugly because I'm not using a dedicated format function, but foreach with multiple data structures is just f'[list;of;arguments]. In other words, it's one character: ' ("each").
- js2 14y agoMy introduction to TCL was in the mid-90's via Expect: http://www.nist.gov/el/msid/expect.cfm http://www.nist.gov/el/msid/expect.cfm
- sliverstorm 14y agoI spend a lot of time using Tcl (I have to) and I spend almost as much time wishing I could be using Perl instead. This is partly because of weirdness, as described by the author of this article, and partly because I routinely run into things that seem to be far more difficult to do in Tcl, than they ever would be in Perl. Can I get one of the Tcl adherents in this thread to comment- have I got things completely wrong? Need I simply become better with Tcl? Or does it truly lack things like powerful string handling and hash tables?
- neild 14y agoTcl most certainly does have hash tables--Tcl arrays are implemented as hashes and can have arbitrary keys.
- pmarin 14y agoFor hash tables you have two options: the dictionary[1] or the Tcl array[2], which is more or less like an Awk array. Can you give me an example of powerful string handling? string[3] for the usual string manipulations. subst[4] when you want weird string substitutions (works like a template). regsub[5] and regexp[6] for regular expressions. [1] http://www.tcl.tk/man/tcl/TclCmd/dict.htm http://www.tcl.tk/man/tcl/TclCmd/dict.htm [2] http://www.tcl.tk/man/tcl/TclCmd/array.htm http://www.tcl.tk/man/tcl/TclCmd/array.htm [3] http://www.tcl.tk/man/tcl/TclCmd/string.htm http://www.tcl.tk/man/tcl/TclCmd/string.htm [4] http://www.tcl.tk/man/tcl/TclCmd/subst.htm http://www.tcl.tk/man/tcl/TclCmd/subst.htm [5] http://www.tcl.tk/man/tcl/TclCmd/regsub.htm http://www.tcl.tk/man/tcl/TclCmd/regsub.htm [6] http://www.tcl.tk/man/tcl/TclCmd/regexp.htm http://www.tcl.tk/man/tcl/TclCmd/regexp.htm
- wazoox 14y agoDepending upon what you do, you could be using Perl, with the help from the Tkx (for GUIs) or Tcl (for about everything else) CPAN modules and use TCL liberally from within Perl.
- lcargill99 14y agoTcl is one heck of a Swiss-army knife solution. The core team is of the first order. The best thing is that it's so easy to use pipes to integrate a 'C'/C++ console mode program and control it via stdin/stdout/sockets. That turns out to be a significant architectural plus - rather than using some MVC C++/Java type library, you get complete seperation of concern. You don't even have to integrate it tightly with 'C' code; just use stdin/stdout and wrap a Tcl package to build a pipe around it. Tcl might have been too easy. I also recall ESR dismissing it at one point in favor of Python.
- scrid 14y agoI work for a medium-large technology company supplying mission critical software (very large amounts of money are involved). We use Tcl for the vast majority of our software. We may head towards Java in the future, but not so much due to any failings of Tcl, more because it is easier to recruit Java programmers. I think the general consensus at our company is that Tcl was the right choice, although our programmers do occasionally gripe at some Tcl shortcomings.
- bch 14y ago@scrid -- curious to hear more.
- zem 14y agoa scheme repl could borrow a leaf from tcl's book by preprocessing everything you typed in to let you (a) omit the outermost parens and (b) mix () and [] freely. would be an interesting experiment to see if it had a better feel for this sort of interactive scripting
- makecheck 14y agoI'm not as fond of the language as some, primarily because it is unnecessarily hard to debug errors and unnecessarily hard to read code and data. For example the interpreter can basically say "there's a syntax error somewhere in this giant block of yours" and not have any idea where. A related issue is that a single delimiter (the brace) is bad for readability, even if it's easy to parse. Just try reading a gigantic dictionary; it isn't anywhere near as clear as Python/JSON-style can be (where there are obvious commas, colons, quoted strings and more to show you exactly what you're looking at). Another headache for debugging is that commands frequently accept the names of variables. In unfamiliar code you can't even answer simple questions like "where are all the places 'xyz' is used?" because a reference to 'xyz' could be hiding almost anywhere. You can change something and not fully understand the effects that your change could have. While I'm sure this allows for very clever code to be quickly written, it fails the more-important test of producing code that is easy to read. It is even possible for commands to silently accept mistakes and seem correct, with major consequences. Suppose "x" just happens to be a one-element list containing a number, '{0}'. With this input, "lindex 0 $x" is legal (even though "lindex $x 0" is the correct argument order). Worse, the wrong form returns something that seems reasonable without error. In this case what it actually does is grab the index that it found by magically looking inside the list ($x) and return one of the values from the implicit list containing "0" that was given on the command line; it returns a "0" but not the "0" that you'd think it does! While one can argue that each language has "best practices" and intended usage, the examples above are largely pulled directly from built-in commands and data types. These are things that people encounter all the time, they are not caused by any particular TCL programming practice.