tcl's future, opinion xpost from redhat.development
Bruce Edge
$.02?
> I suggest that you program in Tcl/Tk some before you commit to it. I
> appreciate Tcl for modifying my views of what a language can be, but I
> will probably not willingly write Tcl ever again. Its syntax is, in a
> word, bizarre. Not as bizarre as the Lisp family, but it definitely
> gets in your way: my personal opinion is that the only reason Tcl has
> survived this long was Tk.
>
> Now that we have things like Python/Tkinter and GTK+, Tcl should
> hopefully begin to slide into obscurity.
>
--
Bruce Edge be...@sattel.com
Sattel Global Networks 818.709.6201 x122
cm...@my-deja.com
In article <385927AB...@sattel.com>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Cameron Laird
In article <385927AB...@sattel.com>,
Bruce Edge <be...@sattel.com> wrote:
>Just to hear a different side of the story, would anyone care to throw in
>$.02?
>
>> I suggest that you program in Tcl/Tk some before you commit to it. I
>> appreciate Tcl for modifying my views of what a language can be, but I
>> will probably not willingly write Tcl ever again. Its syntax is, in a
>> word, bizarre. Not as bizarre as the Lisp family, but it definitely
>> gets in your way: my personal opinion is that the only reason Tcl has
>> survived this long was Tk.
>>
>> Now that we have things like Python/Tkinter and GTK+, Tcl should
>> hopefully begin to slide into obscurity.
.
.
What is "redhat.development"? I've not been able to locate
a netnews group with that name on any of the NNTPSERVERs I
know.
I agree with the praxis of the excerpt above. There is wis-
dom in experimenting with a tool before committing to it. It
benefits no one for a working programmer to spend his days
feeling oppressed and constrained by a syntax he or she finds
bizarre.
I recognize the facts supporting the "personal opinion ...
that the only reason Tcl has survived this long ..." I can
make a strong case to the contrary, certainly at the mundane
level that starts with Expect's standing.
It seems the author hopes Tcl will "begin to slide into
obscurity." I trust that he is telling the truth about his
own sentiments.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Scott Redman
for me to use, coming from a strong C/C++ background. Tcl works really
well for integrating systems (a glue language). It works really
well to combine different pieces of C, C++, or Java (and a few
other languages) together. Almost all EDA companies ship their
software with a Tcl interpreter (Synopsys, Cadence, Mentor, Altera,
etc.), only a few of them use Tk.
Tkinter uses Tcl to display Tk GUIs in Python...so it will probably
be slower than straight Tcl/Tk, or maybe it might be more confusing
than using Tk with Tcl. Python is has significant leading white space,
the amount of indentation of a line is significant...yuk, talk about
bizarre syntax (IMHO)! GTK+ is a C++ class library (there is a C
equivalent as well), and if you want to use C/C++ that might be the
way to go, but only if you want the program to run on Unix. If you
want cross-platform GUIs, Tcl/Tk is a better choice. The WinNT port
of GTK is a long way from being stable. You might also consider
using Java's Swing in combination with Tcl and TclBlend to combine
your backend C/C++ code with a Java-based GUI. Personally, I think
Tk is a better choice, though.
-- Scott
Bruce Edge wrote:
>
> Just to hear a different side of the story, would anyone care to throw in
> $.02?
>
> > I suggest that you program in Tcl/Tk some before you commit to it. I
> > appreciate Tcl for modifying my views of what a language can be, but I
> > will probably not willingly write Tcl ever again. Its syntax is, in a
> > word, bizarre. Not as bizarre as the Lisp family, but it definitely
> > gets in your way: my personal opinion is that the only reason Tcl has
> > survived this long was Tk.
> >
> > Now that we have things like Python/Tkinter and GTK+, Tcl should
> > hopefully begin to slide into obscurity.
> >
>
Bruce Edge
>
> .
> What is "redhat.development"? I've not been able to locate
> a netnews group with that name on any of the NNTPSERVERs I
> know.
>
Charlie
> software with a Tcl interpreter (Synopsys, Cadence, Mentor, Altera,
> etc.), only a few of them use Tk
EDA = ?
Jeffrey Hobbs
Electronic Design Automation. Often affiliated with CAD -
Computer Aided Design.
--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.
Christopher Nelson
>
> Charlie wrote:
> > > other languages) together. Almost all EDA companies ship their
> > > software with a Tcl interpreter (Synopsys, Cadence, Mentor, Altera,
> > > etc.), only a few of them use Tk
> >
> > EDA = ?
>
> Electronic Design Automation. Often affiliated with CAD -
> Computer Aided Design.
I know what EDA is and even I found that description lacking. ;-) To be
completely clear (I hope), EDA is the automation of electronic design,
not the electronic automation of design. Sometimes also called E-CAD,
it is CAD tools for designing and verifying semiconductor chips.
Chris
--
Author: Tcl/Tk Programmer's Reference
http://www.purl.org/net/TclTkProgRef
Harald Kirsch
> > I suggest that you program in Tcl/Tk some before you commit to it. I
> > appreciate Tcl for modifying my views of what a language can be, but I
> > will probably not willingly write Tcl ever again. Its syntax is, in a
> > word, bizarre. Not as bizarre as the Lisp family, but it definitely
Whoever wrote that didn't read `man Tcl' carefully enough and didn't
understand that Tcl's syntax is mostly harmless.
Harald Kirsch
--
---------------------+---------------------------------------------
Harald Kirsch (@home)| Don't like `make' ?
k...@iitb.fhg.de | Use http://wsd.iitb.fhg.de/~kir/brashome/
Maurice Diamantini
wrote:
>>> Now that we have things like Python/Tkinter and GTK+, Tcl should
>>> hopefully begin to slide into obscurity.
I like tcl since years ago, and I hope to use it for years in
the future!
But I think that TCL should reacts by better support of C++ and
OOP in general (megawidget support could be a start).
And about the future new "list_array_dictionnary" command: why not
a command like a widget?
Instead of:
dictionnary_append $myDico <args>
I'd prefere something like:
$mydico append <args>
--
Maurice.D...@ensta.fr - ENSTA/LMA
École Nationale Supérieure de Techniques Avancées
Laboratoire de Mathématiques Appliquées
http://www.ensta.fr/uer/uma/math_app.html
Cris A. Fugate
>
> Just to hear a different side of the story, would anyone care to throw in
> $.02?
>
> > appreciate Tcl for modifying my views of what a language can be, but I
> > will probably not willingly write Tcl ever again. Its syntax is, in a
> > word, bizarre. Not as bizarre as the Lisp family, but it definitely
> > survived this long was Tk.
> >
> > hopefully begin to slide into obscurity.
> >
>
Personally, I love Tcl. Of course I also like Scheme and Forth.
If Tk did not exist I would still use Tcl because it is such
a simple and flexible language. Also, it doesn't force OOP
down my throat so I can use other paradigms such as frames
for which reason I wrote framesets (see http://home.att.net/~cafugate).
Merry Christmas
Cris A. Fugate
cafu...@worldnet.att.net
Cristiano Novello
> I think this was the author's personal opinion. Tcl was very natural
> for me to use, coming from a strong C/C++ background. Tcl works really
> well for integrating systems (a glue language). It works really
> well to combine different pieces of C, C++, or Java (and a few
> other languages) together. Almost all EDA companies ship their
> software with a Tcl interpreter (Synopsys, Cadence, Mentor, Altera,
> etc.), only a few of them use Tk.
>
Scott is right when he says that almost all EDA companies ship their software
with a bundled Tcl interpreter. And I can say this is *maybe* good.
At least this saves us from learning N "shell languages" for each of the N
different
EDA tools we have on the market.
But this fact doesn't demonstrate anything about how good a language is.
The user of this EDA tools is only marginally touched by the deep, philosophic
toughts (i.e. religion wars) about which language is better and why.
(Sometimes) S/He needs some scripting language to easily automate boring and
repetitive task. S/He does not need nor wants to learn another fully fledged
language
(VHDL and Verilog are enough for the time being) to do their main task:
designing circuits!
A designer needs *fast*, standard-compliant, easy-to-use, no-frills,
easy-integrable
tools. And I do not think that filling the package with a Tcl interpreter is
doing the job.
I feel that having the "Tcl inside" sticker on the pack is fashonable
nowadays:
usefulness is another story.
Outside the EDA arena, I use(d) Tcl/Tk to write simple wraparound
scripts/gui's but
I prefer to move to other languages when the task is more complicated
(for a number of reasons that guys much more experienced than me already
outlined
in many docs on the Net).
Cristiano
PS
Obviously, this is my own private thought, not necessarily shared by
Infineon Techologies ;-).
=================--------------------------------- _|_|_|_|_|_|_|_ =
Cristiano NOVELLO (EZM VI - 6218 ) -| more fun, |-
cristianoDOTnovelloATinfineonDOTcom -|___less VLSI___|-
=================--------------------------------- | | | | | | | =
Bruce Edge
I've spent the last few days evaluating tcl on QNX and I can see
the value of such a tool.
The only complaint I have is that I miss the readline style input
editing commands. I saw tclreadline, but my platform doesn't
support shared libs, so I can't use it.
Aside from that, I think I'll be using my Perl and bash manuals as
coasters from now on.
Please forgive the helpless rookie questions while I get up to speed.
Thanks to all who responded.
Cameron Laird
In article <385A7648...@sattel.com>,
Bruce Edge <be...@sattel.com> wrote:
.
.
.
>The only complaint I have is that I miss the readline style input
>editing commands. I saw tclreadline, but my platform doesn't
>support shared libs, so I can't use it.
.
.
It's possible to make tclreadline work statically. TkCon
<URL:http://www.hobbs.wservice.com/tcl/script/tkcon/>
might interest you even more--do you have that much in
the way of X capabilities?
Jeffrey Hobbs
> I like tcl since years ago, and I hope to use it for years in
> the future!
And I hope to be developing it for years in the future...
> But I think that TCL should reacts by better support of C++ and
> OOP in general (megawidget support could be a start).
Could you elaborate on better support for C++? There are a few
things in the plus patch, but I'm not sure what users really need.
I wanted to get megawidget support into 8.3, but alas ran out time
(or you could all wait for 8.3 a while longer...). It will be on
the hi prio list for 8.4.
Jeffrey Hobbs
> Jeffrey Hobbs wrote:
> > I wanted to get megawidget support into 8.3, but alas ran out time
> > (or you could all wait for 8.3 a while longer...). It will be on
> > the hi prio list for 8.4.
> >
>
8.3 will be more like sn.
Bruce Edge
>
> It's possible to make tclreadline work statically. TkCon
> <URL:http://www.hobbs.wservice.com/tcl/script/tkcon/>
> might interest you even more--do you have that much in
> the way of X capabilities?
> --
I'm all ears.
I have Xfree86, I just got tk 8.2.3 working on it this AM.
Minor X bug was SEGVing wish, but that's fixed now.
So, is tkcon a static link of the whole mess?
What exactly were you getting at?
Bruce Edge
>
> TkCon is a Wish script that implements the readline functionality you're
> looking for an d much, much more. It won't help you if you're always
> running from the console, though.
>
> --%
Just got it.
I still can't believe I got tk running on QNX :-)
Jeez it feels like Xmas is a week early this year.
Yesterday all I had was a mangled tcl 7.3, no tk.
and today I have tcl/tk 8.2.3 and tkcon.
Many thankyous, Bruce.
Brian
Newbie clarification question for you regarding megawidget support. Does
megawidget support mean enhancements to the core making building megawidgets
easier, or does it mean adding additional megawidgets to Tk (e.g. combox,
tree, etc.)?
Also, I know this is a known longstanding bug, a bug with Windows I believe;
is there anything that is going to be done regarding a workaround for the
CAPS light not illuminating when in CAPS Lock mode running Tcl scripts?
Thanks!
Jeffrey Hobbs <jeffre...@scriptics.com> wrote in message
news:385A7617...@scriptics.com...
> Maurice Diamantini wrote:
> > I like tcl since years ago, and I hope to use it for years in
> > the future!
>
> And I hope to be developing it for years in the future...
>
> > But I think that TCL should reacts by better support of C++ and
> > OOP in general (megawidget support could be a start).
>
> Could you elaborate on better support for C++? There are a few
> things in the plus patch, but I'm not sure what users really need.
>
> I wanted to get megawidget support into 8.3, but alas ran out time
> (or you could all wait for 8.3 a while longer...). It will be on
> the hi prio list for 8.4.
>
Jeffrey Hobbs
> Newbie clarification question for you regarding megawidget support. Does
> megawidget support mean enhancements to the core making building megawidgets
> easier, or does it mean adding additional megawidgets to Tk (e.g. combox,
> tree, etc.)?
It means that Tk will have the proper internal mechanism in place
to handle true Tk-like widgets built in Tcl (not C). This includes
being able to redirect focus and the like. With the proper system
in place, you can then build megawidgets that behave as if they
were coded in C without lots of tricky work-arounds.
> Also, I know this is a known longstanding bug, a bug with Windows I believe;
> is there anything that is going to be done regarding a workaround for the
> CAPS light not illuminating when in CAPS Lock mode running Tcl scripts?
I was given some code recently that purported how to work around
this problem (note that it's a Win9* problem - it has the correct
behavior on NT). I hope to get around to this before 8.3 final.
Lab`6
> I wanted to get megawidget support into 8.3, but alas ran out time
> (or you could all wait for 8.3 a while longer...). It will be on
> the hi prio list for 8.4.
>
How much longer? Will it be sooon instead of sooooon? Or will it be son?
IOW, I can wait.
--%
Ronald Garcia
cla...@starbase.neosoft.com (Cameron Laird) writes:
>
> I recognize the facts supporting the "personal opinion ...
> that the only reason Tcl has survived this long ..." I can
> make a strong case to the contrary, certainly at the mundane
> level that starts with Expect's standing.
>
I've heard this argument -- that tcl is successful only because of tk
-- before. Actually I think Brian Kernighan made that claim in a
paper at a Usenix Tcl conference. I don't think anyone will ever be
able to prove this either way, but I know from personal experience
that I started to use Tcl originally in order to build GUI's using
Tk...now I use it for a whole lot more than that :).
At the same time, though, I think that using Expect as an argument for
Tcl seems to head in the same general direction, namely that if not
for <insert useful extension here>, Tcl would not have thrived.
A while back I saw a paper by a person who switched to Python from
[incr tcl], and his reason seemed to have more to do with the
"batteries included" aspect of Python, ie, that it came with a
critical mass of extensions that allowed a developer to do just about
anything.
So perhaps this argument seems to be an analysis of the language
syntax and semantics...ie, that maybe a Python or a perl has a
preferable syntax, or built in language features (like auto
documentation or static local variables perhaps?).
My personal opinion is that the language issues may be of greater
importance in the context of developing large scale applications.
Others have already written 100,000+ LOC tcl applications, showing
that it is in fact possible; of course, others have done the same in
Assembly language. The issue seems to be if the language
supports that scale of development. I tend to think that between
namespaces and [incr tcl], it does. But I'm not sure about the
tools outside the language that provide support, having never tried
TclPro or any other similar development tools for tcl.
On another note, most of the discussions I've seen of Tcl vs. XXX or
Tcl as a language have focused on pre-8.0 editions. Have there been
[m]any since? I'm particularly interested in 8.0+ Tcl applications
that embed the interpreter in C/C++ apps.
ron
Gerald W. Lester
> ...My personal opinion is that the language issues may be of greater
> importance in the context of developing large scale applications.
> Others have already written 100,000+ LOC tcl applications, showing
> that it is in fact possible; of course, others have done the same in
> Assembly language. The issue seems to be if the language
> supports that scale of development. I tend to think that between
> namespaces and [incr tcl], it does. But I'm not sure about the
> tools outside the language that provide support, having never tried
> TclPro or any other similar development tools for tcl.
> ...
As one whose company has a couple of large Tcl applications, I like to say
something.
Most of the large Tcl applications that I'm aware of consist of a lot of
small to medium size programs, not one massive monolithic program. This is
different than the way applications are developed in many other languages.
The reasons for the differences lay, IMHO, in the strengths and weaknesses
of the languages (pick a strength in one and it is a weakness in the
other).
Historically, in Tcl it can become difficult to manage program development
when a program starts to exceed a couple of thousands of lines. This
encourages writing of smaller programs. However, tying programs together
in Tcl is very, very easy. This leads people to start decomposing the
problem into multiple autonomous programs. IMHO, this also leads to code
reuse (the whole program, not chunks of it and a fairly natural progress
to the application being developed being able to be distributed across
platforms.
Historically, most other languages charge a very high (at least in
comparison) cost when you decompose an application into several programs
(compile/link/debug cycle, pain of IPC programming, etc). However they
offset this by making it relatively easy to create black box
modules/library and hook them together into very large programs.
With the advent of namespaces and packages, it is much easier to have
larger Tcl programs. Since I'm old enough to have done the 3GLs (hell even
the 2GLs) before Tcl (I'm not sure if Tcl is a 4GL, 5GL or just a NGL) I
can see benefits in both approaches. Lately the size of the Tcl programs
in our applications at my company have been growing along with the number
of packages and namespaces. The we, as a company, use another language (by
choice) is to write extensions for Tcl. I will admit we still have a
couple of sysadmin types who will turn first to perl or csh or ksh for
"personal" applications or for throw-away tools (I use Tcl for those
things myself).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| gerald...@mtolive-lcms.org | the man who is alive." -- Cervantes |
| Webmaster for http://www.mtolive-lcms.org |
+--------------------------------+---------------------------------------+
David Cuthbert
since I haven't written a single line of code for this, I'll just take this
opportunity to toss out my ideas.
Jeffrey Hobbs wrote:
> Could you elaborate on better support for C++? There are a few
> things in the plus patch, but I'm not sure what users really need.
Proper object types is tops on my list. Tcl_Obj is wrapped into an abstract
base, with Tcl_StringObj, Tcl_UnicodeObj, Tcl_IntObj, etc., all proper
subclasses that call the Tcl function implementation. Probably mutexes as
well. All with reference counting handled internally (and correctly!).
Wrap interpreters into a class and use function overloading rather than the
quirky variants that C imposes (e.g., Tcl_SetVar, Tcl_SetVar2,
Tcl_SetVar2Ex, Tcl_ObjSetVar2 would become interp->SetVar()).
I'd also want to make an object-oriented C++ interface into Tk, much along
the lines of the Tcl_xxxObj above but for the Tk widgets. (Seems that every
other language except C++ has this!).
Dave
David Cuthbert
> Scott is right when he says that almost all EDA companies ship their
> software with a bundled Tcl interpreter. And I can say this is *maybe*
> good. At least this saves us from learning N "shell languages" for each
> of the N different EDA tools we have on the market.
Hehe... I work for one of those EDA companies that ships an embedded Tcl
interpreter in our product. It's been interesting; there have been many
times when it has saved my butt when I'm helping one of our field
applications engineers at a customer site seven time zones and two spoken
languages away, trying to customize some aspect of our tool to integrate
with a weird tool flow.
Nobody cares that it's Tcl that we're embedded with; everybody just wants to
get the job done, and Tcl serves this purpose well.
It hasn't been perfect; we've been burned a bit, too. We just shipped a
major release with a heavily patched Tcl 8.1 to work around a number of bugs
(which could have been corrected by upgrading to 8.2, but that didn't come
out in time for us to meet our integration deadline). In retrospect, I
should have pulled 8.1 from our tool and put 8.0 in.
The major reasons we use Tcl is because it's easy to learn (when we get a
new AE, it takes about an hour to get them up to speed), has a reasonably
rich library, and isn't proprietary (like Cadence's versions of SKILL). Oh,
and almost everyone else uses it. I suspect that the EDA industry got
hooked on it simply because then-Prof. Ousterhout lead a CAD group at
Berkeley when he developed Tcl, and it just spread.
> (Sometimes) S/He needs some scripting language to easily automate boring
> and repetitive task. S/He does not need nor wants to learn another fully
> fledged language (VHDL and Verilog are enough for the time being) to do
> their main task: designing circuits!
Wrong audience. The people who use Tcl are the CAD managers, those
responsible for integrating tools from a number of vendors who refuse to
talk to each other. As far as I know, nobody uses Tcl in an everyday manner
to design circuits. (Ok, so I do. But I wrote an extension that allows me
to do this.)
> A designer needs *fast*, standard-compliant, easy-to-use, no-frills,
> easy-integrable tools.
Wrong on three counts. Nobody needs fast glue code. As long as it doesn't
cause a perceptible delay, it doesn't matter what language is used. Now, if
you're talking about writing a router, that's a different story...
As for standards compliance, ha! As ridiculous as this sounds, the EDA
industry is built on non-standards. The market is extremely small; I don't
think any vendor has the time or money to spare in standards wrangling. The
cost of switching from one tool to another is close to prohibitive (a single
user workstation license for these tools runs in the $10k-$400k/year
range). Customers don't seem to care *as long as they get the proper amount
of support from their vendors*.
Besides, if the vendors can lock you into their tool flow, they're happier.
The price is one aspect; the other is to get you to rely on their own
proprietary extensions. Hmm... doesn't this sound vaguely like a company in
Redmond? :-)
Finally, as for no-frills... why is the list of customer-requested
enhancements on my desk so large? :-)
The other two -- easy-to-use and easy-integrable -- are what the customers
really want. Ideally, they don't want to have to see a scripting language
at all; they want it to work out of the box. Barring this, they want it to
be as painless as possible (which translates to as few people-hours spent on
tool integration as possible).
> And I do not think that filling the package with a Tcl interpreter is
> doing the job.
If that's the case, then the vendor did not do a good job of integrating Tcl
into their application.
It doesn't matter *what* language you are using (or your vendor is forcing
upon you). If they don't provide the hooks to control their tool and obtain
information properly, then they haven't truly integrated the interpreter;
they've merely added a few calls to invoke the interpreter so they could
make a marketing "tick in a box". Point me to a language which will
automagically hook into our tool, and I'll switch the next version to that
language tomorrow.
If a vendor has done a good job of integrating the Tcl interpreter, then you
should be able to write a script that checks what devices are in a design,
examine their connectivity, query the process technology database for design
rules, get information on why the script was invoked (is it to call a layout
tool? route a layout? extract parasitics? etc.), and provide a means for
submitting this information back into the tool. If the core of the task
you're trying to accomplish is done elsewhere (e.g., binary executable),
well, that's what the "exec" command is for.
> I feel that having the "Tcl inside" sticker on the pack is fashonable
> nowadays:
> usefulness is another story.
Tcl is not something that causes a customer to buy an EDA tool or even to
allow an evaluation to occur at their site. Quite honestly, it's what the
vendor (or its representatives) use to work around customer-specific items
that would otherwise cause an evaluation to go sour.
Dave
lvi...@cas.org
According to Jeffrey Hobbs <jeffre...@scriptics.com>:
:I wanted to get megawidget support into 8.3, but alas ran out time
:(or you could all wait for 8.3 a while longer...). It will be on
:the hi prio list for 8.4.
I would be happy to wait for 8.3, if it resulted in good megawidget support
--
<URL: mailto:lvi...@cas.org> <URL: http://www.usenix.org/events/tcl2k/>
<*> O- <URL: http://www.purl.org/NET/lvirden/> Tcl2K - Austin, Texas, US
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
lvi...@cas.org
According to Bruce Edge <be...@sattel.com>:
:editing commands. I saw tclreadline, but my platform doesn't
Not necessarily true - it will just take a bit more work. You have
to build it statically, then create a modified version of the code
which initializes the Tcl interpreter, calling the specific tclreadline
initialization functions. This is the way that people programmed in
Tcl 'in the olden days'. I suspect that if you take a peek at
<URL: http://www.purl.org/NET/Tcl-FAQ/part4.html> you will even find
something like make-a-wish or something similar which is designed to
aid you in building a statically linked interpreter.
On the other hand, I would RUN, not walk, away from a platform which
doesn't support shared libraries, myself.
P.S. Lastly, there are some stand alone utilities (I just saw soe
reference recently on freshmeat.net) which you run as a 'wrapper' around
your program. They then provide a readline interface for ALL input
calls... The one I used to use was called ile - the name of the recent
reference slips my mind - search for readline though...
Jeffrey Hobbs
> According to Jeffrey Hobbs <jeffre...@scriptics.com>:
> :I wanted to get megawidget support into 8.3, but alas ran out time
> :(or you could all wait for 8.3 a while longer...). It will be on
> :the hi prio list for 8.4.
>
> I would be happy to wait for 8.3, if it resulted in good megawidget
> support
Hmmm, it'd be interesting to hear more opinions on this, but at
this point, it's too late to change. There always comes a time
when the features vs timeline discussions are done, and in the
timeline race, megawidgets lost, mostly because of the design time
to get it right. There were so many other things already done,
enough to justify a minor release without overloading such a
release with new features. Feather also fell out of 8.3 due to
similar reasons. Definitely a hi prio, but it just isn't ready.
I'm going to enjoy meeting Paul Duffin at Tcl'2K to hammer parts
of Feather into stability for 8.4.
Jeffrey Hobbs
>
> I've been meaning to implement C++ wrappers around Tcl for some time now;
> since I haven't written a single line of code for this, I'll just take
> this opportunity to toss out my ideas.
> Wrap interpreters into a class and use function overloading rather than
So you really want to see Tcl more structured through C++ at the
core level? This is one feature that has interesting theoretical
potential, but is unlikely to be seen in the near future.
There are many reasons why, but the dangers of cross-platform C++
are well known (it only made ANSI standards this year), whereas
Tcl's current implementation compiles on machines that may never
see a proper C++ compiler. Many are skeptical about the speed of
code output by C++ compilers, often for good reason. At the open
source conference last year, someone was seriously proposing (I
think had already started the very beginnings) or a perl code
port to C++. They were talking about what they had to restrict
themselves to to ensure it would compile most places. In the end,
it led to great snickering (never mind talking to a Perl crowd
about using C++ - even though you have to code the core in some
language, but then you have the Tcl guys rooting them on, since we
are fairly confident it will all go awry...).
Maurice Diamantini
<jeffre...@scriptics.com> wrote:
>David Cuthbert wrote:
>>
>> Wrap interpreters into a class and use function overloading
>
>So you really want to see Tcl more structured through C++ at the
>core level? This is one feature that has interesting theoretical
>potential, but is unlikely to be seen in the near future.
No, not **into** the core but as a "standard" interface **above** the
tcl core.
So tcl should compil every where it already compil, and tcl++
(core tcl with a c++ "shell" extension which would provide some class
interface in iosteam support) could compil anywhere a standard c++
compiler exists.
Instead of looking for the several more or less maintains extensions
or guidline for using tcl with c++, I'd like the tcl community (or
a "tcl + c++" specialist?) select **one** of them, and that sciptics
centralize the following:
- a standard optional c++ interface to tcl (which could be provide
in the subdirectory "tools/" tcl source distribution).
This interface could add a "tcl::interp" class and
a "tcl:obj" class to be called from c++ ; but also the "standard
tcl interface"
- a standard tcl interface for using c++ as an exemple of creating
a new user defined class from tcl interpreter (after having
loaded the tcl++ extension),
Perhaps it requires some new "new" and "delete" tcl command,
or instead, it could be better to use the "Tk" form for creating
objects?
Several years ago, there where some work done by "Vince Darley"
Here is a (know unreachtable) readme:
All I hope is that such a fonctionnality will be available from
<http://www.scriptics.com/resource/software>.
########################################################################
# start of "cpptcl2.0.README"
Cpptcl is a tool to allow simple integration of C++ objects with
Tcl (and hence Tk). It includes automatic support for Tcl argument
parsing, command completion, container classes, run-time type
information, archival of object creations, ... Cpptcl is a pair of
loadable Tcl extensions which work fine under Unix and MacOS (and
presumably other platforms too).
In order of priority, this is what Cpptcl does:
The primary purpose of Cpptcl is to allow you to write C++ code and
classes which smoothly, simply and powerfully link with the Tcl
language, and expose as much or little of their interface to Tcl as
desired (member functions and data members). Object creation,
destruction and manipulation are all supported from Tcl. Also the
C++-Tcl interface uses a lot of the powerful features of the C++
language to make your code much more straightforward than if you
were to use the standard Tcl C API. Building and manipulation of
strings, lists, evaluations,... is all possible using stream based
operators, so you can do things like:
tcl_obj t;
t << "store this string"
<< my_var
<< " which contains a C variable value";
tcl_obj tt(interp);
tt << "puts {"
<< t
<< "}"
<< eval;
A secondary goal is to allow you to take existing C++ classes and
automatically wrap them inside other 'Tcl-aware' C++ classes so
that it appears to the Tcl user as if your original class is
integrated with Tcl.
A tertiary goal is to allow you to take either of the above forms
of C++ in Tcl object functionality and wrap such an item inside an
[incr Tcl] class. This occurs at the Tcl rather than C++ level,
although needn't look any different to the user.
This package is primarily useful to Tcl/C++ code developers. Take
a look at the 'Plplot' package for an example of a package which
makes use of this code.
Yours,
Vince Darley
http://www.biosgroup.com/ http://www.fas.harvard.edu/~darley
dar...@fas.harvard.edu
# end of "cpptcl2.0.README"
########################################################################
Lab`6
>
> Brian wrote:
> > Newbie clarification question for you regarding megawidget support. Does
> > megawidget support mean enhancements to the core making building megawidgets
> > easier, or does it mean adding additional megawidgets to Tk (e.g. combox,
> > tree, etc.)?
>
> It means that Tk will have the proper internal mechanism in place
> to handle true Tk-like widgets built in Tcl (not C). This includes
> being able to redirect focus and the like. With the proper system
> in place, you can then build megawidgets that behave as if they
> were coded in C without lots of tricky work-arounds.
>
Ok. So am I the only one with an opinion on this? I can wait a while for
this (although I suspect I'm a little late -- b1 is probably coming out
today, no?). If it doesn't go into 8.3, would it be in 8.4 or in 9.0? I
suspect the first would come out much faster than the second.
Also, when do you plan on redesigning Tcl for 9.0? I expect 9.0 to be a
smaller core with loadable "components", if you will. If I remember
correctly, that was the Original Plan, so that the core would shrink
back to pre-8.0 sizes.
--%
Lab`6
>
> Hmmm, it'd be interesting to hear more opinions on this, but at
> this point, it's too late to change. There always comes a time
> when the features vs timeline discussions are done, and in the
> timeline race, megawidgets lost, mostly because of the design time
> to get it right. There were so many other things already done,
> enough to justify a minor release without overloading such a
> release with new features. Feather also fell out of 8.3 due to
> similar reasons. Definitely a hi prio, but it just isn't ready.
> I'm going to enjoy meeting Paul Duffin at Tcl'2K to hammer parts
> of Feather into stability for 8.4.
>
Well... Ok then. So forget my other posting since you answered it here.
But still, why propose delaying 8.3 if your mind is made up and you're
not gonna do it? That's like presenting a lollypop to a two-year old,
watching him drool and taking it away from him before he gets to lick
it. :-(
--%
Bryan Oakley
> lvi...@cas.org wrote:
> > According to Jeffrey Hobbs <jeffre...@scriptics.com>:
> > :I wanted to get megawidget support into 8.3, but alas ran out time
> > :(or you could all wait for 8.3 a while longer...). It will be on
> > :the hi prio list for 8.4.
> >
> > I would be happy to wait for 8.3, if it resulted in good megawidget
> > support
>
I'm in the "I'd rather wait" camp.
> but at
> this point, it's too late to change.
Oops. Never mind.
> There always comes a time
> when the features vs timeline discussions are done, and in the
> timeline race, megawidgets lost, mostly because of the design time
> to get it right. There were so many other things already done,
> enough to justify a minor release without overloading such a
> release with new features. Feather also fell out of 8.3 due to
> similar reasons. Definitely a hi prio, but it just isn't ready.
> I'm going to enjoy meeting Paul Duffin at Tcl'2K to hammer parts
> of Feather into stability for 8.4.
Do you have the design pretty much solidified? If you could give us a
preview of how it is going to work, perhaps some of use who like to create
megawidgets can get a jump on things and start attempting to write to the
new scheme.
Iain B. Findleton
Most of the wrappers I have made for Tcl/Tk interface are pretty
trivial, but appear more than sufficient. I guess that where I see some
benefit would be the development of a C++ structure that isolated from
developers the impact of changes such as the move to objects, and
perhaps the messiness of the Windows/Unix/whatever implementation
issues.
On the other hand, I have done quite a bit of OOP in C, and only a few
moments of thought about how to do this will result in a code structure
that delivers most of the benefits of C++ (no, not function overloading)
while maintaining portability robustness. You can easily get
constructors, destructors, inheritance, public/protected and private
all in C, and it actually is easier to maintain than the C style of, for
example, those folks at Scriptics Corporation. With a little added
grief, you can go to either message oriented parameter lists or
generalized objects (Wow, there is a thought!) or parseable strings, and
get the equivalent (at a mental stretch) of overloaded functions.
Anybody looked at hush? There is an enormous pile of C++ classes for
doing whatever with Tcl/Tk. Unfortunately, I found it faster to write
my own wrappers than to read the documentation.
Convert all of Tcl/Tk to C++? I would think not. Better to spend time
working on the basic structure of the core to keep it viable and to meke
it easier for third parties to mould it to their particular wishes (No
pun intended!)
--
Iain B. Findleton
http://pages.infinit.net/cclients
custom...@videotron.ca
(514)457-0744
Jean-Claude Wippler
>
> [...]
> So you really want to see Tcl more structured through C++ at the
> core level? This is one feature that has interesting theoretical
> potential, but is unlikely to be seen in the near future.
>
> are well known (it only made ANSI standards this year), whereas
> Tcl's current implementation compiles on machines that may never
> see a proper C++ compiler. Many are skeptical about the speed of
> code output by C++ compilers, often for good reason. At the open
> source conference last year, someone was seriously proposing (I
> think had already started the very beginnings) or a perl code
> port to C++. They were talking about what they had to restrict
> themselves to to ensure it would compile most places. In the end,
Maybe. Maybe not. C++ can be fast, small, and portable.
But I definitely agree with Jeffrey that C++ can also be slow, bloated,
and non-portable. It's the predominant form, in fact.
Two C++ examples from yours truly - I'll let others snicker/decide:
"TinyTCL Is Not Yet Tcl" - is an early cut at a minimal Tcl core:
http://mini.net/pub/ts1/tinytcl.txt
And MetaKit is a fast, small, portable embedded database:
http://www.equi4.com/metakit/
-- Jean-Claude
Jeffrey Hobbs
> Jeffrey Hobbs wrote:
> > (or you could all wait for 8.3 a while longer...). It will be on
> > the hi prio list for 8.4.
> Well... Ok then. So forget my other posting since you answered it here.
> But still, why propose delaying 8.3 if your mind is made up and you're
> not gonna do it? That's like presenting a lollypop to a two-year old,
> watching him drool and taking it away from him before he gets to lick
> it. :-(
You guys are too fond of sweets. The ()ethical remark was really
rhetorical. For those who've known me longer, they know that this
is personally a very high priority, so it was tough to let it slip.
It basically came down to not having the exact changes necessary to
get it done (I didn't want to half-a** anything).
For those looking for a good starter, see:
http://www.best.com/~sau/mega/
Lab`6
Jeffrey Hobbs wrote:
>
> You guys are too fond of sweets. The ()ethical remark was really
> rhetorical. For those who've known me longer, they know that this
> is personally a very high priority, so it was tough to let it slip.
Which is probably why all the people who've commented on this have said
"I can wait".
> It basically came down to not having the exact changes necessary to
> get it done (I didn't want to half-a** anything).
>
Well, we don't want that either. Which is probably why... Actually, I've
only seen one post from someone requesting 8.3 pronto and that person
didn't really say what they're expecting in 8.3 which isn't in 8.2.3.
But I can see you being tugged on one side by the community, on another
side by your employer and last (but probably not least), by yourself. It
can't be an easy decision. Speaking for myself, I'm just saying that for
important additions to Tcl and Tk, I'm all ready to accept some date
slippages. As long as it doesn't become vaporware...
--%
Cristiano Novello
>
> Cristiano Novello wrote:
> > Scott is right when he says that almost all EDA companies ship their
> > software with a bundled Tcl interpreter. And I can say this is *maybe*
> > good. At least this saves us from learning N "shell languages" for each
> > of the N different EDA tools we have on the market.
>
> Hehe... I work for one of those EDA companies that ships an embedded Tcl
> interpreter in our product. It's been interesting; there have been many
> times when it has saved my butt when I'm helping one of our field
> applications engineers at a customer site seven time zones and two spoken
> languages away, trying to customize some aspect of our tool to integrate
> with a weird tool flow.
>
are used
and, yeah, maybe you're right but I addressed a different problem: the
claim
that Tcl is good because is inserted by many EDA vendors in their tools.
> Nobody cares that it's Tcl that we're embedded with; everybody just wants to
> get the job done, and Tcl serves this purpose well.
>
As said above.
>
> The major reasons we use Tcl is because it's easy to learn (when we get a
> new AE, it takes about an hour to get them up to speed), has a reasonably
> rich library, and isn't proprietary (like Cadence's versions of SKILL). Oh,
> and almost everyone else uses it. I suspect that the EDA industry got
> hooked on it simply because then-Prof. Ousterhout lead a CAD group at
> Berkeley when he developed Tcl, and it just spread.
>
I agree on proprietarity. I do not (or better to a minor extent) with
the
claims that is easy to learn (thing that depends strongly on how "deep"
you have to go into the language, that again depends on the things you
have
to do) and with the statement "everyone else uses it": really?
> > (Sometimes) S/He needs some scripting language to easily automate boring
> > and repetitive task. S/He does not need nor wants to learn another fully
> > fledged language (VHDL and Verilog are enough for the time being) to do
> > their main task: designing circuits!
>
> Wrong audience. The people who use Tcl are the CAD managers, those
> responsible for integrating tools from a number of vendors who refuse to
> talk to each other. As far as I know, nobody uses Tcl in an everyday manner
> to design circuits. (Ok, so I do. But I wrote an extension that allows me
> to do this.)
>
I see. Tcl is not for the designer but is for the tool-administrator.
Probably I've misunterstood but I felt that the ads were pushing the
products
by saying that Tcl would have been very useful also for the designers.
As Design Application engineer I think that integrability comes from
sticking to standards
and not from scripting languages. Actually, I'm not *that* willing to
hack in Tcl just
to make my tools communicate because each EDA vendor is understanding
the standard
"in his own private way"...
>
> Tcl is not something that causes a customer to buy an EDA tool or even to
> allow an evaluation to occur at their site. Quite honestly, it's what the
> vendor (or its representatives) use to work around customer-specific items
> that would otherwise cause an evaluation to go sour.
>
> Dave
Think that you're really quite honest. ;-)
Maybe I am a bit naive but I see the whole question in this way:
*) you needed some scripting language
*) Tcl was there and it was for free. Full stop.
Pretending Tcl has been "the choice" or the tool that has Tcl inside is
"the coolest" or "easy integrable" is a bit too much.
Dave, i have a further question: what about the tool interfaces written
in Tk?
Which percentage of the market is relying on Tk to build them?
I ask this because I think, honestly, that Tcl is here because Tk was in
the box.
(at least this is valid for me).
Buon Natale e felice anno nuovo a tutti
Cristiano
--
=================--------------------------------- _|_|_|_|_|_|_|_
=
Cristiano NOVELLO (EZM VI - 6218 ) -| more fun, |-
cristianoDOTnovelloATinfineonDOTcom -|___less VLSI___|-
=================--------------------------------- | | | | | | |
=
Richard.Suchenwirth
>[snip snap]
> I see. Tcl is not for the designer but is for the tool-administrator.
> Probably I've misunterstood but I felt that the ads were pushing the
> products
> by saying that Tcl would have been very useful also for the designers.
>
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens Electrocom, Buecklestr. 1-5, D-78467 Konstanz,Germany
-------------- http://purl.org/thecliff/tcl/wiki//Richard*Suchenwirth
Cristiano Novello
I meant hardware designer. I am a CAD manager and I have the chance see
both
worlds and, believe me, there are great cultural differences between
the two. So, it could be easy for me to agree with you about *your*
position.
But... for the ones (hw designers) that know it, Tcl is some language
you can use
to make scripts that is too bothering to use (as already told, and that
was
not a joke, VHDL and Verilog are *far* more than enough).
I hope that everything has been clarified yet ;-)
Ciao
Stefaan A Eeckels
"Gerald W. Lester" <gwle...@home.com> writes:
> Most of the large Tcl applications that I'm aware of consist of a lot of
> small to medium size programs, not one massive monolithic program. This is
> different than the way applications are developed in many other languages.
....
> Historically, in Tcl it can become difficult to manage program development
> when a program starts to exceed a couple of thousands of lines. This
> encourages writing of smaller programs. However, tying programs together
> in Tcl is very, very easy. This leads people to start decomposing the
> problem into multiple autonomous programs. IMHO, this also leads to code
> reuse (the whole program, not chunks of it and a fairly natural progress
> to the application being developed being able to be distributed across
> platforms.
Applause!
This is so true, and it's a major limiting factor in the OO-ness
of compiled OO-languages such as C++. By considering the endpoint
of the development process to be the *program*, and not the *system*,
they severely limit their usefulness. Constructs such as CORBA are
invented to get around these problems, but introduce gratuitous
limitations and variations.
When looking at a system comprising C++ programs, Pro-C programs,
quicky reports in Perl, the whole mess strung together by shell
scripts, it quickly becomes obvious that the added value of the
OO-ness of C++ for the *system* is rather limited.
So here's my suggestion: ensure that wish becomes just as usable
as the system's primary shell as say, bash. Out with the crummy
shell syntax, in with tcl. Off the cuff, no default empty window
and command line history and editing would go long way (I mean,
tkcon is *nice*, but every so often I type "vi" in a tkcon
window, and have to kill tkcon from an xterm...).
Yes. A UNIX box with an enhanced wish as primary shell would
be close to heaven.
Best wishes to all; Merry Christmas and Happy 2000, if those
apply to you.
Take care,
--
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
Stefaan A Eeckels
Cristiano Novello <cn...@HL.siemens.DE> writes:
> Think that you're really quite honest. ;-)
> Maybe I am a bit naive but I see the whole question in this way:
> *) you needed some scripting language
> *) Tcl was there and it was for free. Full stop.
> Pretending Tcl has been "the choice" or the tool that has Tcl inside is
> "the coolest" or "easy integrable" is a bit too much.
language to integrate (and the easiest to write extensions
for, too). As far as "coolness" is concerned, that's
like beauty, in the eye of the beholder...
>
> Dave, i have a further question: what about the tool interfaces written
> in Tk?
> Which percentage of the market is relying on Tk to build them?
> I ask this because I think, honestly, that Tcl is here because Tk was in
> the box.
> (at least this is valid for me).
I've used Tcl/Tk, Perl/Tk and Python/Tk, and I vastly prefer
Tcl. Try doing a megawidget in Python, or clowning around with
Perl's eval...
But then I'm a LISP addict, so that might explain a lot ;-)
Cristiano Novello
>
> In article <385F5A46...@hl.siemens.de>,
> Cristiano Novello <cn...@HL.siemens.DE> writes:
> > Think that you're really quite honest. ;-)
> > Maybe I am a bit naive but I see the whole question in this way:
> > *) you needed some scripting language
> > *) Tcl was there and it was for free. Full stop.
> > Pretending Tcl has been "the choice" or the tool that has Tcl inside is
> > "the coolest" or "easy integrable" is a bit too much.
> Sorry to butt in, but IMHO Tcl is by far the easiest
> language to integrate
tool...
But for sure I know that it doesn't depend on a language whether *the
tool* is
integrable or not (which means the tool can be inserted smoothly into a
design
environment, like the ones that are used in the IC industry)
> >
> > Dave, i have a further question: what about the tool interfaces written
> > in Tk?
> > Which percentage of the market is relying on Tk to build them?
> > I ask this because I think, honestly, that Tcl is here because Tk was in
> > the box.
> > (at least this is valid for me).
> I've used Tcl/Tk, Perl/Tk and Python/Tk, and I vastly prefer
> Tcl. Try doing a megawidget in Python, or clowning around with
> Perl's eval...
appeal
me either... but again I feel that what had a great(?) success was the
bundle Tcl/Tk (the latter "halve" being the most attractive IMHO).
For instance, I am wondering why in the web script programming (where
the visual stuff
was already handled) Perl had such a breakthrough and, as far as i know,
we have no
"bare" Tcl there.
--
=================------------------------------ _|_|_|_|_|_|_|_ =
Cristiano NOVELLO (EZM VI - 6218 ) -| more fun, |-
cristianoDOTnovelloATinfineonDOTcom -|___less VLSI___|-
=================------------------------------ | | | | | | | =
Volker Hetzer
> Actually I do not know which language is easier to integrate in the
> tool...
> But for sure I know that it doesn't depend on a language whether *the
> tool* is
> integrable or not (which means the tool can be inserted smoothly into a
> design
> environment, like the ones that are used in the IC industry)
Well, having a scripting language that does socket communication does
make a real big difference in most designflows.
Same goes for file i/o and the ability to load extensions in shared libraries.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Stefaan A Eeckels
Cristiano Novello <cn...@HL.siemens.DE> writes:
> Actually I do not know which language is easier to integrate in the
> tool...
integrate, the result will be more reliable than when a
language is difficult to integrate (due to its internal
complexities, for instance).
> But for sure I know that it doesn't depend on a language whether *the
> tool* is integrable or not (which means the tool can be inserted smoothly
> into a design environment, like the ones that are used in the IC industry)
That statement amazes me. Surely, a tool with a baroque, buggy interface
language will be more difficult to integrate? I'm also quite convinced
that it would be easier to integrate three tools with Tcl, than one with
Tcl, one with Perl, and one with Python (if only because you don't have
to learn as many languages), and that the result will be more reliable
in the first case as well.
Now I grant you that if the tool doesn't have the interface
elements that allow its integration, the choice of the language
is not going to alleviate that problem one bit.
> Did not but just saw some examples in Perl/Tk and ... hmmm... doesn't
> appeal me either... but again I feel that what had a great(?) success
> was the bundle Tcl/Tk (the latter "halve" being the most attractive IMHO).
But the appeal of Tk is greatly enhanced by Tcl. IMHO, the Perl/Tk
and Python/Tk bindings (as would a C++/Tk binding) are much less
usable when it comes to building complex, dynamic interfaces.
> For instance, I am wondering why in the web script programming (where
> the visual stuff was already handled) Perl had such a breakthrough and,
> as far as i know, we have no "bare" Tcl there.
There is a lot of Web programming being done in Tcl, but no, it's
not the CGI language of choice (and if you follow c.l.p.m a bit,
you'll realize that the Perl regulars aren't too enthused by that
state of affairs). Why most CGI stuff is done in Perl is probably
caused by the fact that in the early days of the Web, a lot of
these developments were done by UNIX sysadmins, and Perl was (and
is) the most popular UNIX sysadmin tool (after all, it was designed
to be just that). Perl's "hey-I-am-a-super-duper-shell" syntax makes
it a natural for sysadmins. In my experience, Tcl's syntax repells most
sysadmins (IMHO it appeals more to programmers with a LISP mindset :-).
Darren New
> For instance, I am wondering why in the web script programming (where
> the visual stuff
> was already handled) Perl had such a breakthrough and, as far as i know,
> we have no
> "bare" Tcl there.
Well, the first online ecommerce shopping mall was entirely in Tcl.
--
Darren New / Senior Software Architect / Dai Ye
San Diego, CA, USA (PST). Cryptokeys on demand.
"Perl - The BASIC of the 90's"
Kris Klindworth
> For instance, I am wondering why in the web script programming (where
> the visual stuff
> was already handled) Perl had such a breakthrough and,
I lived this peace of history. Perl didn't have a breakthrough
on the web. Perl had a lucky break. It was at the right place,
at the right time, with the right stuff. Here is the story in broad
strokes.
1990 - Perl programmers began annoying/enlightening people in
comp.lang.awk and other scripting news groups by posting Perl
solutions to the questions asked. There was an article in
Unix World introducing Perl. It said that if AWK was a
Swiss Army knife of text manipulation, Perl was a Swiss Army
chain saw.
1991 - The first edition of the Camel book hit the shelves. I picked up
my copy in January. With three years of Unix scripting under my
belt I immediately recognized how much better Perl was for
scripting than awk and shell scripts. Apparently a lot of other Unix
professionals saw it the same way. Over the next three
years Perl became the defacto standard for any serious
scripting in a Unix environment.
1994(?) - Forms and the CGI capability were added to this obscure, but
growing thing called "the Web". As the servers in those days
were all Unix boxes, the language that the Unix sys admins
and developers used for the early scripting was there favorite
tool--Perl. O'Reilly and Associates published
"Managing Internet Information Services". The examples for
CGI programming were in Perl.
1995 - The web really takes off in the technical community. Unix guys
wrote more books on CGI programming, and, surprise, surprise, they
wrote the examples in the what was then the defacto scripting
language for Unix--Perl. The Camel books migrated from the Unix
section in the bookstores to the new Web section.
1996 - The web explodes. Companies decided they HAD to get on the web.
As almost all of the books on the shelves were written with example
in Perl, neophytes and CIO's got the strange notion that Perl was THE
language for programming the web. Job descriptions for the newly
created web developer positions listed Perl as a requirement. People
who want to fill those Web developer positions bought Perl books
and learned tried to learn Perl. A feed back loop of ignorance
propelled Perl into the prominent status it enjoys today.
Don't get me wrong. Perl is a good scripting language. It was my
primary programming language from February 1991 through June
1996. I started CGI programming with it in January of 1995 as
an interface to the databases I worked with. It is my firm conviction
that if Perl dominates web scripting today, it because it was at the
right place at the right time with the right stuff and not
because it is significantly better for the task than TCL or Python.
> as far as i know,
> we have no
> "bare" Tcl there.
There are in fact many places, but perhaps we should start
where more people start than anyplace else on the net...
http://aol.com
-------------------------------------------------------------
Kris Klindworth Email: kris.kl...@carle.com
Oracle DBA Phone: 217/326-2615
Carle Clinic Association Fax : 217/383-4980
Steven J. Cariglia
>
> I lived this peace of history. Perl didn't have a breakthrough
> on the web. Perl had a lucky break. It was at the right place,
> at the right time, with the right stuff.
My impression was/is that perl was pushed by a very vocal/determined
group of GNU'ers (and/or free software people -FSP) over Tcl. Something
about the Tcl/Tk licensing.. I believe that had Tcl been adopted back
then, perl would never have gotten off the ground.
A side note to this is that even Tk was deprecated by the FSP when it
clearly was the best toolkit around.. (I think the FSP tried to push
coding directly in X-Windows as a far better way to go than Tk <roll
eyes>).
I'd have to dust off some very old archives to dig up the huge threads
that developed over this issue. But, it didn't seem to have much to do
with functionality, ease of use, etc.?
--
Steven Cariglia
s...@haystack.mit.edu
Cristiano Novello
First of all, thank you for all your interesting answers.
Now, I would ask Stefaan to review my original posting to Scott Redman
about his statement:
> I'm also quite convinced
> that it would be easier to integrate three tools with Tcl, than one with
> Tcl, one with Perl, and one with Python (if only because you don't have
> to learn as many languages)
Reducing the pain is the most important job.
Then, I would also ask Darren, Kris and Steven to read the anser Dave
Cuthbert
gave to me (reported here)
> I suspect that the EDA industry got
> hooked on it simply because then-Prof. Ousterhout lead a CAD group at
> Berkeley when he developed Tcl, and it just spread.
>
Everyone wants to push its job, that's obvious :-)
And success into technical/scientific world is sometimes due to the
monster that
rules our lives that is called "marketing" :-))
Then, the four most important thing for a tool for be convincing
(already said them...and got some reply by Dave...)
*) be standard compliant!!!!!!! (I hate mangling VHDL code just to have
the simulator unterstand it)
*) be fast!!!!
*) be easy-to-use!!!!!!
*) be integrable.
Then the most important thing for a tool *to be integrable* with other
"players"
*) The EDA vendor attitude ;-)
Obviously these things live only IMHO.
Finally let me wish(!!!!) to all you
Merry Christmas and Happy 2000!
Schoene Weihnachten und frohliches 2000!
Buon Natale e Felice 2000!
(and do not forget to save your important files before the millennium
shutdown...)
Ciao
--
=================----------------------------- _|_|_|_|_|_|_|_ =
Cristiano NOVELLO (EZM VI - 6218 ) -| more fun, |-
cristianoDOTnovelloATinfineonDOTcom -|___less VLSI___|-
=================----------------------------- | | | | | | | =
bo...@aol.com
"Steven J. Cariglia" <s...@haystack.mit.edu> wrote:
> > Kris Klindworth wrote:
> >
> > I lived this peace of history. Perl didn't have a breakthrough
> > on the web. Perl had a lucky break. It was at the right place,
> > at the right time, with the right stuff.
>
> My impression was/is that perl was pushed by a very vocal/determined
> group of GNU'ers (and/or free software people -FSP) over Tcl. Something
> about the Tcl/Tk licensing.. I believe that had Tcl been adopted back
> then, perl would never have gotten off the ground.
It seems to me that the authors of these two languages 'march to
different drummers'. tcl's author thinks embedding and extensions are
all important. perl's has a more pragmatic approach. I don't think
timing has much to do with it. They are each trying to please (and
displeasing) a different group of people. perl pleases more.
>
> A side note to this is that even Tk was deprecated by the FSP when it
> clearly was the best toolkit around.. (I think the FSP tried to push
> coding directly in X-Windows as a far better way to go than Tk <roll
> eyes>).
>
> I'd have to dust off some very old archives to dig up the huge threads
> that developed over this issue. But, it didn't seem to have much to do
> with functionality, ease of use, etc.?
>
> --
> Steven Cariglia
> s...@haystack.mit.edu
>
Sent via Deja.com http://www.deja.com/
Before you buy.
David N. Welton
> > Kris Klindworth wrote:
> > I lived this peace of history. Perl didn't have a breakthrough
> > on the web. Perl had a lucky break. It was at the right place,
> > at the right time, with the right stuff.
> My impression was/is that perl was pushed by a very vocal/determined
> group of GNU'ers (and/or free software people -FSP) over
> Tcl. Something about the Tcl/Tk licensing.. I believe that had Tcl
> been adopted back then, perl would never have gotten off the ground.
The FSF people actually want(ed) some variant of Scheme or Lisp, from
what I have read (I wasn't there). There point is that it's best to
start with a complete language like Scheme and go from there, instead
of using a more incomplete language and having to always be adding to
it. RMS was using Lisp as Emacs' extension language back in the
80ies... Thus, the Guile project.
For example, from the Linuxcare interview (I work for them, so I'm
biased, but it's a nice interview, I think) at
http://www.linuxcare.com/news_columns/interviews/index.epl:
Linuxcare: How did you come to choose LISP as the EMACS engine?
Richard: LISP is the most powerful programming language, and if
you want an interpreter, LISP is the best. None of the other
languages come anywhere near LISP in their power. The most
exciting things about LISP are read, eval, and print. If you look
at other languages, they have no equivalent for any of those.
I'm sure RMS and company do of course prefer GPL'ed software to free
software with licenses that let you make proprietary extensions.
Ciao,
--
David N. Welton -+- dav...@prosa.it -+- http://www.efn.org/~davidw
David N. Welton
> 1994(?) - Forms and the CGI capability were added to this obscure, but
> growing thing called "the Web". As the servers in those days
> were all Unix boxes, the language that the Unix sys admins
> and developers used for the early scripting was there favorite
> tool--Perl. O'Reilly and Associates published
> "Managing Internet Information Services". The examples for
> CGI programming were in Perl.
> 1995 - The web really takes off in the technical community. Unix guys
> wrote more books on CGI programming, and, surprise, surprise, they
> wrote the examples in the what was then the defacto scripting
> language for Unix--Perl. The Camel books migrated from the Unix
> section in the bookstores to the new Web section.
1995 - If I am correct in my recollection, AOLServer and Storyserver
are created, allowing you to do server parsed Tcl, without spawning a
new process.
Playing the speculation game - if these had been open source in some
fashion, Tcl would be much, much bigger in the web space. Server
parsed Tcl is just a natural... An easy language to learn, relatively
powerful, easy to code C extensions to, easy to integrate with your
web server...
AOLServer is now open sourced, but it's too late, I think (although
I'm sure it's a great piece of code).
Cameron Laird
In article <87puvwl...@freddy.page.street>,
David N. Welton <dav...@prosa.it> wrote:
.
.
.
>AOLServer is now open sourced, but it's too late, I think (although
>I'm sure it's a great piece of code).
.
.
For AOLServer's current condition, see
<URL:http://www.linuxworld.com/linuxworld/lw-1999-09/lw-09-aolserver_1.html>.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Christopher Nelson
> > > I wanted to get megawidget support into 8.3, but alas ran out time
> > > (or you could all wait for 8.3 a while longer...). It will be on
> > > the hi prio list for 8.4.
> ...
A question: how will you deal with classes for megawidgets? I've seen something
somewhere about adding -class to basically all widgets but realized that that
leads to a problem with code like:
switch -- [winfo class $w] {
Button {
$w invoke
}
Checkbutton {
$w toggle
}
Radiobuttion {
$w select
}
...
}
If you can set classes, you need a way to get to the "base" class, too. Maybe
another [winfo] sub-command.
Chris
--
Christopher Nelson, Sr. Software Engineer Pinebush Technologies, Inc.
Author: Tcl/Tk Programmer's Reference http://www.purl.org/net/TclTkProgRef
Mike Hoegeman
>
> In article <38613AB3...@haystack.mit.edu>,
> "Steven J. Cariglia" <s...@haystack.mit.edu> wrote:
> > >
> > > I lived this peace of history. Perl didn't have a breakthrough
> > > on the web. Perl had a lucky break. It was at the right place,
> > > at the right time, with the right stuff.
> >
> > My impression was/is that perl was pushed by a very vocal/determined
> > group of GNU'ers (and/or free software people -FSP) over Tcl. Something
> > about the Tcl/Tk licensing.. I believe that had Tcl been adopted back
> > then, perl would never have gotten off the ground.
>
> different drummers'. tcl's author thinks embedding and extensions are
> all important. perl's has a more pragmatic approach.
all imporatant to what? a more pragmatic approach to what?
i don't see your point (completely).
-mike
David Cuthbert
had forgotten about it while on holiday :-)
Cristiano Novello wrote:
> Nice to hear it. I work for one of those IC companies where EDA tools
> are used and, yeah, maybe you're right but I addressed a different
> problem: the claim that Tcl is good because is inserted by many EDA
> vendors in their tools.
Oh, dear... I would hope that nobody would claim that something is good
because the EDA industry uses it. :-) Maybe I'm just a semi-disgruntled
insider, but much of the software being written by the EDA industy is far
from spectacular.
The fact that Tcl can glue all this cra^H^H^H^H junk together is a point
that proponents and pundits can both use.
> I agree on proprietarity. I do not (or better to a minor extent) with
> the claims that is easy to learn (thing that depends strongly on how
> "deep" you have to go into the language, that again depends on the
> things you have to do)
Let me rephrase: it is easy to understand how Tcl interprets the code.
There are only a few rules for substitutions. It's easy to teach this to
non-programmers (applications engineers, in my case) who are editing a few
lines here and there to integrate our software at a customer site.
> and with the statement "everyone else uses it": really?
In my world (Cadence-based analog design... somewhat narrow), yes. It's
either Tcl or SKILL, and the SKILL implementation we have access to is
extremely proprietary (Cadence controlled). Synopsys also uses it; not sure
about Mentor or Avant.
> I see. Tcl is not for the designer but is for the tool-administrator.
> Probably I've misunterstood but I felt that the ads were pushing the
> products by saying that Tcl would have been very useful also for
> the designers.
In the latest issues of EE Times, I've noticed a lot of discussion about
developing a new hardware description/simulation language. There's a lot of
noise being generated about using C++ for this, and a lot of counter-noise
about some competing standard whose name I forget. Personally, I fail to
see why Verilog and VHDL have failed here, but I admittedly don't use any
hardware description languages in regular practice, and haven't on any deep
sub-micron (DSM) designs.
Rather than the language, I think it's the library that's more important.
What features are necessary in a library is dependent on what aspect of
design you're working on.
> As Design Application engineer I think that integrability comes from
> sticking to standards and not from scripting languages. Actually, I'm
> not *that* willing to hack in Tcl just to make my tools communicate
> because each EDA vendor is understanding the standard "in his own
> private way"...
Integrability comes from your tool vendor recognising the fact that you want
to integrate with tools from other vendors and providing adequate interfaces
and documentation to allow you to do so.
Unfortunately (again), very few vendors are willing to do this.
> Think that you're really quite honest. ;-)
> Maybe I am a bit naive but I see the whole question in this way:
> *) you needed some scripting language
> *) Tcl was there and it was for free. Full stop.
> Pretending Tcl has been "the choice" or the tool that has Tcl inside is
> "the coolest" or "easy integrable" is a bit too much.
Actually, I wanted to integrate with Python. The Tcl perspective of
"everything is a string" can become somewhat painful when scripts get
extremely large. Python's type system has its quirks, too, but does a
better job. (Unfortunately, trying to talk an AE through debugging Python
code -- where indentation matters -- with only vi is quite painful in its
own right)
To paraphrase our decision process, it went more like:
- I needed a scripting language in our tool.
- Python was there, I knew it better than Tcl, and it is free.
- I wrote up a prototype interface and demonstrated it.
- Management said, "Nice, Dave, but we have xx other developers here
who know Tcl, and one who knows Python."
- I groaned, and spent a month in misery trying to write, maintain, and
test 1000-20,000 line Tcl scripts.
- A month later, I discovered [incr Tcl] and have lived more or less
happily ever after.
> Dave, i have a further question: what about the tool interfaces written
> in Tk?
> Which percentage of the market is relying on Tk to build them?
> I ask this because I think, honestly, that Tcl is here because Tk was in
> the box.
> (at least this is valid for me).
Hmm... I actually have yet to see tool interfaces written in Tk. It *could*
be there, under the hood, for all I know. But I'm not the right person to
ask. It's the rare event when I run the GUI for our tool; almost everything
I do is in batch mode.
Dave
James Ingham
I want to make a possibly relevant meta-comment here. I think it is a
VERY encouraging sign of the maturity and class of the Tcl community
that a thread which started as Tcl vrs. the rest of the scripting
world continued as an interesting and informative discussion of the
uses and merits of Tcl, with almost no bashing of other languages. In
fact, if you look over the thread, it mostly consisted of discussions
of how Tcl is currently used, and ways that it could be improved.
There is space enough for a whole flock of scripting languages, and
the proper job of the users of any one language is how to improve that
language as best as they can. Glimpses at other languages should be
for the purpose of stealing whatever good ideas they have that are
relevant, period! That was the main content of this thread.
Cool!!!
Jim
--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions Inc.
Jeffrey Hobbs
> > > Jeffrey Hobbs wrote:
> > > > I wanted to get megawidget support into 8.3, but alas ran out time
> > > > (or you could all wait for 8.3 a while longer...). It will be on
> > > > the hi prio list for 8.4.
> > ...
>
> A question: how will you deal with classes for megawidgets? I've seen something
> somewhere about adding -class to basically all widgets but realized that that
> leads to a problem with code like:
>
> switch -- [winfo class $w] {
> Button {
> $w invoke
> }
> Checkbutton {
> $w toggle
> }
> Radiobuttion {
> $w select
> }
> ...
> }
>
> If you can set classes, you need a way to get to the "base" class, too. Maybe
> another [winfo] sub-command.
I disagree, I think the above code should be fixed. Yes, the
idea would be to add the "class-patch" as it is referred to,
that adds -class to all widgets, although toplevels and frames
already have this. The above strict code should be left that
way. A user may intend to have a MegaButton act differently.
It kind of gets to be a pain in the above case, but I think as
a general rule you would want the widget to have it's own
class (this is already done with megawidgets - they just
encapsulate in a frame, which already takes -class).
lvi...@cas.org
According to Mike Hoegeman <hm...@gte.net>:
:bo...@aol.com wrote:
:> It seems to me that the authors of these two languages 'march to
:> different drummers'. tcl's author thinks embedding and extensions are
:> all important. perl's has a more pragmatic approach.
:
:all imporatant to what? a more pragmatic approach to what?
:i don't see your point (completely).
Perl includes many different extensions from many different programmers in
the 'core' source distribution. Tcl includes very few extensions to its
core. Thus, core Perl begins with a wider range of functionality 'out of the
box' than Tcl.
--
<URL: mailto:lvi...@cas.org> <URL: http://www.usenix.org/events/tcl2k/>
<*> O- <URL: http://www.purl.org/NET/lvirden/> Tcl2K - Austin, Texas, US
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Jeffrey Hobbs
> According to Mike Hoegeman <hm...@gte.net>:
> :bo...@aol.com wrote:
> :> It seems to me that the authors of these two languages 'march to
> :> different drummers'. tcl's author thinks embedding and extensions are
> :> all important. perl's has a more pragmatic approach.
> :
> :all imporatant to what? a more pragmatic approach to what?
> :i don't see your point (completely).
>
> Perl includes many different extensions from many different programmers in
> the 'core' source distribution. Tcl includes very few extensions to its
> core. Thus, core Perl begins with a wider range of functionality 'out of the
> box' than Tcl.
We (the Scriptics core team... er, OK, that's me) do mean to change
this ASAP. We're going to start creating a stdlib for Tcl, that
will start with mature Tcl only extensions like FTP, SMTP, base64,
etc. Basic characteristics of packages that will be added are that
they behave and exist properly in their own namespace, that they
are Tcl only, and we may try and apply some TEA config stuff to
them. However, the packages should be so simple that you would
have:
/usr/local/lib/tcl8.3
..../stdlib/
..../base64/
..../base64/pkgIndex.tcl
..../base64/base64.tcl
..../smtp/
...
..../ftp/
...
Such that if you put the stdlib next to your runtime tcl lib,
then Tcl's basic package search path will find any packages
in it. It will still be distributed "separate" from the core,
but we will be more aggressively pointing out its availability.
More on this and other such enhancements at Tcl2K. I encourage
anyone interested in these or any Tcl related topic to be there.
I'll be there all week, and you can only hope that I won't go
hoarse before the conference ends (I almost did last time...).
Benjamin A Allan
However, could we have it at least a little obvious
that this lib is tcl/tk related? Perhaps
/usr/local/lib/tcl8.3
..../tcllib8.3
..../tklib8.3
or (heaven forbid we achieve simplicity) have just one
..../tcltklib
If you don't like the lib syllable in the subdirectory names,
perhaps std, ....ticklestd/.
Some of my fellow pointy-headed sysadmins appreciate
dir names unlikely to conflict with some other too-generically
named thing in /usr/local.:)
thanks,
Ben Allan
Jeffrey Hobbs
> I can't overstate how much I like this idea.
> However, could we have it at least a little obvious
> that this lib is tcl/tk related? Perhaps
> /usr/local/lib/tcl8.3
> ..../tcllib8.3
> ..../tklib8.3
> or (heaven forbid we achieve simplicity) have just one
> ..../tcltklib
Yes, this is more logical. I'm not sure that we got around
to finalizing the name yet, or even whether the Tcl and Tk
parts should be separated. I thought at first that it would
be good to have them separated, as many use Tcl without Tk.
However, there are likely to be many stdtklib calls that would
require stdtcllib routines. In any case, these are the items
that have to be ironed out.
> JEff wrote:
...
> them. However, the packages should be so simple that you would
> have:
> /usr/local/lib/tcl8.3
> ..../stdlib/
--
lvi...@cas.org
According to Jeffrey Hobbs <jeffre...@scriptics.com>:
:Yes, this is more logical. I'm not sure that we got around
:to finalizing the name yet, or even whether the Tcl and Tk
:parts should be separated. I thought at first that it would
I want to vote for making sure that these add ons get installed in a
manner similar to the rest of tcl and tk - so that one can use
--prefix=/usr/tcl83 and later --prefix=/usr/tcl84 , etc. and keep
parallel versions installed simultaneously ...
Cameron Laird
Ronald Garcia <rgar...@picasso.helios.nd.edu> wrote:
.
.
.
>On another note, most of the discussions I've seen of Tcl vs. XXX or
>Tcl as a language have focused on pre-8.0 editions. Have there been
>[m]any since? I'm particularly interested in 8.0+ Tcl applications
>that embed the interpreter in C/C++ apps.
>
>ron
>
No, not many. I invite you to write your own; we'll surely
find a good home for it. In the meantime, <URL:http://
www.sunworld.com/sunworldonline/swol-01-2000/swol-01-regex.html>
is a piece that lightly touches on this topic.
lvi...@cas.org
According to Cameron Laird <cla...@starbase.neosoft.com>:
:In article <d3rln6t...@puck.cse.nd.edu>,
:Ronald Garcia <rgar...@picasso.helios.nd.edu> wrote:
:>On another note, most of the discussions I've seen of Tcl vs. XXX or
^^^^^^^^^^
:>Tcl as a language have focused on pre-8.0 editions. Have there been
:>[m]any since? I'm particularly interested in 8.0+ Tcl applications
:>that embed the interpreter in C/C++ apps.
:>
:>ron
:>
:
:No, not many. I invite you to write your own; we'll surely
^^^^
Is the many to which you refer discussions about Tcl vs other
languages, or Tcl 8.x applications?
Cameron Laird
>
>According to Cameron Laird <cla...@starbase.neosoft.com>:
>:In article <d3rln6t...@puck.cse.nd.edu>,
>:Ronald Garcia <rgar...@picasso.helios.nd.edu> wrote:
>:>On another note, most of the discussions I've seen of Tcl vs. XXX or
> ^^^^^^^^^^
>:>Tcl as a language have focused on pre-8.0 editions. Have there been
>:>[m]any since? I'm particularly interested in 8.0+ Tcl applications
> ^^^^^^
>:>that embed the interpreter in C/C++ apps.
>:>
>:>ron
>:>
>:
>:No, not many. I invite you to write your own; we'll surely
>
> ^^^^
>
>Is the many to which you refer discussions about Tcl vs other
>languages, or Tcl 8.x applications?
.
.
Discussions. A lot of people reading about Tcl persist
in referring to old Tom and Richard diatribes against
perceived misfeatures in 7.5 and before. It's timely
for people to compare even 8.0, let alone 8.2, to the
latest Perl, Python, ...
Cameron Laird
David Cuthbert <da...@kanga.org> wrote:
.
.
.
>To paraphrase our decision process, it went more like:
> - I needed a scripting language in our tool.
> - Python was there, I knew it better than Tcl, and it is free.
> - I wrote up a prototype interface and demonstrated it.
> - Management said, "Nice, Dave, but we have xx other developers here
> who know Tcl, and one who knows Python."
> - I groaned, and spent a month in misery trying to write, maintain, and
> test 1000-20,000 line Tcl scripts.
> - A month later, I discovered [incr Tcl] and have lived more or less
> happily ever after.
benefits [incr Tcl] gives you in this very real-world
instance.
.
.
.
>Hmm... I actually have yet to see tool interfaces written in Tk. It *could*
>be there, under the hood, for all I know. But I'm not the right person to
>ask. It's the rare event when I run the GUI for our tool; almost everything
>I do is in batch mode.
>
>Dave
products which rely on the Tk canvas. I'm a bit fuz-
zy on which vendors are OK with mention of this.
David Cuthbert
> David Cuthbert <da...@kanga.org> wrote:
> > - A month later, I discovered [incr Tcl] and have lived more or less
> > happily ever after.
> benefits [incr Tcl] gives you in this very real-world
> instance.
Well, I'll start with the limitations we encountered in Tcl (or, in reality,
limitations with the way we were using Tcl).
Our scripts started out as fairly small (< 100 lines) wrappers to format
arguments to executables which did the bulk of the work. No procedures;
just a few lines to check for consistency, a few lines of formatting, an
exec call, and some checking of the result code from the executable.
Because there were no procedures, all variables were global, etc.
Our customers wanted better argument checking (this is user-entered input
going to an executable which does no checking on its own), so these scripts
started to grow. No single person was maintaining them; each script was
handed down to the newest developer and/or intern with little instruction on
what kind of programming style was expected. This is about the time I
started; at this point, we had 15-20 scripts of roughly 800-1400 lines each.
We finally started to realise that the same checks were being repeated from
script to script, making it hard to correct an error (you had to fix
something like 20 different files). So we made a file with procedures for
the most common checks in them, sourced it (we didn't know about packages
then), and used them. Life was good.
Well, for about two weeks.
One thing about the EDA industry is that every customer has a unique tool
flow and setup. Although we had added a lot of checking, some sites were
equipped to do a lot more; our scripts were only handling the common
denominator. So you want to alter a check procedure to do more for these
special cases, but need to get a parameter to this procedure (call it Z)
that isn't normally available. Problem: Z isn't a monolitic procedure; it's
called by X, Y, Q, P, etc., and you really don't feel like altering the
rest. So you make Z aware of a 'hidden' global, check to see if it's set,
do the extra checking if it is, etc.
To top it off, these 'hidden' globals had names like "width," "height,"
"current," etc. -- not exactly unique, and not exactly used in the same
manner. Namespace clash galore.
OO people should see this case of "X checks everything Y does, plus Z" and
immediately think "inheritance." Good programmers should see "namespace
clash" and think "encapsulation." [incr Tcl] provides both. The ability to
override methods provides a solution to the first requirement. Member
variables provide the encapsulation. Problem solved.
Of course, there's nothing in Tcl that mandates our original poor
programming style. However, it was the easiest route, and we're usually
under severe time constraints. Even with [incr Tcl], the bad style is
still, probably, the easiest route; suddenly, though, doing it right doesn't
require quite so much effort.
Also, there's nothing in the technology behind [incr Tcl] that makes it
better than any other OO system. I chose it because it was readily
available, was fairly well documented, integrated painlessly, and was rather
intuitive (for us, at least. Outside of Tcl, we're a C++ shop; not sure
what, if any, influence this had on me).
> They're there. There definitely are commercial EDA
> products which rely on the Tk canvas. I'm a bit fuz-
> zy on which vendors are OK with mention of this.
Probably none, unfortunately. :-( EDA vendors (my company included) tend
to be quite secretive.
Dave