Live data from Hacker News

Tcl 9.0

tcl-lang.org

91–100 of 247 posts

Re: Tcl 9.0

#91
post #8

The only time I’ve dealt with Tcl in recent memory was for some MacPorts portfile stuff. Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either.

I often use the tool that is closest to another tool I am using. The closeness may be due to a common heritage, both technical and cultural. A common thread between the two is often high quality, maturity, cross-fertilization, long-term commitment, etc. Now when it comes to Tcl, I use it for the above reasons because it is so convenient for writing scripts to use SQLite. In other words, it is my go-to wrapper for man…

If there's any better relational database API, in any language, than SQLite's Tcl interface, I've not seen it yet. (And the reasons SQLite's Tcl interface is so good would either be hard to replicate without Tcl, hard to replicate without SQLite, or both.)

Re: Tcl 9.0

#92
post #88
post #41

Earlier quoted context omitted.

Indeed, SQLite started life as simply a Tcl extension[0] that “escaped into the wild”. Redis was initially prototyped in Tcl too, and ‘antirez has nice things[1] to say about Tcl. [0] https://sqlite.org/tclsqlite.html [1] http://antirez.com/articoli/tclmisunderstood.html

I'm curious about why they chose Tcl, particularly over languages like Python or Perl. Were there specific aspects of Tcl that made it appealing for SQLite and Redis, or was the choice more about familiarity with Tcl? Either way, I'd love to understand what they found interesting or advantageous about Tcl in these projects. BTW, I chose Tcl/Tk in the past because it was the easier way I found to quickly built an UI o…

The Redis protocol reads a lot like Tcl code.

Re: Tcl 9.0

#93

Really enjoy the language, even if I don't use it much these days. Does it still produce GUIs from 1995 on Linux? I'd still be using it today if it had halfway reasonable support for building GUIs on Linux, like they've had for ages on other platforms.

A theming engine went in something like 15 years ago now; the default theme looks rather dated, but there are plenty of others. See https://wiki.tcl-lang.org/page/List+of+ttk+Themes (though the screenshots of core themes are from 8.5/8.6 - default in particular has changed a bit in Tk 9).

The "catch" is that the theming engine has its own new widgets, and so to be themed an application has to use the new API. Code from 1995 (or 2005) still produces GUIs from 1995.

Re: Tcl 9.0

#94

I know of Tcl but I don’t know anything about its structure. The number one thing I ask of a language is consistency: the minimal amount of magic and most of the language implemented in itself. Ruby almost got there and then, for me, slipped up on class . How does Tcl fare under these criteria?

Tcl's magic is mainly from uplevel and upvar as they allow you to do crazy stuff with the callstack to enable all kinds of metaprogramming. It's not a lot of magic, but it's very powerful.

It's a lot of magic. New control structures mean dsls are as easy as thinking about them

Re: Tcl 9.0

#95
post #65

Earlier quoted context omitted.

One example from the document: > Consider the naive attempt to clean out the /tmp directory. > cd /tmp > foreach f [glob *] {file delete -force $f} > A file ~ or ~user maliciously placed in /tmp will have rather unfortunate consequences.

i once managed to create a directory named ~ using the mirror tool written in perl. then i naively tried to remove it using "rm -r ~" and started wondering why removing an empty directory would take so long, until it dawned on me... i learned a few new habits since then. i almost never use rm -r and i avoid "*" as a glob by itself. instead i always try to qualify "*" with a path, remove files first: "rm dir/*"; and t…

My main safety habit is to avoid slashless paths.

Bad:

    rm *
Okay:

    rm ./*
    rm /tmp/d/*
    rm */deadmeat
    rm d/*
Then again, I commonly use dangerous things like `mv somefile{,.away}` that are easy to get wrong, so maybe don't trust my advice too much.

Re: Tcl 9.0

#96
post #84

Earlier quoted context omitted.

> If you aren't designing computer chips, you have no reason to use it. It's a horrible language. What an unfair statement to make; by no means is it an horrible language. Just because it doesn't fit your tastes doesn't make it "horrible". That's like me saying having to start a line of Python with three spaces is annoying design which makes it an horrible language. Take your statement elsewhere.

30 years of TCL here. It really is the worst. I immediately moved my scripts to Python 1.0 when Python arrived on the scene because TCL (and PERL) were so horrible.

> 30 years of TCL here. It really is the worst.

If it's personal preference, than fine. But that doesn't make it a horrible language for all. I enjoy TCL and Perl and I'm 35.

I don't touch Python because I don't enjoy it. And I coded with it when it was in early 2.0x in 2003. I'd rather learn Java.

Re: Tcl 9.0

#97
post #8

The only time I’ve dealt with Tcl in recent memory was for some MacPorts portfile stuff. Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either.

Copy-pasting a "hype" checklist I made some eons ago: * Extremely consistent and elegant syntax - whole syntax/grammar is described in 12 rules in a single man page (Tcl(n)) of 150 lines and there's no reserved keyword. Nearer to CL than Python on that point. * Homoiconic through strings (like almost every language with eval) but most importantly, through "list-like" strings. * Official man pages! No web-only and spe…

Hey, you missed out coroutines :-)

Re: Tcl 9.0

#98
post #72

Earlier quoted context omitted.

I use it for "expect" because it just works.

Same. I learned Tcl recently for /usr/bin/expect. I wasn't happy to be forced into using yet another esoteric language, but Tcl itself is strangely fun: it's like a more expressive and functional Lua.

Ha, I was in the same position. It's fantastic at scripting serial consoles.

Oddly enough, Lua is also near and dear to my heart. It's a great language to embed to allow non C or C++ folks the ability to extend software or to do so dynamically.

Re: Tcl 9.0

#99

I'm going to give a shout out to NaviServer [0], prior called AOLServer [1]. This web server has been battle-tested and is bullet proof. When something has been used power AOL back in the day, what can you say. OpenACS [2] is the main project of, which has existed since 1997 and that alone is highly powerful in what it can do with. Especially when coupled with TCL. It's still maintained and now supports TCL9 too! Jav…

Brings back great memories and (more or less) where I learned both Tcl & SQL... Back in the mid-90's this is the stack and software I was playing with, though admittedly I was using the ArsDigita Community System proper rather than OpenACS (and back when ArsDigita was a thing).

Funny thing is I remember taking some free classes sponsored and taught by ArsDigita in an office they had in Pasadena, CA (or was it Glendale....???) they weren't too deep or long, but nice introductory stuff.

Re: Tcl 9.0

#100
post #95
post #65

Earlier quoted context omitted.

i once managed to create a directory named ~ using the mirror tool written in perl. then i naively tried to remove it using "rm -r ~" and started wondering why removing an empty directory would take so long, until it dawned on me... i learned a few new habits since then. i almost never use rm -r and i avoid "*" as a glob by itself. instead i always try to qualify "*" with a path, remove files first: "rm dir/*"; and t…

My main safety habit is to avoid slashless paths. Bad: rm * Okay: rm ./* rm /tmp/d/* rm */deadmeat rm d/* Then again, I commonly use dangerous things like `mv somefile{,.away}` that are easy to get wrong, so maybe don't trust my advice too much.

  rm -rf "$TSTDIR"/etc
is pretty dangerous when you forget to set the env var
Post reply on HN