[HN Gopher] The Birth of Tcl
___________________________________________________________________
The Birth of Tcl
Author : timthorn
Score : 118 points
Date : 2022-04-21 16:00 UTC (7 hours ago)
(HTM) web link (www.tcl.tk)
(TXT) w3m dump (www.tcl.tk)
| ms4720 wrote:
| TCL and Scotty there was an awesome nms/SNMP combo
| johnisgood wrote:
| Tcl and Rebol are great. The code is compact, very easy to
| understand and quick to write, especially Rebol. You can do GUI
| in both Tcl/Tk and Rebol as well. You might want to check Rebol
| out as well: http://www.rebol.com/docs/expert-intro.html (or
| http://www.rebol.com/docs/design-objectives.html).
| jrapdx3 wrote:
| You probably already are aware of it but there's an effort to
| create an open source successor to Rebol. See the Red
| Programming Language site [0].
|
| I've played around with Red and it's pretty interesting. Though
| rather different from Tcl. Red compiles to native code out of
| the box which is an advantage. Currently Red is limited to
| 32-bit output. When they get 64-bit working along with self-
| hosting compiler I think the language could become a major
| success.
|
| [0] https://www.red-lang.org/
| johnisgood wrote:
| I know about Red. Unfortunately it requires 32-bit libraries,
| whereas Rebol 3 does not. I could not get Red to work as
| easily and nicely as I did get Rebol 3. :/
|
| > When they get 64-bit working along with self-hosting
| compiler I think the language could become a major success.
|
| I agree. I will most likely switch to it (though I have not
| dig'd deeper, hopefully it follows the philosophy of Rebol).
| I will check if my Rebol 3 programs work with it, or without
| much modification. I suppose as long as it supports 64-bit,
| has libraries for SHA512 (`system/catalog/checksums/sha512`
| in Rebol 3), along with `random/secure` and `random/seed
| now/precise`, I suppose it should be fine.
|
| In any case, it is a deal-breaker for me. I really want them
| to get 64-bit working and have a self-hosted compiler. I wish
| them the best.
|
| For the people who are interested: when I say Rebol 3, I am
| referring to https://github.com/Oldes/Rebol3. There is a
| decent and detailed post on SO about these implementations
| and their differences. I found Oldes' one to be the most
| ideal.
| jrapdx3 wrote:
| Thanks, didn't know about the Rebol3 version in the link.
| I'll have to look into it. AFAIK the Red developers goal is
| to extend the Rebol philosophy to a modern, open source
| tool that can serve a number of high and low level
| purposes. Red is coming along but slowly. Not surprising
| given the lofty ambitions of the project. I too hope they
| succeed.
| 7thaccount wrote:
| Rebol is seriously cool and criminally overlooked on HN. Unlike
| TCL, it didn't survive to the same extent. There is the whole
| Red effort (very cool), but I'm not sure if they'll get there.
| I wish them the best of luck though.
| johnisgood wrote:
| Yeah, so do I. I mentioned in my other comment that I do not
| use it because of lack of 64-bit support and whatnot. If they
| do get there, and I could replace my Rebol 3 programs with
| Red, then I will switch to it. As for Rebol 3, I use
| https://github.com/Oldes/Rebol3.
|
| For what it is worth, people ought to check out the Rebol
| cookbook. It is full of amazing stuff. So easy to implement
| somewhat complicated things. I am seriously wondering why it
| is not more popular. I would say a lot has to do with the
| fact that it has been open sourced too late (should have been
| open to begin with, IMO), and that there are too many
| different, but somewhat alike implementations. It is
| confusing to a newcomer. They do not know what to use, why,
| and if it actually is under active development and will
| continue to be.
| timbit42 wrote:
| Rebol was created by Carl Sassenrath who wrote the Amiga OS and
| put pre-emptive multi-tasking in it.
|
| After he left Commodore he wrote Amiga Logo.
|
| https://en.wikipedia.org/wiki/Carl_Sassenrath
| 7thaccount wrote:
| I really like Tcl the language and some of the tooling, but
| certainly not all of it.
|
| I kind of wish there was a single reputable website that I could
| go to for all versions. I don't want something from Source Forge
| or ActiveState or some random person's website. I'm sure they're
| all fine, but I'm a lot less sketched out with running Anaconda
| Python or Java than Tcl. Funny enough, some Python systems
| include Tcl for the Tk GUI, but I haven't been able to get some
| of the libraries I'm interested in to work with that version.
| AceJohnny2 wrote:
| > _The Tcl Conference is also one of the world 's premier events
| for upper body wear: each year there are 5-10 different T-shirt
| designs given away to recognize various extensions, events, etc._
|
| That's funny. Is there a gallery collecting these?
| sokoloff wrote:
| 25 years ago, I worked on a team that built a full online retail
| brokerage in Tcl (including web page generation). It made me love
| the language as a developer, but the runtime performance on late
| 1990s hardware (especially pre-Tcl8) was pretty poor.
|
| I've since reached for Tcl several times per year and enjoy it
| each time.
| geogra4 wrote:
| My first job was writing Tcl code to orchestrate various little
| c++ apps that were used for data processing to create various
| terrains for a flight sim training app. Love the language. But
| that was a long time ago.
| AceJohnny2 wrote:
| The article doesn't discuss how Sun turned away from Tcl and
| embraced Java instead (understandable since it focuses on Tcl).
|
| It's interesting because Sun had the same goals for Tcl as they
| did for Java (or vice-versa!): " _evolve Tcl into a universal
| scripting language for the Internet_ ", " _allows untrusted
| scripts to be evaluated safely_ ", " _Tcl plugin, so that Tcl
| scripts can be evaluated in a Web browser_ ".
|
| Ousterhout spun Tcl out of Sun in late 1997, which feels like the
| timeline when Sun was turning to Java.
|
| Is there insider history available anywhere on how and why that
| transition happened? I can certainly imagine that performance and
| expressivity were a concern.
| jgrahamc wrote:
| I was the VP of Engineering of Ousterhout's spinout company,
| Scriptics, and worked for him. I don't know the story of how
| Sun made the decision but John has a longer History of Tcl
| here: https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php
|
| "At the same time, it became clear that Sun needed to focus its
| language evangelism around Java, which was released shortly
| after I arrived at Sun and had become hugely popular. Though
| Java and Tcl are very different languages, used for very
| different purposes, it would have been too hard for Sun to
| evangelize both of them simultaneously. I came to the
| conclusion that, overall, Java offered more benefits for Sun
| than Tcl did."
|
| John was a great person to work for. He hired me despite the
| fact that in the interview with him I told him I'd never used
| Tcl and when he extolled its virtues he told me that it was
| "easy to learn and had powerful regular expressions" and I said
| "Don't those two things contradict each other?" He stopped
| talking and had a rather surprised expression on his face. I
| thought I'd blown it. Actually, I'd done the most important
| thing I could possibly have done: made him think something new.
| rcurry wrote:
| I got exposed to TCL/TK while working for a National Lab a
| long time ago. At the time I was a hardcore C++ developer and
| after a week or two with TCL/Tk I was almost dying laughing
| about how easy it was to build really cool applications. I
| truly miss working with that platform.
| amitamit wrote:
| I was at Sun Labs at that time - Ousterhout's group was
| internally regarded as one of the top groups there. I was in a
| different group.
|
| My recollection is that the concerns were not around technical
| merit: a. Tcl and Java were positioned as competitors, b. Sun
| saw Java as a critical weapon in its fight against Microsoft,
| c. Java won the internal battle, which led to Tcl/Scriptics
| spin out.
| sigzero wrote:
| I love Tcl. I haven't used it in a while as my job scope has
| changed. I used to write all sort of utilities and throw a little
| UI on top with Tk. I still keep watch on what happens in that
| space.
| rudasn wrote:
| If I remember correctly, Tcl was the first language I coded in.
| That was in late 90s, I asked my dad to pay some hosting company
| so I could have IRC bots. I don't think I ever understood how
| thinhs really worked, but I remember I was able to type
| "commands" in IRC channels and my bots would do stuff, like send
| private messages, join channels, etc.
| bitwize wrote:
| Eggdrop!
| sedatk wrote:
| I like Tcl a lot. The design is simple, extremely easy to learn,
| and yet the code is still maintainable (((looking at you LISP))).
| Among the scripting languages I've used, I probably liked Tcl the
| most. I wish it didn't fall out of favor.
| monetus wrote:
| You're not alone
| epage wrote:
| I've been evaluating different languages for writing plugins
| and TCL really seems tempting. Unfortunately, I've been leaning
| towards Lua just due to its pervasiveness (today). I also
| vaguely remember one of the top contenders having some more
| esoteric parts that concerned me. I can't remember how much of
| that was TCL, Lua, or both.
| sigzero wrote:
| Both are good with that kind of usage. It will really end up
| being your preference.
| gleenn wrote:
| In my very humble opinion, the parens in lisps are one of the
| most redeeming qualities as it makes IDE manipulation so much
| easier and macros are much easier to write. I did enjoy Ruby a
| lot too though, and you can definitely see some of the clean-
| syntax similarities.
| pjmlp wrote:
| I was a big Tcl user between 1999 and 2002, our startup was an
| heavy user, however the experience of slowly replacing Tcl with
| C code, made me never choose languages without either JIT or
| AOT compiler ever again, other than for scripting tasks.
| [deleted]
| mftb wrote:
| Indeed as sibling comment mentions there are Tcl fans out
| there. The guy who created redis has good things to say[0].
| With a little evangelism it could maybe stage a comeback.
|
| [0]http://antirez.com/articoli/tclmisunderstood.html
| sigzero wrote:
| Dr. Hipp of SQLite fame likes Tcl. The ginormous test suite
| is in Tcl.
| p4l4g4 wrote:
| Same here! Tcl/tk is a lovely little language and much under
| appreciated by many! Interesting software started in tcl, such
| as redis, expect and sqlite. Still use some tcl through
| environment-modules, in my personal work setup.
|
| Have to say that lisps are very nice too, in my opinion.
| Started learning a little common lisp recently and was
| surprised by its elegance. I think lisps can be very
| maintainable, when care is taken. It's easy to write unreadable
| programs, but this also holds for tcl. With great power comes
| great responsibility.
| dwringer wrote:
| I think a lot of programmers as they are first learning their
| first language go through a phase of trying to count brackets
| and parentheses and failing miserably (those bugs are
| horrible to hunt down) before finding editors that help match
| them for you. Even then, many editors don't do a great job of
| this so coders develop a certain aversion to using many
| parentheses or brackets of any type. This is also rooted in
| the conventional C philosophies that more than two levels of
| indentation are a bad thing.
|
| At least that was how I used to see things, prior to getting
| familiar with Lisp and emacs. Now I find myself using all
| kinds of parentheses in every language so as to make order-
| of-operations more explicit at a quick glance. I even learned
| to count parentheses and almost enjoy it.
|
| I think learning Python's complete-opposite approach of
| getting rid of brackets in most cases and using indentation-
| only also clarified my thinking on the matter. I find that
| this brings back the old problem of mismatched-bracket bug
| hunting, but worse because indentation levels can get shifted
| and then there's no amount of paren-matching that will help
| sort things out.
|
| In essence, I think everyone should learn Python and Lisp,
| then see which philosophy they like better.
| andrepd wrote:
| Off-topic, but you should be aware that the (((triple
| parentheses))) are apparently an anti-semitic thing. Just so
| you know it can be misinterpreted in some contexts x)
| MisterTea wrote:
| When idiots started using the "echo" tags in tech oriented
| forums, people would jokingly ask where all these damn lisp
| programmers were coming from.
| [deleted]
| todd8 wrote:
| I've never heard of this perhaps because HN is about the only
| social media I use. However, there is an ADL page on this.
| See https://www.adl.org/education/references/hate-
| symbols/echo
| sigzero wrote:
| Context is everything. I am pretty sure LISP is not Jewish so
| (((looking at your LISP))) is perfectly fine.
| [deleted]
| smrtinsert wrote:
| Fellow tcl lover here. When I left my tcl job I felt like I was
| approaching some next level of productivity that I've never
| quite found with other languages
| a9h74j wrote:
| Is this a classic story, perhaps on the tcl wiki:
|
| _On site with a customer, the question of creating a GUI
| interface came up. A few engineers left and, after a bit of
| time in another room, came back with a proposal already demo
| 'd in tcl/tk._
| jrapdx3 wrote:
| I've used Tcl extensively over many years. It's a tremendously
| flexible tool that can be shaped to accomplish many tasks. Tcl
| was never the most widely used scripting language but it's
| alive and well, and its development continues with new versions
| on the horizon. There still is a lot to like about Tcl.
| AceJohnny2 wrote:
| Interesting to read how Expect came so soon out of TCL (TCL:
| 1988, Expect: 1990)
|
| Expect remains an essential tool for dealing with interactive
| (but not TUI) terminal application, and in usage really fits its
| TCL roots perfectly. In contrast, I've found the Perl and Python
| ports of Expect to be somewhat awkward, not fitting those
| languages paradigms as well.
|
| In the 2020s, I still think Expect is TCL's killer app.
| jrapdx3 wrote:
| Expect has had remarkable longevity, though I'd say the
| greatest impact of Tcl has been though *sqlite* which started
| as a Tcl extension and still uses Tcl in its development.
| Sqlite is used so very widely, hard to find any major software
| that doesn't incorporate it. I guess Tcl is nearly everywhere,
| under the hood anyway.
| [deleted]
| nomel wrote:
| I think expect is a result of having no programatic interface
| for command line tools. I ofter wonder how much more useful
| these command line tools, and how many hundreds of man years
| would have been saved with buggy text parsers, if there was a
| programatic stdin/stdout, in addition to the one for humans,
| from the beginning.
|
| But, with the reality we live in, expect helped me many times
| in the past. These days, I use python's pexpect for the same
| use cases.
| AceJohnny2 wrote:
| Furthermore, I've been wanting to give our embedded app's CLI
| some smarts, add some control-flow features, and I can think of
| no better way to do implement that than make it a TCL shell.
| bitwize wrote:
| Tcl is insane. The language is straight out of The Book
| (Anathem). By that I mean, the semantics are not just wrong,
| they're so wrong they risk warping your brain. But the language
| somehow remains useful, powerful, and flexible. And there is
| still no faster way to get from zero to working GUI in the 2020s
| on a conventional computing environment (Windows or some Unix).
| So it's fantastic for prototyping at the very least.
| monetus wrote:
| What drives you the most nuts about the syntax?
| bitwize wrote:
| 1) I realize that Tcl isn't technically stringly typed on the
| inside anymore, but extensionally it still appears so.
|
| 2) Attempting to understand how variable scoping works in Tcl
| is like attempting to stare into the maw of some eldritch
| horror, deeper than the earth itself by some trick of other-
| space, and lined with infinite rows of writhing, fang-tipped
| cilia. The central tenet of lexical scoping -- that bindings
| visible outside a set of braces should also be visible inside
| unless overridden with a specified inner binding, didn't
| occur to Ousterhout when he designed Tcl and Tcl has to deal
| with the implications of that. 'upvar' sometimes works, but
| sometimes doesn't, and in some cases you have to reason
| through when your code is being called and what's visible
| then.
| blacksqr wrote:
| I just guess there are two kinds of people in the world. I
| think scope leakage across logical boundaries is dangerous
| and really hurts maintainability and code readability, and
| I think Tcl's tight restriction of variable scope by
| default is one of its most valuable properties.
|
| I'm so old I remember many conversations among perl and
| JavaScript programmers talking about the bug that drove
| them craziest, and it always seemed to come down to
| unexpected scope leakage and variable name collisions. Then
| there would be a lot of laughing and back-slapping and
| calls of 'been there bro!' I just can't wrap my head around
| that viewpoint. Better IMO to allow scope to cross function
| point boundaries only at well-defined points.
|
| I've been programming in Tcl for over 20 years and the
| times when use of upvar was called for have been very few.
| Meanwhile, how much of your code that you wrote 20 years
| ago still runs just fine on the latest tool stack?
| larsrc wrote:
| I was thinking exactly in the eldritch horror direction.
| Thanks for writing that, you have saved me the
| unpleasantness of finding out exactly what it was that made
| me loathe Tcl.
| AceJohnny2 wrote:
| What's not to love about `upvar`? /s
| tpoindex wrote:
| Upvar has it's place, especially when writing your own
| control structures. Outside of that, tread lightly.
| jrapdx3 wrote:
| Having used Tcl extensively I think scoping rules aren't
| really too complicated, but there are some apparent
| inconsistencies. A main one is global variables aren't
| visible inside procedures unless declared as "global",
| whereas procedures are global no matter where created (in
| the global namespace). However referring to variables and
| procedures using fully qualified namespaces is always
| correct and unambiguous.
|
| The thing with _upvar_ (and _uplevel_ ) is that by default
| _upvar_ refers to variables in the caller of the current
| _proc_. But when a _proc_ is called indirectly ( _e.g._ , a
| callback _proc_ ) then the variable _upvar_ is intended to
| reference may be 2 or more frames above. Using something
| like "upvar #2 refvar var" works as expected. It's
| analogous to deferencing pointers in C when there are >1
| levels of indirection.
|
| Is there any programming language that doesn't have _some_
| confusing rules? If a language is going to be useful the
| answer is bound to be "no". It's a curious how we get used
| to a particular (or even peculiar) syntax. When used long
| enough it begins to feel "natural" and obvious, and find it
| amazing how anyone would have difficulty understanding how
| it works.
| mdaniel wrote:
| Line comments since the "#" isn't a comment character unless
| it's following a statement or such nonsense
| puts "for real" ;# orly?
|
| https://wiki.tcl-lang.org/page/comment
|
| and there's some weird business about backslashes in comment
| characters, which IIRC "modern" tcl-ists use for ployglot
| launch scripts #!/bin/sh # this
| hides *both* lines from tclsh \ exec "tclsh" "$0"
| "$@" puts "and now, moar tcl"
| sigzero wrote:
| Wow, I comment on that page way back in 2006! I suggested a
| multi-line comment. lol
|
| I don't use end of line comments myself so that never
| bugged me.
___________________________________________________________________
(page generated 2022-04-21 23:01 UTC)