So has why ever identified who that guy with the microphone is? Whenever there’s a new episode of “The Least Surprised” and I see him, he reminds me of Ben Stein.

We don’t know much, but we do know his name: Malsky

Is it just me, or are the greens getting darker?

You know, back in my TCL salad days, we used TCL -built DSLs for practically everything.

This turned out to be a really bad idea. A sea of turing-complete data files isn’t a fate I’d wish on anyone.

However, this time things are better.

Here’s one thing: we’ve got XML and (more importantly) YAML . People do up their plain-jane data in those, and generally save the Ruby DSLs for the things that really need it.

Also, Ruby doesn’t suck.

PH&N

PH&N

Gah. Sorry aobut the double post, people.

Hey Mental, eater of TCL salad – any point in an aspiring young progg’er learning TCL nowadays? I know C/C++, ruby, perl, python, bash, Makefile, some awk, etc., just wondering if my UNIX breadbasket is incomplete without knowledge of tcl.

I had to learn TCL to do some maintainence programming for my job about 5 years ago. I don’t know if 5 years ago counts as “nowadays”. But either way, don’t worry. If you know all those others, you can learn TCL in a day.

phred, you may want to save your soul from the TCL quoting hell.

Except to understand the historic background of the insult “scripting language”, you don’t want to dilute your brain with this stuff.

Lyle, he always reminds me (in terms of appearance) of Corrado ‘Junior’ Soprano

Of course I’m pretty sure why doesn’t intentionally put Mafia connections into his cartoons.

Thanks. I’m taking my tcl book to the trash immediately.

Yeah … I mean, TCL isn’t a bad skill to have I guess. It’s a rare skill and it’s how I got my current job.

But the language really will drive you mad if you have to use it for anything serious—it’s a Bizzaro-world language, a bit like lisp with all the good parts taken out.

Chiefly:

1. TCL has no pass-by-reference—instead, you are expected to count up through the call frames on the stack and twiddle with the caller’s local variables (upvar). Or autogenerate a bunch of global procedures or variables with unique names.
2. TCL has no closures—again, you’re expected to count stack frames and twiddle with the caller’s local variables (uplevel).
3. TCL has little syntax— TCL is so context-dependant that the parser is totally married to the interpreter. You can’t (in the general case) parse a TCL program without running it.
4. TCL has byzantine quoting rules—”well-formedness” means that your program is properly quoted, not that your program will atually prove to be syntactically correct when you try to run it.

So, um. Yeah. It seems like a really sweet language at first (especially with uplevel giving you something that feels a bit like Ruby blocks), but once you start using it heavily feels it begins to feel just a bit more and more like a distant cousin to Brainf*ck or Intercal.

There is one aspect of TCL which totally rocks though: built-in event-based IO. I have yet to see any language get that like TCL does, let alone as part of a language’s standard IO abstraction.

Anyway, that’s enough TCL bashing for, like, forever.

Y’all know of any good event-based IO stuff out there for Ruby yet?

Yes, avoid TCL at all costs. If you want to learn something new, learn Io.

(MenTaLguY: do you happen to work in EDA or something? That’s about the only place I’ve run into TCL regularly)

Oh, and who IS that Malsky guy, anyway? He does seem familiar.

Yeah, as a matter of fact I do. It’s funny… I got my degree in graphic design and then ended up doing programming and system administration at an engineering firm. Dad’s an EE, though; I guess it’s in the blood.

MenTaLguY: I did exactly the opposite. Started off doing comp science then sysadmin, now have a degree in graphic design.

And my dad’s also an EE.

Heh, wild.

Any other permutations-out-there-with-a-family-history-of-EE?

Mentalguy: This might sound stupid, but why not use ruby in the EDA world? Pros/Cons?

By the way, also family history(dad) a EE

More DSL ’s mean: 1) Divide and Conquer 2) Specialization is for insects 3) I know one less language

TheDood: I’ve been working periodically on Ruby EDA things. I think Ruby is a great fit in the EDA realm.

My dad is not an EE - he’s a marine biologist (among other things…). I am an EE who went the software way.

My many-times-great grandparents used to exclaim ‘EE’ when they’d find a bunch of bananas. Does that count?

One good thing Tcl has, which AFAIK is still less complete in Ruby is Expect. Caveats about quoting still stand. So if I find a magic lamp among the rubies, I’ll rub it and ask for a very Ruby-esque GUI (as Tk is for Tcl, and Fox is for C++, but with ruby’s dynamic nature), and I’ll ask for a ruby-esque expect which handles many processes well. Of course, not being on the busy Ruby-Talk these days I’ve probably missed something.

TheDood: The main reason is that none of the EDA vendors are using Ruby yet, whereas some EDA products are even written more or less entirely in TCL .

Another difficulty is that Ruby is comparatively painful to build on some OSes (e.g. HP-UX).

MenTaLguY: Not that anyone still uses HP-UX (well, there are probably still a couple of people out there using it, I’m sure…). If my memory serves correctly, nothing builds well on HP-UX. The first thing to do is to install the gnu tools on an HP-UX box to fix that ;-)

Strange how this has devolved into a discussion on Ruby in EDA . I really want to do something in the EDA space with Ruby – I’ve been working on the next version of RHDL which will hopefully be ready soon. After that I’m starting to work on Inline::VHDL. Let’s start some sort of RubyEDA forum somewhere to discuss further.

I first thought that was Dalai Lama.

No, hey, please. Offtopic is a core mission statement of this blog. Especially since so many of you have the EE blood type. I insist.

pHiL: Yeah. My point was just that, from experience, it’s about an order of magnitude easier to build TCL on HP-UX than it is to build Ruby there.

Tcl has some nice points besides event-driven IO in the core, which is a cool feature btw.

Feature 1: Stable. You can load and run seven year old binary extensions written for Tcl 8.1 into recent Tcl cores 8.5a4 without any recompiling.

Feature 2: Cross Platform, Tcl builds well on very many platforms, someone claimed even more then run Java. (see for a list of single file no installation needed prebuilt binaries the download matrix)

Feature 3: Regular syntax The syntax is so simple you actually have to unlearn stuff from your C experience to get it. There are no exceptions.

Feature 4: Stable Unicode and encoding support. I don’t know of any other language besides java that has such a nice and easy to use unicode and encoding layer built into the core. No troubles with encodings anymore, its all unicode…, even the regexp engine.

Feature 5: Safe Interpreters You can create multiple interpreters to create boundaries between unsafe user or plugin code and application code trivially and provide highly configurable policies whats acceptable and what is not, quite similar to Java sandboxes

Feature 6: Virtual Filesystem support The Tcl core supports a virtual filesystem layer, so you can implement or use a lot of stuff like dbs, web servers, the interpreter itself like a filesystem and even hook those vfs to the OS with something like Fuse on Linux.

Your right that some of the nice features of LISP are missing. Pass by reference is not needed, and you really never need an upvar to go either to the parent callframe or the global level, unless you write an object system or do tricks with new control structures. Closures are discussed, but no current solution is deemed ‘good enough’, as C extensions would be left out in the rain (as in Ruby AFAIK ).

Your right that syntax checking for Tcl is hard, because any command has full flexibility what to do with its argument (i think one could implement most of Ruby in Tcl because of this). So you have to use tests (btw. a nice test framework tcltest ships with the tcl core) and something like static syntax checkers, which exist.

Ruby is a fine language, but bashing Tcl doesn’t make it any better.

quoting hell? I suppose the person with that problem was following some bad advice, or didn’t understand the syntax rules. You’re supposed to use list operations when constructing dynamic commands.

Here’s a practical example of quoting hell that comes from misunderstanding:

% set badcmd “puts \”hello blah\”\”“

puts “hello blah”“

% eval $badcmd

extra characters after close-quote

This would be the proper way to construct the command:

% set goodcmd [list puts "hello blah\""]

puts {hello blah”}

% eval $goodcmd

hello blah”

Another good way of constructing dynamic commands is this:

% set anothergoodcmd [list puts]

puts

% lappend anothergoodcmd “hello blah\”“

puts {hello blah”}

It helps to remember that Tcl lists will shimmer back and forth from lists to strings automatically. For example the ‘puts {hello blah”}’ is a string representation of the list of Tcl_Objs that form that list. Any characters can also be used in a Tcl list, such as { and }. So there really aren’t the serious problems with Tcl’s syntax that I feel were brought up here.

Schlenk, george: Great to hear from both of you. Very informative stuff.