why did these companies choose Tcl over Python
chewie54
As an electronics engineer I use some very expensive EDA CAD tool
programs that are scriptable using Tcl. I was wondering why these
companies have choose to use Tcl instead of Python. Some of these
are:
Mentor Graphics ModelTech VHDL and Verilog simulator
Synopsys Design Compiler and Primetime Static Timing Analyzer
Actel FPGA tools.
Tcl seems to very popular in my business as the scripting language of
choice.
I'm in the process of deciding to use Tcl or Python for a CAD tool
program that I have been working on. Most of the core of the
program, the database, will be done is C as an extension to either
Tcl or Python, but I intend to use Tk or wxPthon for the GUI. I do
need publishing quality outputs from drawings done on a graphics
device that are scaled to standard printer paper sizes.
I would prefer to use Python but can't deny how popular Tcl is, as
mentioned above, so my question is why wasn't Python selected by
these companies as the choice of scripting languages for their
product?
Are there any obvious advantages like:
performance,
memory footprint,
better cross-platform support,
ease of use,
Thanks in advance for your thoughts about this.
Jonathan Gardner
>
> I would prefer to use Python but can't deny how popular Tcl is, as
> mentioned above, so my question is why wasn't Python selected by
> these companies as the choice of scripting languages for their
> product?
>
Here are some reasons why people choose language X over Y:
- History. We've always used X, so why should we use Y?
- Peer pressure. Everyone else uses X.
- Licensing. Language X's license fits our business better than
language Y.
- Support. It is easier/safer/etc... to get support for language X
over language Y. (In some cases, the company that wrote X provides
support contracts while language Y doesn't have such a company.)
- Customer demands. Our customers want language X support, not Y.
- Features. Language X does A, B, and C really well, while language Y
only does it a little bit or not very well.
You'd have to ask them why they do what they do, but it's probably a
combination of the above. Oftentimes, the reasons cited are based on
assumptions and not facts. Of course, objectively measuring any
language is difficult at best, so there is little hope of this ever
getting any better.
As far as performance, memory footprint, cross-platform support, I
don't believe Tcl is better than Python (and probably not worse), at
least compared to C.
Tcl might also be a more natural language for hardware people who have
a hard time accepting the more esoteric concepts of software
engineering. It's a straight-forward language with little in the way
of what they may consider fluff.
"Martin v. Löwis"
> mentioned above, so my question is why wasn't Python selected by
> these companies as the choice of scripting languages for their
> product?
I think this question needs to be answered on a case-by-case basis,
but my guess is that it is in most cases historical. Work on Tcl
started in 1988, and it was the first (major?) embeddable scripting
language (that is also free software etc). Python wasn't released
until 1991, and wasn't first recognized as being just as easily
embeddable (and I think early releases weren't as easily embeddable
as today's Python is).
Tcl's original objective was to support circuit design, so people
in that field clearly knew that Tcl worked, but they were likely
unaware of any alternatives (or else the future of these alternatives
may have been uncertain).
So at that time, Tcl would have been the obvious (because only)
choice. Now these products are stuck with Tcl, and redoing all
the work (including the existing extension modules!) in a different
programming language would be a lot of work.
Regards,
Martin
Hrvoje Niksic
> Mentor Graphics ModelTech VHDL and Verilog simulator
> Synopsys Design Compiler and Primetime Static Timing Analyzer
> Actel FPGA tools.
How old are these tools? Tcl has been around as an extension language
for a long time, longer than most currently popular scripting
languages. It is quite possible that some or all of these tools chose
Tcl simply because it was there when they were making the choice.
MrJean1
used
to provide a command line interface for electronic design automation
(EDA)
tools.
Most commercial EDA vendors at that time were using their own,
proprietary
command language. Only later became Tcl widely adopted among EDA
vendors
and -even more important- among users, electronic designers.
There is a large base of Tcl scripts in existence among users.
Replacing
that is practically and commercially simply not feasible regardless of
the strengths or weaknesses of Tcl vs any other language.
Recently, Python is getting more traction inside EDA, especially for
internal use and internal development and in some cases as the design
language of newer EDA tools.
/Jean Brouwers
snd...@gmail.com
tcl is somewhat simpler to extend but you'll pay the price later on in
the
form or the hideous tcl scripts floating around your system
Tim Roberts
>
>As an electronics engineer I use some very expensive EDA CAD tool
>programs that are scriptable using Tcl. I was wondering why these
>companies have choose to use Tcl instead of Python. Some of these
>are:
>
> Mentor Graphics ModelTech VHDL and Verilog simulator
> Synopsys Design Compiler and Primetime Static Timing Analyzer
> Actel FPGA tools.
Well, I recently did a development contract for Mentor, and the RFQ gave me
the choice of doing the library binding and diagnostic GUI in either Tcl or
Python. Naturally, I chose Python (and wxPython), and both the client and
I are quite happy with the result.
(Actually, I did a Tcl binding for them as well, and just writing the text
scripts reinforced my dislike for it...)
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Eddie Corns
>Hello,
>As an electronics engineer I use some very expensive EDA CAD tool
>programs that are scriptable using Tcl. I was wondering why these
>companies have choose to use Tcl instead of Python. Some of these
>are:
> Mentor Graphics ModelTech VHDL and Verilog simulator
> Synopsys Design Compiler and Primetime Static Timing Analyzer
> Actel FPGA tools.
>Tcl seems to very popular in my business as the scripting language of
>choice.
>I'm in the process of deciding to use Tcl or Python for a CAD tool
>program that I have been working on. Most of the core of the
>program, the database, will be done is C as an extension to either
>Tcl or Python, but I intend to use Tk or wxPthon for the GUI. I do
>need publishing quality outputs from drawings done on a graphics
>device that are scaled to standard printer paper sizes.
>I would prefer to use Python but can't deny how popular Tcl is, as
>mentioned above, so my question is why wasn't Python selected by
>these companies as the choice of scripting languages for their
>product?
Having abandoned TCL for Python years ago, my thought is:
If you expect your users to write (and maintain) large scripts - have mercy on
them and don't give them TCL.
For larger programs/scripts having proper data structures, readable syntax,
etc. is a very significant factor. (Of course TCL may have improved beyond
all recognition since I last used it). Try putting together some sample
scripts in both languages and see how easily others can understand them (and
yourself in a few months).
When I want something nimbler than Python I use Lua.
Eddie
Roy Smith
> I would prefer to use Python but can't deny how popular Tcl is, as
> mentioned above, so my question is why wasn't Python selected by
> these companies as the choice of scripting languages for their
> product?
>
> Are there any obvious advantages like:
>
> performance,
> memory footprint,
> better cross-platform support,
> ease of use,
I used to work on a project which was written mostly in Tcl. Not a huge
project, but not a trivial one either. Perhaps a few 10's of KLOC over 100
Tcl source files. The domain was network monitoring using SNMP. No
graphics. We also used a commercially available network simulator (Mimic)
which was written in Tcl (or, at least, has Mimic as its scripting
language).
For us, the biggest thing was the quick learning curve (i.e. ease of use).
Most of the programmers on the team were network jocks, not programmers.
Getting them up to speed on enough Tcl to do their jobs was very quick.
Performance was not an issue, since the application was rate limited by the
network (i.e. waiting for SNMP replies to come back).
We also had lots of hooks into C code. Doing that is trivial in Tcl. Yes,
I know you can extend/embed Python, but it's a LOT easier in Tcl.
Embedding a Tcl interpreter in a C program is literally one line of code.
I sat down with the book to figure out how to do it, and had a running
interpreter going in 10 minutes. Part of what makes it so easy is that
everything in Tcl is a string (no need to support multiple data types).
I don't think I would want to write a huge system in Tcl. For one thing,
it's not object oriented (I have no direct experience with incr Tcl, so
that may not be a fair critisism). It's also slow (even slower than
Python). Of course, in both Tcl and Python, the key to a fast application
is to do all the CPU-intensive parts in C and just script the glue code.
Anyway, I like Tcl. It's certainly worth considering seriously as a
scripting language. As for "which is better, Tcl or Python", there's no
one right answer to that. Evaluate both and decide which fits your needs
better. Often, questions like that will be decided by things which have
little to do with language technology. Is your company re-organizing and
there's a development group who are used to working in language X who are
looking for a new project? Guess which language they're going to pick?
Got a major customer (or prospect) who expresses an interest in language X
for scripting extensions? Guess which language you're going to use?
Kevin Walzer
One of the reasons Tcl has stayed around for so long is that it has
found several niche's/domains where it has proven extremely useful.
VDHL/Verilog is one of these areas: Tcl became the preferred solution
for embedding and scripting, and has proven hard to dislodge. Network
automation/scripting (via Tcl's Expect solution) is another problem
domain where Tcl is widely used. GUI programming (with Tk) is yet another.
Developers tend to forget about Tcl as a viable programming language,
and one of the reasons is that the problem domains where it has gained
traction tend to be highly specialized.
I do GUI programming in Tk with both Python and Tcl. Doing sophisticated
GUI's in Tk tends to be harder in Python than Tcl, because some of the
current, modern Tk GUI libraries haven't been wrapped via Python.
Understanding Tcl helps because I can drop into Tcl to customize a Tk
widget as needed, then call the customized bits from Python.
In terms of suitability as a general purpose programming language,
Python's biggest advantage over Tcl is the size of its standard library
(Tcl is much smaller at its core, by design), its more singular approach
to object-oriented programming if you use that method (Tcl has several
different OO systems), and the size of its community--the larger number
of Python programmers out there make it much more likely that you will
find an open-source solution for your needs. Tcl's community is much
smaller, its development moves more slowly, and Tcl does not compete in
several major "hot" areas of development (no web frameworks like Django
or Ruby on Rails).
Hope this helps,
Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Paddy
Here is TCL's author talking about its roots: http://www.tcl.tk/about/history.html
The Electronic Design Automation industry was in some ways ahead of
other industries in adopting TCL as its major scripting language but
because of this I think it might now be suffering because, as capable
as TCL is, current EDA tools would benefit from reflecting what is
increasingly an object oriented compiled language core, as Python
objects for user manipulation.
- Paddy.
Hrvoje Niksic
> We also had lots of hooks into C code. Doing that is trivial in Tcl. Yes,
> I know you can extend/embed Python, but it's a LOT easier in Tcl.
> Embedding a Tcl interpreter in a C program is literally one line of
> code.
Have you tried both or just Tcl? I've seen examples of both and they
look about equally simple to set up.
http://docs.python.org/ext/high-level-embedding.html shows a Python
high-level example. Many companies use the kind of simple embedding
shown there in real-world projects.
Robin Becker
.......
> I think this question needs to be answered on a case-by-case basis,
> but my guess is that it is in most cases historical. Work on Tcl
> started in 1988, and it was the first (major?) embeddable scripting
> language (that is also free software etc). Python wasn't released
> until 1991, and wasn't first recognized as being just as easily
> embeddable (and I think early releases weren't as easily embeddable
> as today's Python is).
in the 70's many of the people I knew in engineering were using forth as an
embedded language. Of course the embedding was the final application as the
controlling computers were really puny eg pdp8/9/11.
At that time the concept of free software hadn't even arisen. I believe forth
was proprietary, but it was widely available to academics and many machine tools
and similar control applications used it.
--
Robin Becker
chewie54
> Providenza & Boekelheide, Inc.
Hi Tim,
I would like to use Python and C and wxWidgets for my EDA CAD program.
I want
to put most of the program core in an Python extension and GUI in
wxWidgets.
I do need to get publishing quality vector graphics outputs from this
program so
one of my concerns is if the wxWidgets will work for this or will I
have to use
something like openGL or Cairo.
Did your work for Mentor include a high quality graphics output?
Thanks,
Chris Mellon
wxWidgets has a vector graphics implementations which is a wrapper for
native vector graphics. Look at wxGraphicsContext. It's not perfect
and you may want to use Cairo directly, especially if you need to
render to PDF or postscript for output.
Tim Roberts
>
>I would like to use Python and C and wxWidgets for my EDA CAD program.
>I want to put most of the program core in an Python extension and
>GUI in wxWidgets.
>
>I do need to get publishing quality vector graphics outputs from this
>program so one of my concerns is if the wxWidgets will work for this
>or will I have to use something like openGL or Cairo.
>
>Did your work for Mentor include a high quality graphics output?
No. My project was a friendly GUI front-end for exercising a hardware
simulation. They liked it enough that they've asked for another.
VernM
I'm an electrical engineer too, and have lamented the same lack of
Python scripting for tools like the ModelTech VHDL simulator. I think
the original choice had to do with with the ease of embedding TCL into
applications written in C, and the use of TCL in university EE
departments. I would rather die than try to write anything approaching
a complete application in TCL. Other braver souls have actually done
it, but I am sure they are masochists.
About a year ago I discovered an interesting project that embedded
Python in TCL (!). it's called TCLPython. I have tried this out with
ModelSim 6.2, and it actually works! I have written a few Python
scripts that drive a signal in a VHDL simulation.
Here is a link: http://www.ellogon.org/petasis/index.php?option=com_content&task=view&id=27&Itemid=43
Best regards, Vern Muhr
Kryvor
> programs that are scriptable using Tcl. I was wondering why these
> companies have choose to use Tcl instead of Python. Some of these
> are:
>
> Mentor Graphics ModelTech VHDL and Verilog simulator
> Synopsys Design Compiler and Primetime Static Timing Analyzer
> ActelFPGA tools.
I suspect that it's due to historical reasons.
TCL first appeared in 1988, whereas Python appeared in 1991. Some of
these tools have been around for a very long time, and I suspect that,
at first, it was mostly a question of picking the most popular
scripting language; decisions made in recent years are probably more
for convenience & backward-compatibility reasons than anything else.
(That said, I'm not a huge fan of Python's lack of braces ... :)
K.