Python EDA Initiative: Why Use Python?

The task is to create a set of open source EDA tools. The first problem is: what programming language should be chosen? A set of objective criteria narrows the problem scope.

The chosen programming language should be:

The language candidates are:

Now, let's apply the criteria to each of these languages:


Strengths: Python has a good open source license and good portability. Python has unusually good affinity for extensions. Jython and Boost.Python connect Java and C++ directly with Python. Python has a combination of file/directory based module abstractions and object/class abstractions for large-scale programming. With built-in support for advanced data structures (strings, hashes (dicts in Python parlance), and lists), and a solid standard library, Python scores well in productivity. The fact that Python has been used to teach programming to young children attests to its accesibility to non-experts.

Weaknesses: Python scores well on the selected metrics, but it has problems, too. Python has been undergoing significant changes in the most current versions; these features are extremely useful, but are making the language unstable. Threading support is very weak and interacts badly with extensions. It is not as widespread as other languages. The Vaults of Parnassus are no match for the completeness of CPAN.

Conclusion: Python is a strong language for applications development.


Strengths: C is the default choice of open source development. It is completely unencumbered by licensing. The language itself is quite portable. It is accessible to non-experts. Some would argue this, but the vast quantity of software written in C provides solid evidence of its accessibility.

Weaknesses: C is not terribly supportive of large-scale programming. Code grouping is primarily defined by files. Less-detailed or more-detailed code granularity is not supported. C libraries tend to be annoyingly non-portable. C is not very productive. Memory must be explicitly managed. Preprocessor manipulations occur outside of lexical analysis. Libraries of advanced data structures tend to require detailed calling conventions. Error management requires manipulating global error variables and checking return values.

Conclusion: C should simply not be used for applications programming anymore. C++ has all of the strengths of C while mitigating many of the weaknesses.


Strengths: C++ is almost completely compatible with C. It is also unencumbered by licensing. The language itself is quite portable. C++ has features for large-scale programming. The addition of classes allows grouping of data and accessors for finer granularity than C. Namespaces also play into large-scale programming features. The C++ Standard Library is now sufficiently well implemented on most platforms that it can be considered portable. This provides good data structures without requiring explicit memory management. Boost provides solid, peer-reviewed libraries for many common programming tasks. Error conditions can be signaled using exception mechanisms. Consequently, C++ can be highly productive.

Weaknesses: C++ is not accessible to non-experts. There are many who would argue with this. However, C++ provides far too many ways to get things "almost-but-not-quite" right. In addition, a programmer must learn how to use the Standard Template Library before becoming highly productive in C++. Even though expert programmers are extremely productive in C++, new programmers often find STL code incomprehensible while average C++ programmers often do not understand the programming idioms which avoid the many subtle pitfalls.

Conculsion: C++ is an extremely good candidate for applications programming. However, its inherent difficulty makes it a poor choice for a project which wants to receive contributions from those who may not be programming experts.


Strengths: Java is widely accepted for network-centric programming. The language itself touts its portability. Its class handling is supportive of large-scale programming. It has static typing, garbage collection, exceptions, a large set of standard classes, and a very good testing framework. These features make it a highly productive language. Most programmers can read Java programs without too much difficulty; it seems to be accessible to non-experts.

Weaknesses: Java has a license unacceptable to many people. This is a limiting factor for EDA tools which are attempting to reach a broad audience. The class framework can be limiting; interfaces to other packages can be limited (this is changing). In addition, Java seems to have more theoretical portability than practical. Attempts to run even simple programs on different operating systems often fail.

Conclusion: Java is also a good candidate for applications programming. However, its license is a poor choice and portability is an issue.


Strengths: Tcl/Tk seems to be the standard scripting language for VLSI tools nowadays. It has a good license and has been ported to lots of hardware. Tk is an extremely useful GUI toolkit. So much so that Python uses it for its GUI toolkit as well. Tcl/Tk was originally designed for gluing together VLSI tools; consequently, it is extremely productive and is useful to beginners.

Weaknesses: Tcl/Tk was not designed to be a full-scale programming language. Support for large-scale programming is bolted on with [incr Tcl] rather than being part of the core. Everything in Tcl/Tk is treated as a string; advanced data structures are not built into the language.

Conclusion: Tcl/Tk is a good candidate for linking together programs, but is weak for doing significant programming on its own.


Strengths: Perl has a great license and phenomenal portability; it is installed on most machines by default Productivity in Perl is extremely high due to the inclusion of advanced data structures directly in the base language and the Comprehensive Perl Archive Network(CPAN). The widespread use of Perl attests to its appeal to beginners. Perl has interfaces to almost any useful

Weaknesses: Perl was not designed to handle large-scale programming; its handling of classes and multi-dimensional structures has been added to the language rather than being inbuilt. Consequenly, these features are somewhat awkward to use. Perl is also extremely idiomatic. While beginners can get their own code to work fairly quickly, the density of idioms often requires expert proficiency to decode.

Conclusion: Perl is a good candidate for scripting and linking but suffers from its weaknesses when used as a full development language. It idiomatic nature makes it difficult for users to read; a deadly problem in a project which wants outside contributions.


Strengths: Lisp has a good license and spectacular portability. It also has the advantage that it has been a de facto standard for EDA tool scripting for almost 20 years due to the ease of embedding it. This same use shows that Lisp can be a productive language for EDA tasks.

Weaknesses: Lisp is extremely dependent upon an external development environment for large-scale programming support. It also has no particularly good standard library upon which to build. In addition, Lisp has several features which impair its accessibility to non-experts. Closures, macros, and lack of syntax represent barriers to the non-expert even as they make some tasks which would be difficult in other languages extremely easy in Lisp.

Conclusion: Lisp, while a powerful language in many ways, is not suitable for general applications programming. It does have *extreme* strength in implementing programs which write programs. Problems which can utilize this unique strength should reevaluate language implementation choice.