Re: [tlug] Alternatives to sed + awk

[Alexander Danilov <alexander.a.danilov@example.com>]

2011/3/9 Stephen J. Turnbull <stephen@example.com>

Alexander Danilov writes:
 > 2011/3/4 Stephen J. Turnbull <stephen@example.com>
 >
 > > Alexander Danilov writes:
 > >
 > >  > Tcl - very simple syntax (11 rules), very powerfull language.
 > >
 > > I know nothing about Tcl except that MacPorts's port is written in it.
 > >
 >
 > It may be interesting for you to know that a lot of files from /etc
 > directory can be loaded into tclsh as Tcl scripts using standard
 > Tcl command "source".

Actually, "a lot" is uninteresting, because determining which is which
requires inspecting whole scripts.  "All" would be interesting.

As far as simple syntax goes, nothing beats Brainf!ck, of course, but
Scheme comes close and Lisp isn't far behind.  The problem is that to

Brainfuck is unreadable. Tcl is readable. It is possible to load any fiction book into
Tcl interpreted, you should just need to know what would you like to with this bookю
 

implement simple syntax, you need a lot of polymorphism, which pushes
the complexity into the details of the functions ("commands", in Tcl
lingo).  In the case of Lisp, this is good, because the sacrifice in
clarity is limited by strong (though dynamic) typing, and more than
offset for many programmers and many purposes by the power of the
"code is executable data" model.  Ie, the syntax of Lisp code is the
same as the syntax of Lisp data, and therefore you can write program-
writing programs.  In fact, this is a fundamental part of all modern
Lisp implementations, because that is precisely what defmacro (in
Scheme, define-syntax) do.

Lisp in not a competitor for Tcl not in GUI, not in network programming, not in strong typing domain, may be somewhere else,
but not in everyday tasks.
Lisp is different, than Tcl, but I don't see any big advantages of Lisp over Tcl.
Haskell is competitor, but not Lisp.

 

In Tcl, however, you have very weak typing.  Everything at Tcl command
level is a string, so that

      For example, the commands
             set a 3
             set b {$a + 2}
             expr $b*4
      return 11, not a multiple of 4.  This is because the Tcl parser
      will first substitute $a + 2 for the variable b, then the expr
      command will evaluate the _expression_ $a + 2*4.

It is not weakness of Tcl, it's just consequence of one of 11 rules of languges.
 

(From expr(n).)  Ie, it's basically a macro language, like TeX or m4.
This is well-known to be a trap, a prolific source of bugs.  This is
justified in the case of TeX which processes mostly free-form text,
and the result in the case of m4 is that it's basically used only to
develop autoconf.  More functional approaches to string processing
(Icon, SNOBOL) have also failed to achieve widespread application,
despite the apparent applicability to, say, web development, with the
universal use of H*Text*ML for driving browsers.  I think there's a
lesson here.

If Tcl works for you, fine.  Use it and be productive.  There's
nothing wrong with that.

But pretty much everything out there is Turing-complete (Steve Baur
once wrote a complete BASIC interpreter in Bourne shell), so it's not
clear what "powerful" means.  And it's not a well-designed language
IMHO, and, as I wrote before, the only application written in Tcl that
I care about is an embarrassment to all concerned.  (And in fact the
core dependency analysis functions are written in C because (a) it
runs much faster and (b) it's far easier to write and debug in C -- a
damning statement if I ever heard one!)

Tcl is not well designed language,