Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Birth of Tcl

tcl.tk

Post reply on HN
Print view View original

71–80 of 105 posts

Re: The Birth of Tcl

#71

Post by bitwize »

jrapdx3 wrote: post #47
bitwize wrote: post #12

Earlier quoted context omitted.

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 v…

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 th…

Ah, so Tcl's rules are dynamic scoping with extra steps. No wonder they're so mind-boggling.

Lexical scoping is the most straightforward, least surprising scoping strategy I've seen. With lexical closures it allows for some tremendously powerful constructs.

Re: The Birth of Tcl

#72

Post by RHSeeger »

sedatk wrote: post #2

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.

I adore Tcl, and always have. Funny that you mention Lisp, because I've always considered Tcl a kind of "close cousin" of Lisp; both in it's code structure and the ability to build new control structures and the like. It feels more Lisp-y to me than it does C-y.

Re: The Birth of Tcl

#73

Post by kevin_thibedeau »

amitamit wrote: post #39
AceJohnny2 wrote: post #27

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 ". Ousterh…

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.

In the 90's Java did have technical merit because the Tcl of that era didn't have a bytecode interpreter. It wouldn't have been practical for the sort of low level embedded devices Sun was aiming to support with Java processors. The resources needed for dynamism is also a handicap for such platforms.

Re: The Birth of Tcl

#74

Post by bch »

AceJohnny2 wrote: post #27

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 ". Ousterh…

> Ousterhout spun Tcl out of Sun in late 1997, which feels like the timeline when Sun was turning to Java.

I think there was internal politicking at Sun going on too, where JOs departure wasn’t necessarily “coincidentally” when Sun was turning to Java.

Re: The Birth of Tcl

#75

Post by bch »

rcurry wrote: post #54
jgrahamc wrote: post #29

Earlier quoted context omitted.

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.…

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.

Argonne National leaned heavily on Tcl relatively recently for a petascale super-computer project of theirs[0] (I was introduced to it by Justin Wozniak of Argonne at a Tcl conference in Manassas).

[0] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf

Re: The Birth of Tcl

#76

Post by shaunxcode »

jecel wrote: post #67
AceJohnny2 wrote: post #27

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 ". Ousterh…

I only watched this from the outside, but my impression was that it was an overreaction. Sun had a nice research operating system based on Java called SpringOS, but when clients heard about that they revolted. The transition from SunOS to Solaris had been traumatic and they threatened to jump ship if there would be any more changes ahead. Sun's reaction was to adopt "only Sparc, only Solaris, only Java forever and ev…

to be fair to sun and Self at least a lot of the research was rolled into the hotspot stuff!

Re: The Birth of Tcl

#77

Post by rudasn »

bitwize wrote: post #50
rudasn wrote: post #20

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.

Eggdrop!

Yes! Haha completely forgot about that.

And the hosting provider was called Dungeons something.. Very dodgy looking website, dad needed a little convincing to give them his CC info

Re: The Birth of Tcl

#78

Post by jrapdx3 »

bitwize wrote: post #71
jrapdx3 wrote: post #47

Earlier quoted context omitted.

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 th…

Ah, so Tcl's rules are dynamic scoping with extra steps. No wonder they're so mind-boggling. Lexical scoping is the most straightforward, least surprising scoping strategy I've seen. With lexical closures it allows for some tremendously powerful constructs.

True, lexical scoping is dominant in current programming languages and it is easier to reason about.

Alas Tcl is more complicated. It's sort of dynamic but not quite depending on how variables are accessed. For one thing a proc definition provides a separate scope from the global variable scope. If we define:

    set b 5 ;# global
    proc w {a} {
      # upvar 1 b b
      + $a $b ;# "can't read 'b': no such variable"
    }
    proc x {} {
        set b 2 ;# local
        w 0
    }
    x ;# error re: no such variable 'b'
If it was truly dynamic (or more correctly indefinite) scope, we'd see '2' printed because 'b' would be readable in procedure w, but instead we get an error. However if inside the procs '::b' was used instead of 'b', then 2 is printed consistent with dynamic scope. ('::b' is 'b' in the global namespace.)

Of course the call to w in x doesn't operate under lexical scope since procedures are global and can't access variables inside another procedure's scope.

It is possible under some conditions to mimic lexical scope using the upvar command. In the case of proc w, uncommenting the upvar call would reference var b in the calling proc (or stack frame).

Wow, written out that is kinda "mind-boggling"! But in practice it's not a problem keeping it straight, at least most of the time...

Re: The Birth of Tcl

#79

Post by moomin »

It may be something of a specialised tool now, but in the 90s it’s hard to express how far ahead of the curve the TCL ecosystem was from anyone else. I remember people looking offended at how fast you could slap together a UI compared to the C/C++ nonsense they were used to. Expect redefined the game for all sorts of scripting.

Re: The Birth of Tcl

#80

Post by johnisgood »

johnisgood wrote: post #46
7thaccount wrote: post #44

Earlier quoted context omitted.

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.

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…

So I just dived in to the Rebol cookbook myself, and I came across Rebol 3 implementations of some of the goodies from there that are originally written in Rebol. For example I stumbled upon https://zolk3ri.name/cgit/rebol-cr-auth/ and https://gist.github.com/gchiu/5288312. They are both quite cool. It truly does make me love Rebol even more!
Post reply on HN