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

Tcl the misunderstood (2006)

antirez.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Tcl the misunderstood (2006)

#31

Post by j45 »

vog wrote: post #23
j45 wrote: post #12

Tcl is certainly not a toy language. I was introduced to it when running an eggdrop bot in the irc days, and I suspect for many of us was one of the first more feature complete languages we had no choice but to learn because we wanted to add custom functionality to our bots. I haven't kept up with it and enjoyed seeing there's still those who find it productive

Well, back in those days (around 1998-2002), when I was a kid at school, Eggdrop bots were a bit slow, which often became an important factor on channel wars: channel overtakes, net splits, and so on. So we (some friends and me) created our own bot (with a very simple DSL) just for fun in pure C, and it was very fast ( http://davis.sourceforge.net/ ). Of course, our DSL was never as well designed as Tcl.

Haha! I didn't get much into channel wars, diplomacy got a lot further when there was always legit bandwidth kicking around.

Tcl in some ways was the cause of, and solution to a lot of problems on IRC.. I ended up becoming friends with some of the people who'd try to takeover a channel I might be in and we'd realize we had more in common than not, such as how to customize those damn bots. Still have some of those friends years later, and I'm not sure if I'm the only one. Tcl feel good story.

Re: Tcl the misunderstood (2006)

#32

Post by sliverstorm »

Spooky23 wrote: post #5

I agree with the sentiment, but who is actually claiming that TCL is a toy language? Random uninformed people on Reddit opine about all sorts of stuff. It is an old language with lots of cruft, but it's been used in all sorts of places for something like 25 years. Perhaps people's experiences with the language are colored by using it as a means to customize behavior in some big hairy enterprise app.

I don't love TCL, but "toy language" is frankly a comical representation. At least from what I see, it's practically the exact opposite. Nobody I know uses TCL because they like it or because it is fun; they use it because they must, to get work done (to control big hairy enterprise software).

Re: Tcl the misunderstood (2006)

#33

Post by j45 »

muppetman wrote: post #25
j45 wrote: post #12

Tcl is certainly not a toy language. I was introduced to it when running an eggdrop bot in the irc days, and I suspect for many of us was one of the first more feature complete languages we had no choice but to learn because we wanted to add custom functionality to our bots. I haven't kept up with it and enjoyed seeing there's still those who find it productive

I still have an eggdrop. Uptime nearly 200 days!

Respect! I feel like firing up mIRC but I don't have windows nor the patience to fire up my vm :P

Re: Tcl the misunderstood (2006)

#34

Post by mst »

fuzzix wrote: post #14
binarymax wrote: post #11

Earlier quoted context omitted.

I don't understand the purpose of your comment. OK so perl is great. This article isn't about Perl...it's about the semi-obscure and commonly underestimated Tcl (which is also a great language).

To state the problem explicitly, internal storage format of strings doesn't mean you can handle all data streams seamlessly. Internal consistency is fine, but ultimately your program will have I/O. If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled? Does it seamlessly detect encoding and translate to UTF-8 or is there more to this issue than what's stated in the article? Also, are the string…

This article is from 2006.

Perl's unicode support is excellent now. In 2006 5.10 wasn't out yet, and anything before 5.8.5 had all sorts of odd unicode bugs.

Or: Tcl got there significantly before we did.

Re: Tcl the misunderstood (2006)

#35

Post by VMG »

I came away from this impressed, but still thinking that it is a "toy language" in the sense that it is too powerful. You sometimes do not want to have to worry what a line of code means, and TCL does not allow that.

> The Tcl community developed a number of OOP systems, radical language modifications, macro systems, and many other interesting things, just writing Tcl programs

Well there's your problem. It becomes impossible to learn the language as a whole, because it is so flexible and everybody does things differently.

Re: Tcl the misunderstood (2006)

#36

Post by gjm11 »

gjm11 wrote: post #15
arnsholt wrote: post #6

An interesting corollary to concept 5 (the fact that everything in Tcl is a string) is that this means that Tcl is actually homoiconic. It does it completely differently from Lisp, but still ends up in the same place: code and data have the same representation.

You can represent arbitrary C++ code as a string, too, and C++ has a fairly decent string type. Does that make C++ homoiconic? I wouldn't say so, because the structure of the code is lost when you represent it as a string and because C++ doesn't give you any way of using the code represented thus (e.g., there's no standard way to compile it). (The second of those isn't strictly part of what's meant by homoiconicity.…

Hi, downvoters! Would you care to tell me what you disliked about my comment, and thereby help me do better in future? (Or allow me to defend myself if I don't see what you disliked as a fault.)

I should maybe clarify one point: I was not saying that Tcl isn't homoiconic (which is, e.g., why I said "Tcl may be homoiconic"). Only that the mere fact of representing everything as a string doesn't make it homoiconic.

Re: Tcl the misunderstood (2006)

#37

Post by beefhash »

VMG wrote: post #35

I came away from this impressed, but still thinking that it is a "toy language" in the sense that it is too powerful. You sometimes do not want to have to worry what a line of code means, and TCL does not allow that. > The Tcl community developed a number of OOP systems, radical language modifications, macro systems, and many other interesting things, just writing Tcl programs Well there's your problem. It becomes im…

You call that a "problem". C++ developers make money with that every day.

Re: Tcl the misunderstood (2006)

#38

Post by lilyball »

sliverstorm wrote: post #32
Spooky23 wrote: post #5

I agree with the sentiment, but who is actually claiming that TCL is a toy language? Random uninformed people on Reddit opine about all sorts of stuff. It is an old language with lots of cruft, but it's been used in all sorts of places for something like 25 years. Perhaps people's experiences with the language are colored by using it as a means to customize behavior in some big hairy enterprise app.

I don't love TCL, but "toy language" is frankly a comical representation. At least from what I see, it's practically the exact opposite. Nobody I know uses TCL because they like it or because it is fun; they use it because they must , to get work done (to control big hairy enterprise software).

> Nobody I know uses TCL because they like it or because it is fun

I haven't written TCL in a few years, but back when I did (when I worked on MacPorts) I actually did think it was fun.

Re: Tcl the misunderstood (2006)

#40

Post by fuzzix »

mst wrote: post #34
fuzzix wrote: post #14

Earlier quoted context omitted.

To state the problem explicitly, internal storage format of strings doesn't mean you can handle all data streams seamlessly. Internal consistency is fine, but ultimately your program will have I/O. If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled? Does it seamlessly detect encoding and translate to UTF-8 or is there more to this issue than what's stated in the article? Also, are the string…

This article is from 2006. Perl's unicode support is excellent now. In 2006 5.10 wasn't out yet, and anything before 5.8.5 had all sorts of odd unicode bugs. Or: Tcl got there significantly before we did.

That is a fair point, but I'm not trying argue that Perl is somehow better. I am just using it as a reference point. I'm more suggesting the article may be overstating the ease-of-use / capabilities of Tcl.

To be clear, I'm not arguing against using Tcl in favour of Perl or anything else. It's just that my experience with a language with great encoding support doesn't jive with what's claimed here.

Post reply on HN