Tcl Thread

>>32119 Also [] and {} are used for quoting ([] is replaced with the value of the expression inside and {} doesn't perform any substitutions except for escaping closing braces). Strings can also be not quoted at all if they don't contain whitespace so actually yes that snippet of code is all function application and different quoting conventions even if it doesn't look like it.

Wrong. Everything has a string representation. It is not actually a string. >should I learn this or that Why not just try them all? That's what I did and why I write Tcl scripts.

>>32126 Oh ok. I must've misinterpreted the wiki article. Thanks for correcting me.

Hi, lainons. Yesterday I started learning Tcl and it seems like its paradigm of everything being a string is simply better and easier than everything else I've tried. Why don't more languages do it? And why does it seem like we get less innovative ideas in programming?

wait, isn't shell like this?

>>32111 Yes the principles are similar but Tcl does it in a way that seems closer to lisp to me in a way that i can't really put my finger on. I think it's because most Tcl scripts are made up of function application and passing values returned by those functions around. For example this script: tcl set x 0 set list {1 2 3 4 5} while {$x < [llength $list]} { puts [lindex $list $x] } is entirely made up of function application and different quoting conventions.

I saved this copypasta a while ago: Tcl is the best scripting language for the real but still productive hacker (some of the fattest Schemes are not far). * Extremely small - whole syntax/grammar is described in 12 rules in a single man page (Tcl(n)) of 150 lines and there's no reserved keyword. * Official man pages! No pydoc or cppreference garbage, here you almost have C degree of exhaustivity. * Kind of "unfashionable" language meaning basically no poz. * At least two implementations with jimtcl being a very thorough embedded one. * One of the simplest if not the simplest interaction with C, letting you write C plugins very easily (with critcl, ffidl and swig to help). * Comparable in speed to cpython, a bit slower than Perl5 and Lua. Has a and a WIP/dead LLVM compiler (tclquadcode) for a big speedup in the far and uncertain future. https://wiki.tcl-lang.org/page/Tcl+Performance for more. * Cool 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 unique string representation". Allows for some very cool things like editing dictionaries as lists or lists as strings and transparent serialization (`puts $mydict $chan` <=> `set mydict [read $chan]`). * Talking about types, multiprecision arithmetic is transparently handled, allowing you to do `expr {42 ** 1000}` if you just want to. * Very 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 exist, get information on the stack frames and their content, etc... Together with `trace`, you can write an internal debugger in few lines. See https://wiki.tcl-lang.org/page/Full+program+trace+onwards for an example. * 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. * On the subject of performance and simplicity, no need for an actual garbage collector, reference counting is enough because you cannot make circular references. * Modifying the procedure arguments is done via `upvar`: in Tcl, a variable reference is just a name (string) with a stack frame number, quite elegant considering the language's 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 use the very convenient tclreadline, tdom, pipethread and tclcurl. Some more here: https://core.tcl-lang.org/jenglish/gutter/ * Channels is 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 a channel without an actual backing FD. Basically like glibc's unportable fopencookie. * Centralize all ioctl/fcntl soykaf and even more (like defining the EOF char). * Integration with the event loop via `chan event` 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. * An elegant thread extension consisting of an interpreter per thread and no raw access to other thread's memory. Comes with both simple (`thread`) 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. cf https://github.com/mariomka/regex-benchmark/pull/44. * `uplevel` (execute 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. * Obvious Lisp inspiration: * Homoiconic through strings. * Usual FP goodies like map/filter/apply. * Already mentioned macros. * Proper prefix arithmetic allowing for `* 4 [+ 1 2 3]` instead of `expr {(1 + 2 + 3) * 4}` with sane behaviour for more than two (reduce) or zero (neutral element) arguments. * Multiple more-or-less powerful object systems ([incr Tcl] for C++ style OO, XoTcl for CLOS inspired OO or Snit for something Tk oriented). * All of that with the same advantage of CL: it does not enforce nor preach a particular way of programming, unlike the ML family that comes with the "everything is immutable" ball and chain that often gets in the way instead of helping (because, big surprise, modifying data is often an essential part of efficient and intuitive algorithms while recursing only makes sense when manipulating recursively defined data types). See https://wiki.tcl-lang.org/page/Functional+Programming for more. * Biggest inconvenient is the near-death state of the language and community (practical consequences: no LSP/SLIME equivalent, bugs accumulating, lack of maintainted libraries) as well as some warts that can't be solved easily. As someone who knows a bit of CL, the language itself is less powerful (especially on the macro side) but the standard library is miles ahead during the day to day. Basically, a mix of CL and sh that somehow managed to end up very good and getting even better with time. I could continue all day, but you should just try it. Some more talk about it: * https://wiki.tcl-lang.org/page/What+is+Tcl * https://wiki.tcl-lang.org/page/Tcl+Articles * https://colin-macleod.blogspot.com/2020/10/why-im-tcl-ish.html * https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html * http://antirez.com/articoli/tclmisunderstood.html Where to begin: * man n Tcl (or `man 3tcl Tcl` on retarded distros like Debian) * https://wiki.tcl-lang.org/page/TCL+for+beginners * https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+0 * https://wiki.tcl-lang.org/ for everything, this is where the Tcl community lives * Rosetta Code for examples/exercises Anon's page: https://wiki.tcl-lang.org/page/q3cpma >>32111 Yes but Tcl is comfier and more powerful. I have been thinking about learning either Tcl or Perl.

>>32116 > Official man pages! No pydoc or cppreference garbage, here you almost have C degree of exhaustivity. True that's a really good thing about tcl. The man pages are also almost always helpful. > "everything is a tagged union with on-the-fly conversion when needed and a unique string representation" This is true but i think even the wiki says it's actually just strings that can be interpreted differently by different procs. > I have been thinking about learning either Tcl or Perl. I'd definitely go with Tcl. I've tried learning Perl before but it just wasn't as intuitive and comfy to me and the documentation i could find wasn't as exhaustive and helpful.

>>32121 That's pretty neat, actually

>>32115 That looks exactly like any other mainstream language. Arguably, 'set' is jot function application, and a while loop certainly is not.

>>32119 > a while loop certainly is not. > In Tcl everything is a command, and everything goes through the same substitution phase. > Control structures are commands, not language syntax. Tcl cannot have constructs which aren't commands by design

>>32120 Well there are operators but those are just strings that get treated differently by expr normally "1 + 2" is interpreted as command "1" applied to the arguments "+" and "2".

>why does it seem like we get less innovative ideas in programming 1) Late civilisational decadence kills real progress (i.e. not "new iPhone 32, my duderinos!!!1!") or directs it to hedonistic endeavours. 2) The industry wants fungible cogs, so power and absolute productivity will always lose to stuff like Java/Ada/(part of) C++ that can be understood and used by the lowest common denominator. And the startup/FAANG world is made of soyboys who just want the latest shiny without looking at the old shiny and not caring about stuff like stability. btw, I made that pasta, so ask any question about Tcl, though I'm completely ignorant of Tk. As said in my page, I moved to CL and kept Tcl purely for scripting, though.

>>32132 I update that paste some time ago, too.

> it seems like its paradigm of everything being a string is simply better and easier than everything else I've tried. it isn't. unless you're comparing it to bash. >And why does it seem like we get less innovative ideas in programming? because even go - a language made by neckbeards after 30 years of frothing about C and finally conceding to have some basic hygene - is more sane than your retarded autist language, as well as just as powerful. string manipulation is literally just a poor half working implementation of data structure manipulation, which all languages past the 70s already got mostly right

>>32144 >because even go - a language made by neckbeards after 30 years of frothing about C and finally conceding to have some basic hygene - is more sane than your retarded autist language, as well as just as powerful "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." Rob Pike The only good thing from Go is the CSP implementation. The end. The worst thing is its C-like limp wristed type system that's still miles from ML; if you go the static typing way, go all in, don't do half measures, mate. And still no macros, nor named parameters.

>>32144 > it isn't. unless you're comparing it to bash. I'm comparing it to all 10 of the languages I tried. Out of all of them only Lisp comes close to the simplicity of Tcl > your retarded autist language Dude are you mad? Did my opinion hurt your feelings?

>>32109 >And why does it seem like we get less innovative ideas in programming? Coming up with something that's both new and useful in a world where all the fundamental stuff has already been discovered is an uphill battle.

>>32155 Yeah ig that's true. Most "innovative" ideas that we have are things that were present in algol and lisp.

Why is it so difficult to create a single self-contained binary of a Tcl/Tk program? There are "Starkits", "Starpacks", etc. but it's not exactly simple to create a standalone program. A Tclkit is needed to make "Starkits", but Tclkit is only available from a third-party source, not from the official Tcl/Tk website. Why is there nothing as simple as cc myprog.c -o myprog ?

>>32584 Because it's an interpreted language, dumbass.

>>32584 >>32587 You could embed the script text into the interpreter executable to make a standalone executable. People don't care enough to make things easy to use though so that's probably not implemented. Maybe a shell script contain the interpreter executable & the script text and feed the text to the interpreter.

>>32132 Why did you move to Common Lisp? I'm trying to choose something to branch out to after some time with Scheme and CL/tcl are two of my shortlist. Is it better to do one before the other?

>>32653 Read the end of my page (https://wiki.tcl-lang.org/page/q3cpma). Mainly: * CL simply is a lot less dead in term of libraries and its stdlib is quite well furnished. * It has SLIME while Tcl doesn't have LSP or anything like it. * uplevel is not a replacement for macros + quasiquoting + gensym. * Gradual/optional typing is incredible. * Having named parameters is underrated. * Nice to have literals evaluating to themselves, to use (if t 1 2) instead of [if 1 {string cat 1} {string cat 2}].

>>32653 Another advantage of learning Common Lisp instead of Tcl: there are more Common Lisp books than Tcl books, so you'll have an easier time learning more.

>>32109 >Why don't more languages do it? And why does it seem like we get less innovative ideas in programming? Plenty of languages do, and it causes all kinds of problems. Like >>>32111 pointed out Shell does this. Powershell attempts to improve this by giving the parser too modes, Expression (with types) and Command (all strings). Early languages had no types (BCPL) and so you might ask why they were added at all. It turns out that type checking adds a lot value for programmers in catching bugs. With the Unix Way, communication is usually done with untyped byte streams, this has been seen as a huge feature and disadvantage depending on your perspective. Everything must be scraped and parsed, versioning,extension and error reporting are difficult. For instance, everything as a file natrually raises the question, how do you eject a CD-ROM drive, how do you resize a TTY ? The standard operations bytestream operations (open(),close(),read(),write()) may not lend themselves well to these cases - in fact ioctl 's are a mess created for out of band proprietary extensions for each unique that requires additional features. Powershell attempted deal with the limitations of a string-based approached by passing .NET objects between "commandlets" that come with type information, and allow for easy manipulation (cf. Where-Object filtering by properties ). I do appreciate type checking in my languages - I use type hinting in python and mypy. I am not sure that I want to require my programs to all share a common tool chain and be able to interpret binary objects from the other. FreeBSD has a cool project of getting coretuils to emit JSON to avoid parsing. I think it would absolutely suck to do everything a string at all times in a complex program but might be awesome for small scripts.

>>32584 >cc myprog.c -o myprog lol compiling C isn't that easy, not even close. Its that easy for C Standard Library only functions, and not even all of them (-lpthread , -lm ). The reality of compiling C is Makefiles, CMake, or autotools their own DSLs. It generally buys you a lot (virtually every platform in the world), but its complex. Contrast this with pythons import soln .

>>32109 Well, I heard people use TclTk for building gui programs and Tcl is a standard scripting language in EDA world. My story: I use guile for writing "glue" and for embedding, I have the project written in guile and C and I don't have much time to support it. I though I could go opensource and maybe find 1-2 men for supporting it, but I'm afraid that lisp will be very repulsive for people. What about Tcl as a substitution for guile in my case and moving to Tcl for scripting and embedding at all? >>32664 True, I still can not into m4.

I'm new to Tcl (I just started working through the Tcl tutorial at https://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html). Currently, all I know of is: #!/usr/bin/tclsh puts "\t hello world!" #no formatting: puts {\t hello world 2!} puts "1 + 2 is [ expr 1+2 ]" if 0 { puts stderr "ERROR!!" } else { puts "The script is working fine!" } #Tcl is both command-based and string-based lang: set something 42 #this is crazy! #but it's like saying that Perl is write-only lang, # (it only applies to bad programmers) set {this is allowed} "ok" ;#puts ${this is allowed} set name [string toupper "Lain"] puts "bye, $name\n$something" The main reason why I got interested in Tcl was tk (I would like to use it to create GUIs for my scripts, I know I could use Tkinter in Python but I wanted to go back to Tk's roots). Other reasons include: * Expect: https://wiki.tcl-lang.org/page/Expect * Tcl can be used as embedded scripting language in C or C++ project (similar to Lua or Chibi Scheme or Guile) * the event loop (a quick search found https://www.tcl.tk/about/event.html and https://wiki.tcl-lang.org/page/Tcl+event+loop and https://wiki.tcl-lang.org/page/Event+tutorial). I wonder why did Tcl plummet in popularity? It doesn't seem like a bad language or too arcane. I installed tcllib (https://wiki.tcl-lang.org/page/Tcllib) and I'm wondering how is wish better than regular tclsh? Also, I don't get the graphical part of wish (it just opens a blank tk window???). How can I add tk widgets to the window that wish opens? I'm also interested in Expect (a way to automate interactive cli tools with Tcl). I think I will DL the Exploring Expect: a Tcl-based toolkit for automating interactive programs book (sadly, the book is not available anywhere anymore). I'm also considering buying the newish The Tcl Programming Language: A Comprehensive Guide book: https://www.magicsplat.com/ttpl/index.html (the author also has Tcl themed blog) There are more tutorials listed at https://wiki.tcl-lang.org/page/Online+Tcl+and+Tk+Tutorials >>32133 Thanks for writing it!

Why isn't there a hybrid unix shell that's based on KSH and Tcl? Wouldn't Tcl be good choice for writing Unix shell because it's a string-based (like Unix shell) but it would have a better language for scripting (Tcl)? Tcl also was designed to be easily embedded into other programs. You would also get access to Tk. Tksh could be the starting point (read the Usenix paper). You should also take a look at desktop Korn shell (dtksh), it's a part of CDE. It gives you direct access to X11/Motif from Ksh93.

Tcl was good when Perl/Python/Ruby/Tcl didn't exist, but for 2023 I see zero reasons to invest time in this old relic.

>>37415 >old relic Define old relic? There's a lot of things all around can be called permanent.

>>37414 Never used Tcl before, eh?

>>32155 It sounds strange. How can one verify everything was invented already?

>>37361 The book you've mentioned looks like an interesting one. I can't buy it in my country, why the hell it wasn't pirated yet?

This language is very interesting? What's the ceiling? And your favorite ressource to learn it?

Since this thread got bumped, I learned recently that before he became nerd famous Steve Yegge worked on a team that used Tcl (and Emacs) as tooling to semi-automatically write object-oriented assembly OSs and programs like GEOS for mobile devices and weaker computers that messier systems like Windows or heavyweights like Unix couldn't run on back in the day. Apparently it let them write more and faster code than even their C competition could with what I guess were the god-awful compilers of the time. Figured it'd be worth mentioning today. Tcl must be pretty capable in the right hands if it can accomplish something like that: https://newsletter.pragmaticengineer.com/p/steve-yegge

>>37498 You can't, or at least I'm pretty sure you can't. I really didn't write the statement with verifiability in mind. But I think the overall point still stands. We've already invented structured control flow; we've already invented function calls; we've already invented garbage collection; we've already invented closures; you get the picture. I'm not saying that there isn't more to invent, but it's going to require a lot more cleverness than it did back then, when a retard language like COBOL could casually introduce structs, one of the most important concepts in modern programming, particularly in statically typed languages.

Ashok's book https://rutracker.org/forum/viewtopic.php?t=6236694

>>32144 >powerful overused trash-tier buzzword what even constitute """powerful""" here?

>>32686 I do use Tk for my programs and they do look quite nice if you go the extra mile and render your own theme

>>38035 My guess is "similar to the C abstract machine". Tell this sort of person about higher-order functions as a data structure (which is what Tcl's "strings" implement) or pattern-matcher theory post 1980 or so and they get very confused.

>>38036 How to implement custom rendering for TK? For example this >>75169 lainon wrote gui library for X11, I want TK to use this library where should I start digging? I couldn't find any answers in Ousterhout's book.

>>38036 That soykaf looks great. How did you that? I've wanted to learn Ruby+TCL/TK to do stuff like that but I have no idea how to do that. This guy wrote a Ruby IDE in Ruby+TCL/TK. A whole IDE. https://www.arcadia-ide.org/

This thread had me dive into Tcl. I'm loving it for scripting, it is harmonious with Unix environments. chsh -s /usr/bin/tclsh

I literally only use Tcl for Expect. Outside of expect it's too weird to use normally. It's got some cute design once you dig into the whole, everything is a command and the quoting rules and nesting, it's almost beautiful. But honestly it just feels like a slog. Fiddling with TTYs in $your_favorite_lang isn't worth it for me where expect just works though. Nice software that.

>>32119 >That looks exactly like any other mainstream language. Arguably, 'set' is jot function application, and a while loop certainly is not. This reminds me of an article I read. https://morepablo.com/2023/05/where-have-all-the-hackers-gone.html >While visiting a friend, he noticed I had a Golang shirt, he told me he loved Golang, I told him I like the shirt but the language less. He got excited and proposed we "get into it" later, and after dinner we plopped down on couches and he said "alright! Let's get into it!" I wanted to talk about its garbage collector (1, 2), how goroutines/channels are a delightful abstraction but I prefer BEAM's abstractions because it allows for Supervisors, Golang's very loose approach to correctness… and he didn't want to talk about any of that. He, on the other hand, emphatically talked about how much he loved that "the Go developers knew that all you need is a for loop. Someone brought Scala into my company and I hate the mental shift."

I love this lang, it took me only a week to get a grip of the rules, and just having the manual open beside me when working is enough. The documentation is surprisingly good, though the wiki is a mess. The meta-info you can get is incredible. There is a lot of potential for modular code. Tcl is definitely my favourite, even above Lisp.