Tcl is basically a sloppier Perl with a GUI.
TCL fits on microcontrollers. If I'm looking at anything other than Python or bash(for trivial logicless scripting) it's probably because I'm in a constrained environment.
Tcl the Misunderstood (2006)
61–70 of 72 posts
Re: Tcl the Misunderstood (2006)
#62One thing which I've always not understood about Tcl/TK is why there isn't a standard graphical tool for laying out a GUI program. For a long while, when I might have used Tcl/TK, I instead used Runtime Revolution/Livecode (a cross-platform HyperCard clone) which had a very nice system for interactively drawing programs. I'd really like for there to be an agreed-upon standard option for graphical program development…
> a cross-platform HyperCard clone I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)
Decker is FOSS, and available in both a web version and native builds for MacOS, BSD, Linux, and Windows: http://beyondloom.com/decker/
If you've seen Decker previously you might find it useful to know that it has recently acquired several "escape hatches" for interoperating with software and APIs outside its usual sandbox: http://beyondloom.com/decker/decker.html#thedangerzone
Re: Tcl the Misunderstood (2006)
#63Tcl is basically a sloppier Perl with a GUI.
> Tcl is basically a sloppier Perl
That’s a hot take for one language with basically a sheet to describe it[0], and another whose “rules” are best described by “whatever this implementation does.”
Re: Tcl the Misunderstood (2006)
#64Earlier quoted context omitted.
> a cross-platform HyperCard clone I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)
Livecode going opensource and targeting HTML5 was a big part of why I chose it (and funded it on Kickstarter). Still annoyed about their changing course and removing the Community Edition.
[deleted]
Re: Tcl the Misunderstood (2006)
#65Earlier quoted context omitted.
> a cross-platform HyperCard clone I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)
Decker is FOSS, and available in both a web version and native builds for MacOS, BSD, Linux, and Windows: http://beyondloom.com/decker/ If you've seen Decker previously you might find it useful to know that it has recently acquired several "escape hatches" for interoperating with software and APIs outside its usual sandbox: http://beyondloom.com/decker/decker.html#thedangerzone
Thanks for reminding me of Decker, which I think has been featured on HN a few times.
I live in a HiDPI, color world but the 1-bit vintage Mac-style GUI and fonts look nice to me.
https://hypercard.org also has some interesting links.
I think the sandbox/doesn't play well with others issue has affected the use cases of environments from HyperCard to Lisp to Smalltalk. Tcl/Tk seems designed for connecting to other software.
Re: Tcl the Misunderstood (2006)
#66Earlier quoted context omitted.
Decker is FOSS, and available in both a web version and native builds for MacOS, BSD, Linux, and Windows: http://beyondloom.com/decker/ If you've seen Decker previously you might find it useful to know that it has recently acquired several "escape hatches" for interoperating with software and APIs outside its usual sandbox: http://beyondloom.com/decker/decker.html#thedangerzone
Thanks for reminding me of Decker, which I think has been featured on HN a few times. I live in a HiDPI, color world but the 1-bit vintage Mac-style GUI and fonts look nice to me. https://hypercard.org also has some interesting links. I think the sandbox/doesn't play well with others issue has affected the use cases of environments from HyperCard to Lisp to Smalltalk. Tcl/Tk seems designed for connecting to other sof…
There are basically two parts to Decker's stance on sandboxing:
To maintain fidelity between the capabilities of web-decker and native-decker, the constraints of web browsers need to be treated as a common denominator. Some of the ways that conventional webapps circumvent these constraints are not an option for web-decker, because it's designed to function without a server-side component; this avoids dependencies on centralized infrastructure. (There are also some features intentionally left out because they would be inaccessible on e.g. touch-based devices which lack a physical keyboard or the ability to register "hover" events from a pointing device.)
To center user-empowerment, Decker should be "safe by default" and require affirmative consent for things like sending information to remote servers or accessing the local filesystem. If a user understands the risks, they can deliberately shift Decker into a more permissive mode of operation which lets it interoperate directly with local resources, raw browser APIs, etc. By default, Decker can safely run applications written by untrusted third parties, and in "dangerous" mode it is more comparable to a conventional automation tool or scripting environment. This approach may not please everyone, but it is a carefully-considered compromise.
Decker does have paletted color support; many decks produced by users apply this to great artistic effect: https://itch.io/games/tag-decker
Re: Tcl the Misunderstood (2006)
#67One thing which I've always not understood about Tcl/TK is why there isn't a standard graphical tool for laying out a GUI program. For a long while, when I might have used Tcl/TK, I instead used Runtime Revolution/Livecode (a cross-platform HyperCard clone) which had a very nice system for interactively drawing programs. I'd really like for there to be an agreed-upon standard option for graphical program development…
I don't think it is needed. I am a hobby programmer and not even remotely competent but I can whip up GUIs in Tk with little effort and I find it quicker and easier than the graphical UI designers.
I am a visual person (at least that's what I told myself when I chose to get a graphic design degree rather than do computer science (but was one 300-level course short of a CS minor)), and I find the disconnect between the visual appearance and the obtuse code a quite difficult stumbling block --- the one tool I was successful doing using Python and TK never had a visual appearance I was satisfied with.
Re: Tcl the Misunderstood (2006)
#68Another excellent aspect of Tcl I found is extensibility of JO's C implementation. At some point I needed to write some native code for speed and making this visible to the Tcl interpreter was a pleasure. Plus the codebase is so clean and well written.
I agree, I have modified Tcl's codebase, too, to suit some of my needs (I wanted to use Tcl as my shell).
Re: Tcl the Misunderstood (2006)
#69Earlier quoted context omitted.
I don't think it is needed. I am a hobby programmer and not even remotely competent but I can whip up GUIs in Tk with little effort and I find it quicker and easier than the graphical UI designers.
I am a visual person (at least that's what I told myself when I chose to get a graphic design degree rather than do computer science (but was one 300-level course short of a CS minor)), and I find the disconnect between the visual appearance and the obtuse code a quite difficult stumbling block --- the one tool I was successful doing using Python and TK never had a visual appearance I was satisfied with.
If I am not sure how things should be laid out I just sketch it on graph paper or on my tablet, I consider each square of the graph to be 10 pixels or what ever suits and have at it. 10 or 15 minutes will generally be enough to go through many revisions and leave me with map to follow, 5 or 10 minutes of typing and it is done. After that tweaks are just changing a few numbers and the results are essentially instant since no compile time and you can see the results with a command from your editor.
Wish also has an interactive mode, not point and click but results are instant, great for learning Tk. No idea if it can work with tkinter though.
Re: Tcl the Misunderstood (2006)
#70Does anyone know of a good tutorial for getting starting with Tcl/Tk that still makes sense in 2024? I'm really intrigued by the idea of building and shipping simple, cross-platform GUIs, but I'm completely overwhelmed by all of the installation and configuration options. It seems like tclkit is supposed to be the go-tool tool for self-contained executables, but I honestly can't even figure out which site is the sour…
John Ousterhout's Tcl and the Tk Toolkit is great and has been updated to Tcl/Tk 8.5 which is recent enough to not cause headaches. Don't think it goes into self contained executable but covers everything else very well.
Edit: Just remembered that Tcl/Tk: A Developer's Guide by Flynt has a chapter on self contained executables and the various tools for making them. Have not looked into this book much so can't comment on it.