>>> import tkinter
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.9/tkinter/__init__.py", line 37, in <module>
import _tkinter # If this fails your Python may not be configured for Tk
ImportError: libtk8.6.so: cannot open shared object file: No such file or directory
I specifically stated "any windows or mac python program".
Indeed, most linux distro packaging teams decided to split tk in a separate package that is not installed by default. Same for pip and setuptools. Of course, this made getting a congruent python experience extra hard, on a platform with already plenty of gotchas for python setup, but hey, they saved a few Mo.
$ python3
Python 3.6.9 (default, Jan 26 2021, 15:33:00)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more
information.
>>> import tkinter
>>> tkinter.Tcl().eval('puts {hello, world}')
hello, world
''
>>>
Ubuntu 18.04; but it's not on a machine running 20.04
Ever since I came across a Tcl programming book in my college library I've always been fascinated with it. I return to it every couple of years to play around with meta-programming ideas that I've come up with.
For example, here is a really naive example of implementing a DSL that allows you to write something like
SELECT name age FROM person INTO name age
and have the values of the selected columns be placed in variables specified after the INTO keyword.
Implementing that isn't too difficult:
# a pretend database
set language(name) Tcl
set language(created) 1988
set language(created_by) "John Ousterhout"
set language(stable_release) 8.6.11
proc SELECT {args} {
### Lowercase all the args to make things easy
set args [string tolower $args]
set from_index [lsearch $args from]
set cols [lrange $args 0 [incr from_index -1]]
set table [lindex $args [expr $from_index + 2]]
# Get access to the global variable with the value contained in $table
global $table
set into_index [lsearch $args into]
set vars [lrange $args [incr into_index] end]
foreach c $cols v $vars {
upvar $v local_var
set val [lindex [array get $table $c] 1]
set local_var $val
}
}
After that, you could "SELECT created name created_by FROM language INTO x y z" and then
puts "$y was created by $z in $x"
>Tcl was created by John Ousterhout in 1988
Watching the first 30 minutes of this video, TCL has one more thing in common with Lisp: the fact that I appreciate it as an artifact and a testament to how simple a language core can be, but I would never ever want to maintain a production system in it
There’s a huge difference between a minimal lisp interpreter you may have written in university and something industrial strength like Common Lisp or Clojure
Then I don’t understand why you’d be outright opposed to running a production system with it. It’s not as shallow as just not liking the syntax, is it?
I spent 4 years back around 2000 developing on a CMS that used TCL as the underlying language. It was mostly a hate/hate relationship. More for the CMS than TCL itself, but that can be said about any CMS.
I worked for a startup in the late 1990s that had a reseller agreement with Vignette. If I recall Vignette was going for something like a million dollars a site license. I took one look at it and ended up rolling our own TCL-based CMS in case the Vignette deal went south. Well I left, Vignette went south and the company ended up using my CMS.
The TCL interpreter, unlike other scripting languages, doesn't perform any checks at the start of a program. That is, even silly syntax errors are found not before that very line is reached. If that happens to be in a lesser trodden error path, you might find it only at a very inconvenient time.
I use TCL as I use EDA SW a lot, but I found the most horrible feature of TCLs language design, comments are not comments. A comment is a command to ignore the line. However a comment with a curly brace in it can break control flow, as its partially interpreted. I found this by commenting out some code (that was malformed) and my tcl program failed to run. I ended up commenting out the entire program save one line and still I got errors. Then I realised to my horror the comments with braces were actually affecting control flow!
That said, in EDA in general it works well for the most part.
> Tcl (like Perl) shot itself in the foot right as the DotCom/DotBomb went off.
I don’t know what you mean “shot itself in the foot“ here. Some examples?
> Python was effectively completely stable through all this and gained a critical mass following.
I don’t know how much more “effectively stable” Python was than Tcl. Can you expand on this?
I personally see this largely as “luck of the draw”. It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL. Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that? We can see things now and say “popular languages are popular”, and that’s about it.
Perl and Tcl carved themselves into incompatible versions (Perl 6 and Tcl 8) at a critical moment.
Python, on the other hand, felt like it was at version 1.5.2 absolutely forever.
> It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL.
Except that, in the late-1990s/early-2000s, it didn't matter. Scripting languages were slow relative to compiled languages. Multiple-threads effectively didn't exist. Hyperthreading didn't hit until 2003--after the DotBomb.
> Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that?
Gee, who could have guessed that a whole lot of scientists and engineers kinda liked Matlab the program but hated Mathworks the company and that providing somewhere for them to jump ship to would be popular? Like ... absolutely everybody?
Of course, just the idea isn't enough. The alternative has to be sufficiently capable.
Thus ... Enthought. Enthought personnel put in a lot of elbow grease and work to make Python a scientific computing go-to language.
As always, the best way to predict the future is to make it.
I wasn’t actually maintaining software across this divide, but I do still occasionally see Tcl 7.x installations in the wild and find it quite recognizable. It seemed to me the biggest changes from 7->8 were byte code interpreter and “dual ported” Tcl_Obj to store values vs naive C strings(which should have only exposed themselves as “improved performance”).
The release notes[0] for Tcl 8 seem to list minor-ish annoyances, but perhaps you did have to support something across the 7-8 divide; I won’t argue against your experience in that case.
> As always, the best way to predict the future is to make it
Did TCL have a compatibility break with version 8? I've always perceived TCL as an incredibly stable language, with features added but rarely removed/changed. Is there a time when that wasn't true?
Correct, the move from Tcl 7 to Tcl 8 did not break Tcl code nor C extensions, and brought huge performance benefits. C extensions could be updated to use them, but the C string API continued (and continues) to exist.
> I personally see this largely as “luck of the draw”.
Not luck of the draw, it was because of the OOP craze in the late 1990s and early 2000s. In undergraduate school I took some introductory programming classes for an easy A, as I was already working as a web developer (like many in my generational cohort) for living expenses. (My degree program was entirely unrelated.) In one of those classes I just ended up as something of a [very poor] TA for the professor. At some point he told me that his department was looking to reorganize their curriculum to emphasize OOP and asked what I thought about Java and Python. I had never programmed in either, mostly working with Perl, JavaScript, PHP and ColdFusion. But I told him that Python was becoming popular in the open source space, and the simplicity of the language, including dynamic typing, and freely available tooling would likely make it more accessible.
I don't know if he took my advice, but in any event as I remember things Python eventually overtook Perl partly, if not largely, by riding the OOP wave. People like to say that it was because Python was simpler and more consistent (TOOWTDI instead of TMTOWTDI), but it was really only simpler and more consistent in the context of OOP programming. For quick, top-to-bottom procedural programming tasks Perl has always been simpler, IMO.
Perl 5 also had OOP, but neither Perl nor Tcl could credibly claim "native" OOP during the relevant time frames. By contrast, one of Python's founding design goals was OOP.
Ruby didn't have very much mindshare in the U.S. during the relevant period. Which is a real shame. There's always been a significant amount of great work coming out of Japan that never gets popular attention elsewhere. Ruby is one of the notable exceptions, though it's break-out success came belatedly. (Wikipedia says the first English language Ruby mailing-list was created in 1999. AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008. All of these are indicative of an exceptionally late popular introduction to the English language programming community.)
I don't mean to imply that luck had nothing to do with Python's success. It's just that if you look at the contenders at the time and the qualities that people were (rightly or wrongly) looking for in a programming language, it's not at all surprising why Python gained popularity. To the degree luck had anything to do with it, it was largely the timing of those nexus of factors.
AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008.
O'Reilly published Matz's Ruby in a Nutshell in 2001, but it didn't sell very well. When I worked there, I encouraged more Ruby publishing but only after I published the "Rolling with Ruby on Rails" articles (January 2005) did that argument get much traction.
The Pragmatic Programmers released their first Ruby programming book in 2000, by way of comparison (and Dave introduced me to DHH in 2004, which is how I decided to seek out the Rails articles).
According to my recollection and accounts of others I've read, a huge part of Python's early success was the maintainers' decision to support a comprehensive "batteries included" distribution of extension modules, including binary compiled libraries.
Tcl made the crucial (in retrospect wrong) decision not to support a central extension package repository or well-stocked releases and chose to focus on the core. This forced users to scrounge the web for extensions and hope they compiled on their platforms, and depend on sketchy support from individual authors.
The OOP craze played a significant role as well I think. I recall that in the late 1990s Tcl was part of something of a renaissance of varied programming paradigms escaping academia and getting applied in the wild (partly in the form of clever Tcl extensions). But Java/OOP and WWW/server-client killed that movement dead.
I just watched this. Karl Lehenbauer gives a basic intro to the language, making comparisons with Lisp, talks about his own development as a software engineer, and how his company FlightAware uses Tcl for most of their code. I found his personal history the most interesting part, there were lots of things there that made me think: yes, been there, done that :-)
I have fond memories from school in the 90s, I think, where I found an irc client which had Tcl scripting. I didn't do anything spectacular but I do remember loving the language at the time.
"tac" or "tik"? ? Client for AOL Instant Messenger? I used the console version on a Mac SE 30 running BSD, and shared a serial tty w/ brother at the same time. Had to use a readline wrapper for it, but it worked great!
Eggdrop [0] and BitchX [1] come to mind. Irssi [2] has a plugin that enables Tcl scripting.
I'm currently fiddling with TkCAD [3] in order to put a small CNC machine to use here, it needs some small adaptations to work on Linux, but I think it's a nice find!
Amusingly, any windows or mac python program comes with a TCL interpreter, thanks to the tkinter GUI:
Nooope, not on linux at least
On Debian GNU/Linux Tkinter is provided by the python-tk package (might differ in other distros).
I specifically stated "any windows or mac python program".
Indeed, most linux distro packaging teams decided to split tk in a separate package that is not installed by default. Same for pip and setuptools. Of course, this made getting a congruent python experience extra hard, on a platform with already plenty of gotchas for python setup, but hey, they saved a few Mo.
I didn't know about pip and setuptools being separate packages. That explains some things.
Of my understanding, tkinter is not in python packages because it needs an WM to run correctly
Oh I understand the motivation. I also know it caused a lot of pain, for very little gain.
Manu Linux distributions have tclsh preinstalled.
Just now:
Ubuntu 18.04; but it's not on a machine running 20.04
Ever since I came across a Tcl programming book in my college library I've always been fascinated with it. I return to it every couple of years to play around with meta-programming ideas that I've come up with.
For example, here is a really naive example of implementing a DSL that allows you to write something like
and have the values of the selected columns be placed in variables specified after the INTO keyword.
Implementing that isn't too difficult:
After that, you could "SELECT created name created_by FROM language INTO x y z" and then
Watching the first 30 minutes of this video, TCL has one more thing in common with Lisp: the fact that I appreciate it as an artifact and a testament to how simple a language core can be, but I would never ever want to maintain a production system in it
There’s a huge difference between a minimal lisp interpreter you may have written in university and something industrial strength like Common Lisp or Clojure
I know. I just meant the language itself, not the interpreter.
Then I don’t understand why you’d be outright opposed to running a production system with it. It’s not as shallow as just not liking the syntax, is it?
TCL never got the love it deserves.
At least outside the electronics and embedded software development space. It's all over this area.
I spent 4 years back around 2000 developing on a CMS that used TCL as the underlying language. It was mostly a hate/hate relationship. More for the CMS than TCL itself, but that can be said about any CMS.
Vignette?
I worked for a startup in the late 1990s that had a reseller agreement with Vignette. If I recall Vignette was going for something like a million dollars a site license. I took one look at it and ended up rolling our own TCL-based CMS in case the Vignette deal went south. Well I left, Vignette went south and the company ended up using my CMS.
The TCL interpreter, unlike other scripting languages, doesn't perform any checks at the start of a program. That is, even silly syntax errors are found not before that very line is reached. If that happens to be in a lesser trodden error path, you might find it only at a very inconvenient time.
I learned to hate TCL with a passion.
What checks shall it perform ? It's an interpreter.
I use TCL as I use EDA SW a lot, but I found the most horrible feature of TCLs language design, comments are not comments. A comment is a command to ignore the line. However a comment with a curly brace in it can break control flow, as its partially interpreted. I found this by commenting out some code (that was malformed) and my tcl program failed to run. I ended up commenting out the entire program save one line and still I got errors. Then I realised to my horror the comments with braces were actually affecting control flow!
That said, in EDA in general it works well for the most part.
I use it daily at work. (EDA space)
Tcl (like Perl) shot itself in the foot right as the DotCom/DotBomb went off.
Python was effectively completely stable through all this and gained a critical mass following.
> Tcl (like Perl) shot itself in the foot right as the DotCom/DotBomb went off.
I don’t know what you mean “shot itself in the foot“ here. Some examples?
> Python was effectively completely stable through all this and gained a critical mass following.
I don’t know how much more “effectively stable” Python was than Tcl. Can you expand on this?
I personally see this largely as “luck of the draw”. It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL. Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that? We can see things now and say “popular languages are popular”, and that’s about it.
Perl and Tcl carved themselves into incompatible versions (Perl 6 and Tcl 8) at a critical moment.
Python, on the other hand, felt like it was at version 1.5.2 absolutely forever.
> It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL.
Except that, in the late-1990s/early-2000s, it didn't matter. Scripting languages were slow relative to compiled languages. Multiple-threads effectively didn't exist. Hyperthreading didn't hit until 2003--after the DotBomb.
> Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that?
Gee, who could have guessed that a whole lot of scientists and engineers kinda liked Matlab the program but hated Mathworks the company and that providing somewhere for them to jump ship to would be popular? Like ... absolutely everybody?
Of course, just the idea isn't enough. The alternative has to be sufficiently capable.
Thus ... Enthought. Enthought personnel put in a lot of elbow grease and work to make Python a scientific computing go-to language.
As always, the best way to predict the future is to make it.
I wasn’t actually maintaining software across this divide, but I do still occasionally see Tcl 7.x installations in the wild and find it quite recognizable. It seemed to me the biggest changes from 7->8 were byte code interpreter and “dual ported” Tcl_Obj to store values vs naive C strings(which should have only exposed themselves as “improved performance”).
The release notes[0] for Tcl 8 seem to list minor-ish annoyances, but perhaps you did have to support something across the 7-8 divide; I won’t argue against your experience in that case.
> As always, the best way to predict the future is to make it
Truth.
[0] https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities
Did TCL have a compatibility break with version 8? I've always perceived TCL as an incredibly stable language, with features added but rarely removed/changed. Is there a time when that wasn't true?
Correct, the move from Tcl 7 to Tcl 8 did not break Tcl code nor C extensions, and brought huge performance benefits. C extensions could be updated to use them, but the C string API continued (and continues) to exist.
> I personally see this largely as “luck of the draw”.
Not luck of the draw, it was because of the OOP craze in the late 1990s and early 2000s. In undergraduate school I took some introductory programming classes for an easy A, as I was already working as a web developer (like many in my generational cohort) for living expenses. (My degree program was entirely unrelated.) In one of those classes I just ended up as something of a [very poor] TA for the professor. At some point he told me that his department was looking to reorganize their curriculum to emphasize OOP and asked what I thought about Java and Python. I had never programmed in either, mostly working with Perl, JavaScript, PHP and ColdFusion. But I told him that Python was becoming popular in the open source space, and the simplicity of the language, including dynamic typing, and freely available tooling would likely make it more accessible.
I don't know if he took my advice, but in any event as I remember things Python eventually overtook Perl partly, if not largely, by riding the OOP wave. People like to say that it was because Python was simpler and more consistent (TOOWTDI instead of TMTOWTDI), but it was really only simpler and more consistent in the context of OOP programming. For quick, top-to-bottom procedural programming tasks Perl has always been simpler, IMO.
> Not luck of the draw, it was because of the OOP craze in the late 1990s and early 2000s.
Sure, but Tcl also had/has a well-regarded OO system, and Ruby was on the scene, so Python doesn’t actually stand out singularly.
Perl 5 also had OOP, but neither Perl nor Tcl could credibly claim "native" OOP during the relevant time frames. By contrast, one of Python's founding design goals was OOP.
Ruby didn't have very much mindshare in the U.S. during the relevant period. Which is a real shame. There's always been a significant amount of great work coming out of Japan that never gets popular attention elsewhere. Ruby is one of the notable exceptions, though it's break-out success came belatedly. (Wikipedia says the first English language Ruby mailing-list was created in 1999. AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008. All of these are indicative of an exceptionally late popular introduction to the English language programming community.)
I don't mean to imply that luck had nothing to do with Python's success. It's just that if you look at the contenders at the time and the qualities that people were (rightly or wrongly) looking for in a programming language, it's not at all surprising why Python gained popularity. To the degree luck had anything to do with it, it was largely the timing of those nexus of factors.
AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008.
O'Reilly published Matz's Ruby in a Nutshell in 2001, but it didn't sell very well. When I worked there, I encouraged more Ruby publishing but only after I published the "Rolling with Ruby on Rails" articles (January 2005) did that argument get much traction.
The Pragmatic Programmers released their first Ruby programming book in 2000, by way of comparison (and Dave introduced me to DHH in 2004, which is how I decided to seek out the Rails articles).
According to my recollection and accounts of others I've read, a huge part of Python's early success was the maintainers' decision to support a comprehensive "batteries included" distribution of extension modules, including binary compiled libraries.
Tcl made the crucial (in retrospect wrong) decision not to support a central extension package repository or well-stocked releases and chose to focus on the core. This forced users to scrounge the web for extensions and hope they compiled on their platforms, and depend on sketchy support from individual authors.
The OOP craze played a significant role as well I think. I recall that in the late 1990s Tcl was part of something of a renaissance of varied programming paradigms escaping academia and getting applied in the wild (partly in the form of clever Tcl extensions). But Java/OOP and WWW/server-client killed that movement dead.
I just watched this. Karl Lehenbauer gives a basic intro to the language, making comparisons with Lisp, talks about his own development as a software engineer, and how his company FlightAware uses Tcl for most of their code. I found his personal history the most interesting part, there were lots of things there that made me think: yes, been there, done that :-)
Should have an alternative lisp or scheme syntx (r7rs-small)
I have fond memories from school in the 90s, I think, where I found an irc client which had Tcl scripting. I didn't do anything spectacular but I do remember loving the language at the time.
"tac" or "tik"? ? Client for AOL Instant Messenger? I used the console version on a Mac SE 30 running BSD, and shared a serial tty w/ brother at the same time. Had to use a readline wrapper for it, but it worked great!
http://users.tmok.com/~smike/
Eggdrop [0] and BitchX [1] come to mind. Irssi [2] has a plugin that enables Tcl scripting.
I'm currently fiddling with TkCAD [3] in order to put a small CNC machine to use here, it needs some small adaptations to work on Linux, but I think it's a nice find!
[0] https://eggheads.org/
[1] http://bitchx.sourceforge.net/
[2] https://irssi.org/
[3] https://github.com/revarbat/TkCAD
TCL was a popular scripting language for IRC bots. Eggbot was done really nicely.