[HN Gopher] Tcl 9.0
___________________________________________________________________
Tcl 9.0
Author : bch
Score : 214 points
Date : 2024-09-26 18:59 UTC (4 hours ago)
(HTM) web link (www.tcl-lang.org)
(TXT) w3m dump (www.tcl-lang.org)
| cmacleod4 wrote:
| The first major release in 27 years. 64-bit internal structures,
| so data can be huge. Full unicode with all the funky new emojis.
| Zip filesystems, etc., etc.
|
| There's lots of new stuff, and some old cruft has been dumped, so
| some programs may need a few updates, but there's still a high
| level of compatibility. The page above links to release notes
| with details of what's in and what's out.
| Zuider wrote:
| Why did they remove tilde '~' as a convenient shortcut for the
| Home directory?
| bch wrote:
| Tcl Improvement Proposal (TIP) 602[0].
|
| [0] https://core.tcl-lang.org/tips/doc/trunk/tip/602.md
| throw0101b wrote:
| 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._
| em-bee wrote:
| 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 then remove the empty directory.
| "rmdir dir/"
|
| if i do want to use rm -r, it is with a long path. eg in
| order remove stuff in the current directory i may
| distinctly add a path: rm -r ../currentdir/*" instead of
| "rm -r *"
|
| related, i also usually run "rm -i", but most
| importantly, i disable any alias that makes "rm -i" the
| default, because in order to override the -i you need to
| use -f, but "rm -i -f" i NOT the same thing as "rm". rm
| has three levels of safety: "rm -i; rm; rm -f". if "rm
| -i" is the default the "rm" level gets disabled, because
| "rm -i -f" is the same as "rm -f"
| kristopolous wrote:
| I've long fantasized about a tool I call "expect" that
| safeguards against crazy stuff like that.
|
| It has a syntax of your expectations, functionally
| existing as a set of boundaries, and you can hook it to
| always run as a wrapper for some set of commands. It
| essentially stages the wrapped command and if none of the
| boundaries are violated it goes through. Otherwise it
| yells at you and you need to manually override it.
|
| For instance, pretend I'm ok with mv being able to
| clobber except in some special directory, let's call it
| .bitcoin or whatever. (chattr can also solve this, it's
| just an example). The tool can be implemented relying on
| things like bpf or preload
|
| Originally I wanted it as a SQL directive ... a way to
| safeguard a query against doing like `update table set
| field=value expect rows=1` where you meant to put in the
| where clause but instead blew away an entire column. I
| think this would be especially useful surfacing it in
| frameworks and ORMs some of which make these accidents a
| bit too easy.
| danielheath wrote:
| For sql specifically, "limit 2" is my default way to
| write "expect 1"; if it affects two rows, I know that I
| have screwed up, whereas "limit 1" can be wrong without
| my noticing.
| kristopolous wrote:
| That's not a terrible solution although expect sounds
| like a simple safety mechanism for feeble-minded people
| like me who do simple queries.
|
| I actually know postgres people. I should probably ask
| them
| kragen wrote:
| just to clarify, this has nothing to do with the "expect"
| that is the other major application of tcl other than tk?
| kristopolous wrote:
| None.
|
| I was just reminded of a good idea I never implemented
| sweeter wrote:
| I love zsh auto completion for this stuff. It
| automatically escapes really messed up paths like paths
| with new lines or emojis and crazy characters like that.
| Its really rare but I still intentionally practiced
| removing these things just so I can do it safely if it
| ever happens.
| sfink wrote:
| 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.
| mzs wrote:
| rm -rf "$TSTDIR"/etc
|
| is pretty dangerous when you forget to set the env var
| progmetaldev wrote:
| Very cool of you to post this. Too many people won't post
| stories like this, but I've done very similar multiple
| times. I think it definitely helps reinforce proper
| habits, and is the best way to cut your teeth on
| technology. It's also great for anyone new to read
| something like this, and be able to avoid something so
| devastating, and maybe make lesser mistakes, but still
| learn from both!
| cmacleod4 wrote:
| In the long run, special cases like that often turn out to be
| more trouble than they are worth. If an ordinary file
| happened to start with '~' it would not be handled correctly.
| So you either accept or ignore that potential problem, or you
| have to write extra code to work around it. It's safer to not
| have such special cases at all.
| mirekrusin wrote:
| Should be starts with ~/
| cmacleod4 wrote:
| No, ~abc will be interpreted as the home directory of
| user abc in Tcl 8.*
| Koshkin wrote:
| Just recently I used '~' in the remote target path in the scp
| command, and, somewhat unexpectedly, it created the directory
| with that name and put the files there.
| wduquette wrote:
| The Zip filesystem stuff is wonderful change to see: it takes a
| number of techniques that were common in the community (if you
| had the right tools and knew how to use them) for building
| standalone applications, and makes them part of the basic
| toolkit in a standard way. It's a truly excellent change, and
| I'm glad to see it.
| Klonoar wrote:
| 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.
| metadat wrote:
| Eggdrop IRC bots. Even 25 years since I first created one,
| Eggdrop is still the best and most reliable + flexible IRC bot
| platform, and comes with native support for Tcl.
| jiripospisil wrote:
| Curious as well. The only time I've seen it used in the wild is
| Redis' test suite.
| https://github.com/redis/redis/tree/unstable/tests/integrati...
| aidenn0 wrote:
| Tk based GUIs work across pretty much all desktop platforms and
| are much less resource intensive than electron and friends.
| criddell wrote:
| Is Electron really considered a competitor to Tk based GUIs?
|
| In my (limited) experience, Tcl/Tk is great for basic stuff
| but I don't think you could do even a small part of what you
| can do with an html + css + javascript GUI.
| aidenn0 wrote:
| 1. Tk can do a lot more than you think
|
| 2. I have seen very basic GUIs in electron just for the
| cross-platform nature of it.
| nmadden wrote:
| It used to be the other way around. It's been a while since
| I did much UI work, but the web always felt incredibly
| frustrating for layout compared to Tk. (I think CSS finally
| has something approaching Tk's grid layout manager?) There
| are fewer frameworks for Tk, but I think it has most things
| you'd need. Maybe some of the finer control over fonts etc
| is lacking.
| criddell wrote:
| > most things you'd need
|
| Say you wanted to write a CAD app like
| https://www.onshape.com. There's no way you could do it
| Tcl/Tk, is there?
| oldlaptop wrote:
| Most of what I'd call the UI - all the toolbars and
| pseudo-floating-windows - is basic bread-and-butter Tk
| stuff. The 3D context and CAD kernel would be the tricky
| bits. There are extensions floating around to work with
| OpenGL (or whatever), but I don't see doing the heavy
| CAD-kernel lifting in Tcl - that would likely have to be
| in C, or whatever. (Just as it presumably is for
| Onshape.)
| Karrot_Kream wrote:
| I agree with you but a lot of the demand for GUI tools is
| small tools. Think something like Postman: it's really just
| a code editor widget to put in some request metadata and a
| table view storing requests. This is the kind of tool that
| something like Tcl would be great at and really doesn't
| need the sophistication of HTML+CSS+JS.
| catherinecodes wrote:
| Absolutely. It's even been remarkable stable--programs
| written 20 or 30 years ago work without any kind of
| modification.
| jamal-kumar wrote:
| Last use I remember seeing for it was in scripting Intel FPGAs
|
| https://www.intel.com/content/www/us/en/docs/programmable/68...
| duskwuff wrote:
| Tcl is widely used in EDA automation in general - it's not
| just an Intel thing. Xilinx, Synopsys, Cadence, and Mentor
| all use Tcl extensively, for example.
| jamal-kumar wrote:
| Super interesting, what's the rationale behind its use
| there?
| duskwuff wrote:
| That's what it was created for, believe it or not. And
| it's been used there since the early '90s; there were
| very few other embeddable scripting languages at the
| time, so it caught on quickly.
| bsder wrote:
| John Ousterhout realized that every single EDA tool at
| Berkeley wound up implementing a crappy extension
| language. So, he implemented a language so that there
| could be a single, not-so-crappy extension language for
| the Berkeley EDA tools. He made C integration
| particularly easy (something the lisps of the time didn't
| really do). As his students spread out, each company they
| hit had a shitty extension language and they lobbied to
| get it replaced with Tcl and thus Tcl spread.
|
| The issue with languages is that memory, CPU, and disk in
| the early 1990s are still fairly expensive. You need a
| language that is _small_ yet still complete. Even today,
| the only languages that really fit that bill are Scheme
| /Lisp, Tcl, and Forth.
|
| The memory limitations releasing are why you see the
| "stringly-typed" scripting languages like Tcl, Perl, etc.
| from the late 1980s transition to "dynamically typed"
| languages in the 1990s like Python, VB, later Ruby,
| Javascript, etc.
|
| Tk popped up because GUI development at the time was
| utter shit (web doesn't exist, VB6 doesn't exist, etc.).
| It is really hard to describe just how much better Tk was
| than _anything_ else in the time frame.
| neves wrote:
| When I had contact with TCL for a networking class in the 90's
| I already knew Python and didn't like that "everthing is a
| string" pathos.
|
| For me the greatest TCL contribution was Ousterhout's
| dichotomy:
| https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy or by
| the author himself: https://web.stanford.edu/~ouster/cgi-
| bin/papers/scripting.pd...
| vFunct wrote:
| It's the scripting language of the EDA industry. If you're
| designing computer chips, you're using TCL. Cadence and
| Synopsys standardized on TCL 30+ years ago.
|
| It's strength is that you get to operate EDA tools as if they
| were shell script commands, like run_my_task -option_a
| -option_B
|
| If you aren't designing computer chips, you have no reason to
| use it. It's a horrible language.
|
| The sooner the EDA industry can get rid of TCL, the better.
| doublerabbit wrote:
| > 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.
| vFunct wrote:
| 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.
| doublerabbit wrote:
| > 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.
| Karrot_Kream wrote:
| I'm curious why you feel this way.
|
| A long time ago as a college student I used Tcl in an EDA
| internship. It was awful for reasons completely unrelated to
| Tcl. There was a library of tool-specific primitives. The
| primitives were badly documented, badly tested, and nobody
| actually understood how any of it worked except cargo-culting
| and copy-pasting each others' scripts. Code only worked on
| the happy path and there was almost no thought given to edge
| cases. There was no culture of code review so nobody
| scrutinized your code to find out whether you were using Tcl
| in the right way or not. I'll grant, though very lightly,
| that Tcl has more accessible metaprogramming facilities than
| Python which makes it easier to _misuse_ than Python. Similar
| to how Ruby in the hands of a undereducated /bad Ruby
| programmer is also quite gross.
|
| But I had the same issues using Perl in the EDA industry. The
| conclusion I came to was that code standards were just
| abysmal in EDA because code was largely seen as a cost-center
| activity rather than a profit-center activity as the real
| output was the ETL or the device and not the code that went
| into it.
|
| I re-learned Tcl when I was older and when my time in EDA was
| a faint memory and I found the language a joy. It was
| remarkably easy to get started in and really easy to build an
| application out of. This experience further made me reflect
| on how bad the code culture in EDA was.
|
| So I'm curious what specifically you'd see the EDA industry
| move to and how you think it would fix the problems EDA
| currently has with Tcl. Python, is the successor I imagine?
| That said my actual time in EDA was very short so I welcome
| the opinion of an actual insider.
| vFunct wrote:
| It's basically like shell scripts, and really only useful
| for running shell-like commands. You don't want to do
| anything complicated with it, such as any direct data
| processing. I mean, you can, but your code is not going to
| be readable. As a Cadence Applications Engineer, I had to
| decode so many customer TCL scripts, some tens of thousands
| of lines, to figure out what they were trying to do. It's
| not fun.
|
| As a language, Python is the correct answer.
|
| And now, Python just has so much more widespread support.
| You can get any library you want in Python, with its
| millions of packages available. Want to do some AI
| processing on your schematics while printing out a graph?
| There are all sorts of libraries for that. You can't get
| that in TCL.
| wduquette wrote:
| I think of Tcl as Lisp for C programmers; by which I mean, Tcl
| give you the metaprogramming capabilities you get with Lisp in
| a language that looks more like C, plays well with C, is much
| more straightforward than your typical shell language, and has
| a cross-platform GUI. A skilled Tcl programmer can do magic.
|
| I spent ten years, from 2005 to 2015, programming almost
| entirely in Tcl/Tk and I loved it. Since then I mostly use it
| for casual scripts rather than for writing apps; but it's still
| my #1 choice when I need to do some scripting to automate
| something at the OS level.
| wduquette wrote:
| I should add...Tk is the easiest GUI toolkit I've ever used
| (and I've used a bunch of them). It's got all the basic stuff
| you need, either built-in or readily available. But it comes
| from the classic desktop GUI world, you have to work at it to
| make it look nice, and it's a pain to do webpage-like layouts
| with it.
|
| I wouldn't do an end-user GUI in Tk at this point; but for
| in-house tools that need a GUI and don't need to be on the
| web it's hard to beat.
| bch wrote:
| Standard fare:
|
| BigIP iRules in F5 network appliances (and A10 appliances)[0],
| orchestration in Argonne National Labs super computer[1],
| Tealeaf[2], Python Tkinter[3] ...
|
| _I_ use it day to day because it's got a great balance of
| Lispyness and simple scriptyness, and a great C interface. It's
| got a fine REPL, and can be built up (by writing in C) with
| extensions that are 100% first-class canonical Tcl, in good
| part (wholly?) because Tcl is such a simple language[4], and
| homoiconic[5]. A joy to develop in and use.
|
| [0] https://community.f5.com/kb/technicalarticles/irules-
| concept...
|
| [1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
|
| [2] https://www.acoustic.com/pdf/Acoustic-Experience-
| Analytics-%...
|
| [3] https://docs.python.org/3/library/tkinter.html
|
| [4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm
|
| [5] https://stackoverflow.com/questions/6492704/what-exactly-
| doe...
| vodou wrote:
| Quite common in space industry. It is the script language used
| in many (all?) SCOS-2000 based mission control systems. Yes, is
| is actually used to control satellites and spacecrafts.
| robinsonb5 wrote:
| I used it a few weeks ago to fetch and display access timing
| histograms in an FPGA project.
| wduquette wrote:
| I should also note that Richard Hipp, the creator of SQLite,
| says that SQLite is coded in Tcl. The database engine itself is
| coded in C, of course; but the vastly larger test suite is
| mostly coded in Tcl; and it's the test suite that makes SQLite
| the reliable engine that it is. The test suite persists; the
| engine's been re-written in whole and in part.
| bch wrote:
| 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
| wslh wrote:
| 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 on Unix/Linux.
| oldlaptop wrote:
| The Redis protocol reads a _lot_ like Tcl code.
| smartmic wrote:
| 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 many SQLite
| applications. This is mainly related to (rapid) prototyping use
| cases.
|
| From https://sqlite.org/tclsqlite.html :
|
| > The SQLite library is designed to be very easy to use from a
| Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the
| primary test suite for SQLite is written in TCL. SQLite can be
| used with any programming language, but its connections to TCL
| run deep.
| oldlaptop wrote:
| 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.)
| forinti wrote:
| I used it a few times, mainly because of Freewrap. With very
| little code I was able to write a Windows app with GUI that I
| could distribute easily as an executable: - A
| backup app for an online sales application (inputs items and
| spits out a file); - An app to fix files in a buggy POS
| for a large retail chain (this might have been used in
| thousands of machines, I can't recall the details now); -
| A small app to copy Forms/Reports to the server, fire
| compilation, and push the new file to git; - A wrapper
| for gs to help a media department easily join many PDFs into
| one file.
|
| All these have a page or maybe two of code.
| IshKebab wrote:
| The only reason to use it today is because you're forced to by
| the EDA industry. Otherwise there are far far better options.
|
| That also means this release is basically irrelevant for the
| next 10 years because that's about how long it takes the EDA
| vendors to update their bundled TCL versions.
| cmacleod4 wrote:
| It's unfortunate that people who dont "get" Tcl feel forced
| to use it because they are in EDA.
|
| I used to have the opposite problem. My employer would not
| allow me to write anything mission-critical in Tcl because
| they thought other people would not be able to maintain it.
| But now that I'm retired I can write as much Tcl as I like,
| which is quite a lot :-)
| oldlaptop wrote:
| From the (little) I've seen of that world, I'm not sure the
| EDA vendors understand Tcl very well either; I wouldn't
| want to work with scripts for Cadence's schematic capture
| tool, and that's not because of Tcl, it's because their
| scripting interface is a disaster. (Exposing C++ iterators
| at the script level, for example.)
| vFunct wrote:
| Ironically the schematic capture scripts were likely
| written in SKILL (LISP-like language) and not TCL.
|
| SKILL is much better than TCL for data processing. TCL's
| strength is in command control flow.
| IshKebab wrote:
| I "get" TCL - it's a neat hack. Arguably even an elegant
| hack. I can see how it would be fun to play with, in the
| same way that BASIC was.
|
| But most of my work isn't playing and I don't want it to be
| built on hacks.
| fullstop wrote:
| I use it for "expect" because it just works.
| dvzk wrote:
| 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.
| fullstop wrote:
| 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.
| stackghost wrote:
| >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.
|
| For a long time it was the only way to get a decent IRC bot
| going, because eggdrop[0] was a Tcl wrapper around a small C
| core, but the only place I've seen it in the wild other than
| IRC bots was in the Xilinx toolchain and once when I was in
| undergrad some TA was using it to get telemetry from Tektronix
| oscilloscopes in the robotics lab.
|
| [0] https://www.eggheads.org/
| throw0101b wrote:
| > _Anybody using it for something else and can speak to why
| you'd use it today?_
|
| It was often used as an embedded language (e.g., in F5 load
| balancers), especially in the pre-Lua days.
| BoingBoomTschak wrote:
| 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 spec-like doc like
| cppreference nor lackluster "minimalist" stuff like pydoc
| (compare `pydoc print` with `man n puts`, for example).
|
| * One of the simplest if not the simplest interaction with C,
| letting you write C plugins very easily (with critcl and swig
| to help).
|
| * Not slow, not fast. In the same ballpark as cpython or Perl;
| doesn't need a tracing garbage collector, refcounting does the
| job since no cycles are possible by design (worse for
| throughput, but lighter runtime).
|
| * Fun type system that is superficially "everything is a
| string" (like sh) but in reality "everything is a tagged union
| with on-the-fly conversion when needed and a guaranteed string
| representation". Allows for transparent serialization (`puts
| $mydict stdout` <=> `set mydict [read stdin]`), like CL's
| read/write.
|
| * Powerful introspection through `info` (mainly). Allows for
| stuff like getting the name/body/arglist of a procedure, get
| all the registered procedures, know if a variable exists, get
| information on the stack frames and their content, etc...
| Together with `trace`, you can even write an internal debugger
| in few lines.
|
| * Procedure arguments are passed by pointer with a copy-on-
| write system: don't modify the argument and you don't get any
| memory copy. To you, it just looks like regular passing by
| value.
|
| * Modifying the procedure arguments is done via `upvar`: in
| Tcl, a variable reference is just a name (string) attached to a
| relative stack frame number, quite elegant considering the
| language's core concepts.
|
| * If you use at least the builtin extensions (thread, http,
| tdbc, tcltest, msgcat) and the very basic
| tcllib/tclX/tclUdp/tklib packages, you're almost set for life.
| Personally, I also recomment the very convenient tclreadline,
| tdom, pipethread, tablelist and tclcurl.
|
| * Channels is one of the cleanest I/O implementation I've ever
| used with some cool features:
|
| - Transformations allowing filters like deflate/zlib/gzip or
| TLS to be put on a channel (see `transchan` for the API).
|
| - Reflected aka virtual channels, to make your own channels.
| Basically like glibc/BSD's unportable fopencookie/funopen or
| CL's gray streams.
|
| - Centralize a lot of ioctl/fcntl mess and even more (like
| defining the EOF char) in `chan blocked/configure/pending`.
|
| - Integration with the event loop via `chan event/postevent`
| allows for a nice callback oriented approach to sockets and
| pipes.
|
| - Other third-party channel types include pty (expect), random,
| memory or fifo (memchan).
|
| * Builtin event loop (see `after`, `vwait`, `socket -server`
| and `chan event`) for powerful and seamless concurrency/command
| scheduling. Much simpler than Python's very
| "AbstractBeanFactory" asyncio.
|
| * An elegant thread extension consisting of an interpreter per
| thread and no raw access to other thread's memory. Comes with
| both simple (`thread::send/broadcast/transfer`) and performant
| (`tsv`) synchronization/communication facilities.
|
| * Finally a sane, light and portable (even more with Tile) GUI
| toolkit: Tk.
|
| * One of the fastest Unicode aware regex implementations,
| written by Henry Spencer himself. Has its own greater-than-
| POSIX-ERE syntax called ARE, not as complete as PCRE (lacking
| lookbehind constraints, most importantly), but still great for
| an hybrid NFA/DFA engine. Performance comparison with Perl:
| https://github.com/mariomka/regex-benchmark/pull/44.
|
| * `uplevel` (eval a script in a different stack frame) and
| `tailcall` (replace the current procedure with another command)
| let you augment the language by implementing control structures
| and keywords yourself. Inferior to CL's synergy between
| unhygienic macros, "naked AST" style homoiconicity, symbols as
| first-class objects, gensym and quasi-quoting, but still quite
| powerful.
|
| * Safe interpreters let you do very fun things like config
| files in Tcl with limited access to the machine and master
| interpreter.
|
| * Recent versions (>= 8.5) really embraced FP with:
|
| - Real lambdas (but not closures, these have to be emulated)
| through apply.
|
| - Purer hash maps (dict) than ugly sticking-out-like-a-sore-
| thumb arrays.
|
| - Lisp style prefix arithmetic (allowing for `* 3 [+ 1 2]`
| instead of `expr {3 * (1 + 2)}`) including sane behaviour for
| more than two (reduce) or zero (neutral element) arguments.
|
| - Builtin map/filter (lmap) with 8.6. See https://wiki.tcl-
| lang.org/page/Functional+Programming for more.
|
| * Multiple more-or-less powerful OO systems (now based on the
| builtin TclOO): [incr Tcl] for C++ style OO, XoTcl for a take
| on CLOS or Snit for something Tk oriented.
|
| * Some massive issues on the top of my head: lacking a
| LSP/SLIME equivalent, the warts of the weird type system (no
| way to differentiate between atoms and single element lists or
| evenly sized lists and dicts), missing metaprogramming
| facilities like quasi-quoting, no official support for UDP and
| UNIX domain sockets, no GC for class instances (cf
| https://core.tcl-lang.org/tips/doc/trunk/tip/550.md), no FFI in
| core, subtly broken exec (cf https://core.tcl-
| lang.org/tips/doc/trunk/tip/424.md and https://core.tcl-
| lang.org/tips/doc/trunk/tip/259.md)
|
| Here are some project I made with it, still worth using
| compared to CL which is my true love, simply because its stdlib
| is better suited for a lot of tasks:
| https://git.sr.ht/~q3cpma/mangadex-tools
| https://git.sr.ht/~q3cpma/rymscrap
| https://git.sr.ht/~q3cpma/lemonbar-tcl
| https://git.sr.ht/~q3cpma/tcl-misc
| cmacleod4 wrote:
| Hey, you missed out coroutines :-)
| natrys wrote:
| I use it to write long running little scripts. It's better than
| shell, and imo more useful out of the box than Lua. They are
| basically for I/O (often using sqlite which it has great
| integration with, or using expect which is also great) so I
| don't care about performance, but I like that it requires much
| less memory compared to say Python for that kind of little
| things (there is also jimtcl which is also neat in this
| regard).
| breck wrote:
| For those that are new to Tcl, there's an alternate universe
| where Tcl is the browser language instead of Javascript:
|
| "Interesting footnote: the founding of Netscape occurred at the
| same time I was deciding where to go in industry when I left
| Berkeley in 1994. Jim Clarke and Marc Andreessen approached me
| about the possibility of my joining Netscape as a founder, but I
| eventually decided against it (they hadn't yet decided to do Web
| stuff when I talked with them). This is one of the biggest "what
| if" moments of my career. If I had gone to Netscape, I think
| there's a good chance that Tcl would have become the browser
| language instead of JavaScript and the world would be a different
| place! However, in retrospect I'm not sure that Tcl would
| actually be a better language for the Web than JavaScript, so
| maybe the right thing happened."
|
| Source: https://pldb.io/blog/JohnOusterhout.html
| hathawsh wrote:
| Perhaps. I think one of the main reasons JS caught on is that
| it had no significant baggage and the designers could take it
| in any direction it needed to go. Every language used by more
| than a few people, no matter how good it is, has some baggage.
| As a result, in that alternate universe, the browser scripting
| language landscape might have been a lot more fragmented.
| breck wrote:
| > it had no significant baggage and the designers could take
| it in any direction it needed to go
|
| This is a fantastic insight and put very well. Thank you.
|
| New platforms unlock rare opportunities for new languages
| that have no baggage and can focus on fully exploiting the
| new platform.
| IshKebab wrote:
| I doubt the world would have stuck with TCL if that had
| happened. JavaScript was good enough for people to put up with.
| TCL definitely isn't. More likely we would have ended up with
| TCL + something else, with TCL deprecated.
| kevin_thibedeau wrote:
| The work on the safe subset of Tcl for the web can be exploited
| today to run untrusted scripts in an easily managed sandbox. If
| you want you can strip away enough commands for the language to
| be non-Turing complete.
| Koshkin wrote:
| > _maybe the right thing happened_
|
| Absolutely. I would have hated to see things like
| set x [ expr $y + $z ]
|
| all over the place. (As a _command_ language, this is not so
| bad.)
| froh wrote:
| funny enough, tcl browser plugins were around from at least
| 1996
|
| https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
|
| I'm pretty sure some fellow students came into our computer
| room before that, "look now there even is a TK plugin for
| Mosaic!". it was not in "look it's like gopher but with a
| mouse!" days, but not that much later.
|
| however you of course had to _do_ something to use it, while
| JavaScript came out of the box (once it was there).
| gorgoiler wrote:
| 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 <<
| self_.
|
| How does Tcl fare under these criteria?
| wduquette wrote:
| The Tcl language is made up of _commands_ ; a command has a
| name and takes an argument list, with which it can do literally
| anything. The standard commands are written in C; Tcl `procs`
| are commands that are written in Tcl. The control structures,
| like `if` and `foreach` and `while` is just a Tcl command. The
| `proc` command that defines a proc is just a Tcl command.
|
| I think of it as Lisp for C programmers.
|
| So: is the language implemented mostly in itself? No, it's
| mostly implemented in C. Is there a minimal amount of magic?
| No; the amount of magic you can do is effectively unlimited.
| bch wrote:
| > Is there a minimal amount of magic? No; the amount of magic
| you can do is effectively unlimited.
|
| I might be mistaken, but I think the OP was asking if there
| is surprising magic (I.e. special cases/considerations) built
| into the language, in which case I'd say, "No, Tcl is not
| "magical", but surprisingly simple and regular." That said,
| indeed it's powerful in its application of its primitives,
| but you do still need to mind some things (don't pretend* you
| can quote better than the quoting engine, don't pretend* you
| can do lists better than the list processor, ...). Not
| magical though - very understandable.
|
| * _rules are meant to be broken, blah, blah, but the
| "gotchas" are new practitioners falling into this, or
| advanced cases, falling into this..._
| wduquette wrote:
| In that sense, yes, very little magic...enabling vast
| conjurations. :-)
| robinsonb5 wrote:
| It's also absurdly easy to integrate into C or C++ projects,
| or to write an extension in C or C++ which can be loaded to
| implement new commands.
| gorgoiler wrote:
| Thanks for this explanation. It was very helpful. In terms of
| magic I meant it simply as how big is the set of unchangeable
| axioms, as opposed to how many things are derived in the
| language itself from a more minimal set of magical axioms.
| With Lisp being the language with the least magic _lisp for C
| programmers_ was insightful!
| orthoxerox wrote:
| Tcl is incredibly consistent, because it's homoiconic.
| talideon wrote:
| 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.
| smrtinsert wrote:
| It's a lot of magic. New control structures mean dsls are as
| easy as thinking about them
| tpoacher wrote:
| I recently asked HN if Tcl is still relevant in 2024
| https://news.ycombinator.com/item?id=41108667
|
| Nice to see a new release coming out not too long after such a
| question :)
| Karrot_Kream wrote:
| > New Notifiers: The central event handling engine in Tcl is now
| constructed on top of the system calls epoll or kqueue when they
| are available. The select based implementation also remains for
| platforms where they are not.
|
| This is huge! A big portion of why concurrency in Tcl was so
| dated and why the language was considered so non-performant was
| because it relied on `select` despite `epoll` and `kqueue` being
| available for at least a decade.
|
| Tcl is one of my favorite languages because of how easy it is to
| get started with and how easy metaprogramming is.
| kragen wrote:
| mostly people consider tcl non-performant because fundamental
| operations are about twice as slow as cpython, which is no
| speed demon: https://news.ycombinator.com/item?id=41637953
|
| another reason is that we don't know how to write fast tcl, as
| i inadvertently demonstrated in that thread
| sedatk wrote:
| I can't overstate my love for Tcl, yet I had only a little chance
| to use it when writing XiRCON IRC scripts back in the late 90's.
| Such an elegant language: simple, easy to learn, flexible. I call
| it Lisp for humans. I wish it were more popular. So glad to see
| that it's still alive and kicking.
| mattw2121 wrote:
| Agreed, my only exposure to Tcl was writing IRC scripts for
| bots and I have nothing but fond memories of the experience.
| sshine wrote:
| Same. Such a simple life writing text-only event handlers.
| doublerabbit wrote:
| 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!
|
| Javascript, TCL and NaviServer (and which has it's own modules
| such as DNS Server, LDAP, Mail really makes an powerful tool.
|
| If you're looking to get in to TCL and Web Development, you can
| really create fun with the two combined. I highly recommend that
| if you wish to dabble with something on the side for easy
| learning and plentiful features. Go take a look.
|
| [0] https://wiki.tcl-lang.org/page/NaviServer
|
| https://github.com/naviserver-project/naviserver
|
| [1] https://news.ycombinator.com/item?id=35648805
|
| https://www.linuxjournal.com/article/6164
|
| [2] https://openacs.org/about/history
|
| https://openacs.org/
| sbuttgereit wrote:
| 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.
| urbandw311er wrote:
| Wow Tcl is still a thing? Takes me back to university days -- and
| even 20 years ago it was considered a bit of a poor man's UX. I'm
| off to read the article and see if it's any better these days...
| bachmeier wrote:
| 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.
| oldlaptop wrote:
| 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.
| urbandw311er wrote:
| It's not exactly encouraging when a website for a UI tool
| contains absolutely no visual examples of UI on any of its main
| pages.
| cmacleod4 wrote:
| There is a redesign of the website in progress. In the
| meantime, take a look at https://wiki.tcl-
| lang.org/page/Showcase .
___________________________________________________________________
(page generated 2024-09-26 23:00 UTC)