[HN Gopher] History of Tcl (2009)
___________________________________________________________________
History of Tcl (2009)
Author : jasim
Score : 55 points
Date : 2021-01-14 17:36 UTC (5 hours ago)
(HTM) web link (web.stanford.edu)
(TXT) w3m dump (web.stanford.edu)
| ggcdn wrote:
| Many earthquake engineers and researchers are all too familiar
| with Tcl, because for years the preeminent structural analysis
| tool OpenSees [1] required Tcl scripts to use/run. Just in the
| last few years was it forked to python.
|
| https://opensees.berkeley.edu/OpenSees/home/about.php
| korse wrote:
| Are TCL scripts still necessary for some VLSI software stacks?
| avmich wrote:
| Chuck Moore -
| https://web.archive.org/web/20160314224653/http://www.colorf...
| - could provide example of the opposite.
| PhaseLockk wrote:
| Yes. A typical SoC is assembled using thousands of lines of TCL
| to drive the various EDA tools that are involved in the design
| process.
| Fwirt wrote:
| I recently started learning Tcl for the heck of it and am
| surprised by what a nice little language it is and that it
| doesn't get more publicity. It's true that it's not great for
| working with numbers or complex data structures, but it's a
| really nice language for "plumbing", and is still in active
| development. The last few releases have added support for tail-
| call recursion, "coroutines", and native dictionaries. It's had a
| bytecode compiler for like 20 years, so it's not as slow as it
| used to be.
|
| As far as complaints about the syntax being weird: It's far more
| consistent than Algol descendants in that everything is a string,
| much like everything in Lisp is a list. You don't have to learn a
| bunch of different syntactic constructs, everything is a string,
| and every string is a space-delimited list, and can be
| interpreted as a command. The hardest part of the language is the
| quoting rules, which the documentation affectionately refers to
| as "quoting hell". Once you wrap your head around that,
| everything becomes clear. The standard library is pretty easy to
| learn, and the documentation is good.
|
| Check it out.
| sigzero wrote:
| The core developers are very thoughtful bunch on what gets into
| Tcl as well. It's nice to watch the back and forth traffic.
| agumonkey wrote:
| Also the community is quirky fun, I remember finding a lot of
| esoteric implementation of whatever cs/lisp concept I could
| think of.
|
| These kind of communities are fun.
| na85 wrote:
| Tcl is pretty cool as a historical curio but boy, every time I go
| back and look at old tcl code, even stuff that I wrote, it takes
| forever to wrap my head around the syntax.
|
| I'm not sure why I'd reach for Tcl today when lua exists.
| sprash wrote:
| > I'm not sure why I'd reach for Tcl today when lua exists.
|
| Use the right tool for the right job. E.g. Tcl works very well
| together with sqlite and with its own toolkit Tk. This makes it
| the perfect tool to build platform independent database user
| interfaces. The "everything is a string" philosophy makes it
| also the perfect candidate to make simple user interfaces for
| command line programs. Gitk is such an example. Would you use
| tcl to create a new browser, a large website or any type of
| large project? Obviously not.
| eadmund wrote:
| > I'm not sure why I'd reach for Tcl today when lua exists.
|
| Regular syntax, for one thing. Command-oriented sensibility,
| too.
| kevin_thibedeau wrote:
| Tcl is highly configurable because of its simple syntax and
| homoiconicity. It can be stripped down to be non-Turing
| complete for configuration files and then built back up with
| custom commands to suit ones needs.
| bch wrote:
| The syntax of Tcl is bog-simple, and it's entire operational
| description fits in a simple man page[0]. The flexibility can
| certainly be abused, though that's not strictly the fault of
| Tcl.
|
| [0] https://www.tcl-lang.org/man/tcl8.6/TclCmd/Tcl.htm
| jcelerier wrote:
| > The syntax of Tcl is bog-simple, and it's entire
| operational description fits in a simple man page[0].
|
| given a problem of fixed complexity, the simpler the
| language, the harder will the implementation of this problem
| have to be
| wott wrote:
| Yep. Languages with a simplistic syntax (and a simplistic
| paradigm) make writing compilers for those languages easy,
| but they do not make creating programs in the languages
| easy. We can think of Lisp, or even more of Forth. It is
| also a common characteristic of "esoteric" languages:
| providing very little syntax, very few keywords,
| instructions and ready-built features, is an ingredient of
| their recipe for obfuscation.
| SubjectToChange wrote:
| Why is it hard to make programs in lisp? Especially in
| something like Common Lisp?
| monetus wrote:
| Here is a pretty neat tcl->Llvm compiler
| https://core.tcl-lang.org/tclquadcode/dir
|
| There is a talk on youtube about it I know
| bch wrote:
| Not sure how to respond - you're not necessarily wrong, but
| Tcl is also not Brainfuck[0]. The GP was indicating:
|
| > it takes forever to wrap my head around the syntax.
|
| ... which (from observation) is often from second-guessing
| or overthinking the rules.
|
| [0] https://en.wikipedia.org/wiki/Brainfuck
| blue-dragonfly wrote:
| Arguments against Tcl like:
|
| https://vanderburg.org/old_pages/Tcl/war/0000.html
|
| aside, I found Tcl/Tk along with with the extension Expect:
|
| https://en.wikipedia.org/wiki/Expect
|
| to be a powerful way to do automation. In the '90s, I automated a
| process of migrating data from a mainframe to Unix workstations
| using a Tk GUI run by end users which generated Tcl/Expect
| scripts to download, convert, and verify massive amount of files
| in a batch.
| blue-dragonfly wrote:
| I haven't written any Tcl/Tk/Expect recently. It is interesting
| to know they are still being used, thanks for the updates.
| Expect was also quite useful for testing command-line
| applications. Even back then, RMS's arguments may or may not
| have applied to what he was doing, but our department got a lot
| of use out of Tcl for our sys admin work. We had many new-hires
| at the time, some without much CS background, and we found they
| could acquire and become productive in Tcl quickly, which was
| important in meeting our schedule.
| rufugee wrote:
| Heck....I just used Tcl/Expect to automate 1000s of
| transactions in one of our legacy systems. I tried a number of
| expect implementations (python, go, java), but found them all
| lacking or overly complicated compared to the original Expect.
|
| If you need to automate old terminal apps, you really can't do
| any better at the moment.
| kevin_thibedeau wrote:
| Most of those arguments are out of date. Tcl has evolved
| significantly since 94. It's never going to win on raw
| performance, but for its intended use cases, interpreter
| performance doesn't have to be best in class.
| bdowling wrote:
| My favorite Tcl trick is a single-line template file processing
| system. puts [ subst [ read [ open [ lindex
| $argv 0 ] ] ] ]
|
| (Hint: `subst` applies Tcl's string substitution function, which
| substitutes variables like $varname and Tcl commands enclosed in
| square brackets. So, this one line program can be used as a
| templating system that is somewhat like PHP or eRuby.)
| jibbit wrote:
| i could really do with React in Tcl right now
| agumonkey wrote:
| for tui or webapps ?
| Uhhrrr wrote:
| The article mentions how prominent Tcl is in EDA, but the other
| big user I'm aware of is as the scripting tool of choice for
| Cisco's IOS (as of 10 years ago, not sure if that's still true
| today).
| [deleted]
| lilyball wrote:
| Tcl is one of my favorite scripting languages to work in. It's
| wonderful in the simplicity of the core language and how you can
| write things that act like keywords as just pure Tcl. I'd love to
| see Tcl gain some modern sensibilities like closures, the ability
| to run a destructor when a variable falls out of scope or is
| deleted, nested variable scopes within a proc, etc.
___________________________________________________________________
(page generated 2021-01-14 23:01 UTC)