A Tcl strength
Christopher Nelson
For example, programming languages and applications are
usually written by different people, and this is responsible
for a lot of the worst flaws in programming languages. I
think every language should be designed simultaneously
with a large application written in it, the way C was with
Unix.
It occurs to me that this may be a source of Tcl's strength. Dr. O.
wrote it not as an academic exercise but hand-in-hand with the
development of the ECAD tools it was meant to automate.
Jonathan Bromley
<cne...@nycap.rr.com> wrote:
>It occurs to me that this
[concurrent development of the language and its applications]
> may be a source of Tcl's strength. Dr. O.
>wrote it not as an academic exercise but hand-in-hand with the
>development of the ECAD tools it was meant to automate.
And, be it noted, Tcl is now utterly ubiquitous in exactly that field.
I worry about ECAD (now more commonly called EDA) tools for a
living, and I can think of only one really important mainstream tool
that does NOT use Tcl as a scripting language. Many tools also
have alternative scripting languages for historical or other
reasons, but if you know Tcl you can script electronics design tools.
However, that's not the whole story. Tcl's infinite extensibility
proves to be its downfall in some places (at least for geriatrics
like me whose memory is a little flaky). In a regular Tclsh,
try
llength [info commands]
and you'll get 86 or thereabouts. Now, given a certain well-known
digital simulator's Tcl console in its most up-to-date version, I get
900 in the command line version and 2169 in the GUI version.
Go figure :-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
suchenwi
Jonathan Bromley schrieb:
> However, that's not the whole story. Tcl's infinite extensibility
> proves to be its downfall in some places (at least for geriatrics
> like me whose memory is a little flaky). In a regular Tclsh,
> try
> llength [info commands]
> and you'll get 86 or thereabouts. Now, given a certain well-known
> digital simulator's Tcl console in its most up-to-date version, I get
> 900 in the command line version and 2169 in the GUI version.
I'm not sure whether that richness in commands is more an asset or more
a liability. The chances of confusing two, or never being aware that
one exists, are much greater with that kind of overengineering :)
I like Tcl most because one can greatly simplify the solutions to the
problems at hand, ideally "do almost nothing yet get the work done" :
- less lines of code
- less variables
- less procedures/commands
But of course, Tcl/Tk are many things to many users, and that is a good
thing of course.
Michael Schlenker
> On 11 Aug 2006 06:01:48 -0700, "Christopher Nelson"
> <cne...@nycap.rr.com> wrote:
>
>>It occurs to me that this
> [concurrent development of the language and its applications]
>>may be a source of Tcl's strength. Dr. O.
>>wrote it not as an academic exercise but hand-in-hand with the
>>development of the ECAD tools it was meant to automate.
>
> And, be it noted, Tcl is now utterly ubiquitous in exactly that field.
> I worry about ECAD (now more commonly called EDA) tools for a
> living, and I can think of only one really important mainstream tool
> that does NOT use Tcl as a scripting language. Many tools also
> have alternative scripting languages for historical or other
> reasons, but if you know Tcl you can script electronics design tools.
>
> However, that's not the whole story. Tcl's infinite extensibility
> proves to be its downfall in some places (at least for geriatrics
> like me whose memory is a little flaky). In a regular Tclsh,
> try
> llength [info commands]
> and you'll get 86 or thereabouts. Now, given a certain well-known
> digital simulator's Tcl console in its most up-to-date version, I get
> 900 in the command line version and 2169 in the GUI version.
> Go figure :-)
private or public commands, so llength [info commands] will give you all
the implementation details too, unless namespaces are used to hide'em.
And event that number is misleading for the frequent ensemble style
commands..., what should [string] be counted? as a single command or
should all variants like [string is] [string length] etc. be counted...
So looks more like either bad api design, a very complex product that
needs a huge api or simply the wrong measurement.
Michael
Jonathan Bromley
<sch...@uni-oldenburg.de> wrote:
>> llength [info commands]
>> Now, given a certain well-known
>> digital simulator's Tcl console in its most up-to-date version, I get
>> 900 in the command line version and 2169 in the GUI version.
>> Go figure :-)
>Which is a bit misleading, as Tcl does not really have a concept of
>private or public commands, so llength [info commands] will give you all
>the implementation details too, unless namespaces are used to hide'em.
>
>So looks more like either bad api design, a very complex product that
>needs a huge api or simply the wrong measurement.
Well... it *is* a very complex product. And, to be fair to it, the
twenty or so commands that users normally need for typical
scripting tasks are *very* well documented. I just wanted to
make the point that knowing Tcl is sometimes not enough :-)
Yes, it was the wrong measurement. Doesn't stop it being
fun, though.
Michael Schlenker
> On Fri, 11 Aug 2006 16:07:36 +0200, Michael Schlenker
> <sch...@uni-oldenburg.de> wrote:
>
>
>>> llength [info commands]
>>>Now, given a certain well-known
>>>digital simulator's Tcl console in its most up-to-date version, I get
>>>900 in the command line version and 2169 in the GUI version.
>>>Go figure :-)
>>Which is a bit misleading, as Tcl does not really have a concept of
>>private or public commands, so llength [info commands] will give you all
>>the implementation details too, unless namespaces are used to hide'em.
>>
>>So looks more like either bad api design, a very complex product that
>>needs a huge api or simply the wrong measurement.
>
> Well... it *is* a very complex product. And, to be fair to it, the
> twenty or so commands that users normally need for typical
> scripting tasks are *very* well documented. I just wanted to
> make the point that knowing Tcl is sometimes not enough :-)
Sure. Quite similar to a having a java or .net programmer that does only
know the core language, but none of the libraries..., just not as bad,
as the Tcl core language is more powerful.
Michael
MH
Which is why a firm I may or may not be familiar with is taking a slightly
different tack, and adding modular/object-based commands to their EDA
product using Itcl.
It remains to be seen whether or not users like it, but hopefully it will
alleviate the [info commands] problem the tool you mentioned faces.
MH