Home > Community > Blogs > Custom IC Design > skill for the skilled rule of english translation
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Custom IC Design blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

SKILL for the Skilled: Rule of English Translation

Comments(4)Filed under: Custom IC Design, SKILL, Team SKILL, LISP, clarity, Norvig, English translation

An obvious criticism of my previous post SKILL for the Skilled: Making Programs Clear and Concise is that clarity is subjective. What is clear to one person may be confusing to someone else, especially to someone who is accustomed to doing things the hard way.

I'd also suggest the converse is also true. If you are accustomed to using a programming language that encourages an imperative style, you may become convinced that more confusing code is clear.

Several readers of this blog referred me back to an iconic author in the field of computer science, Peter Norvig. The book Paradigms of Artificial Intelligence Programming is a good resource as a survey of many different non-trivial but easy to understand programming problems. The book is almost 1,000 pages and belongs on every SKILL programmer's bookshelf. The name of the book is generally agreed to be misleading as it turns out not to be much about artificial intelligence, but rather about programming style.

Norvig also presents a nice test for clarity in his presentation called a Tutorial on Good Lisp Programming Style. The rule can be found on pages 53 and 54 of that set of slides.

Rule of English Translation
  1. Start with an English description of the algorithm.
  2. Write the code from the description.
  3. Translate the code back into English.
  4. Compare 3 to 1.

From this description the implication seems to be that the smaller the difference detected when comparing 1 and 3, the better job you have done at writing a clear and concise program.

Let's use SKILL as an example rather than Common Lisp as Norvig does. Suppose we want to write a SKILL program to do some analysis of the instances in a layout cellView.

Start with an English description of the algorithm

Given a list of shapes and a layer name, find the subset of shapes on that layer.

First attempted implementation

The following implementation is an imperative approach. The reader sees how the calculation occurs but has to think a while to figure out exactly what is being calculated.

(defun shapes_on_layer (shapes layerName)
(let (stack)
(foreach shape shapes
(when (shape~>layerName == layerName)
(push shape stack)))

Translate the code back into English

Given a list of shapes and a layer name, start by initializing an empty stack, iterate over the shapes. If the shape is on the given layer, push it onto a stack; when finished iterating return the elements on the stack.

More clear and concise implementation

This implementation reads very easily, and it is clear to the reader what is being calculated.

(defun shapes_on_layer (shapes layerName)
(setof shape shapes
(shape~>layerName == layerName)))

Translate the code back into English

Given a list of shapes and a layer name, return the set of shapes which are on the given layer.

We can see that when translated back to English, the second of the two implementations looks much more like the original problem statement.


Of course there are exceptions to every rule (except perhaps this one). Sometimes we must sacrifice clarity for efficiency--particularly if the programming language is not as high level as SKILL. If you find the programming language you are using tends to more often force you to write code in the style of the first two examples, rather than the second, you should conclude that the strength of your programming language is NOT its clarity and expressiveness.

Incidentally, I tested the two implementations above on my Linux laptop to see which one is actually faster. I tested both the imperative and functional style implementations on a cellView containing 32,768 shapes, 20,480 of which are on "Poly" layer. The more concise functional style implementation found the "Poly" subset about 7% faster than the imperative style implementation. In this case there was no run time performance penalty for clarity.

The SKILL programming language allows you to write very expressive code.

See Also: Jim Newton for Team SKILL


By Kari on December 7, 2010
Great article. I often start my programs with an English description, but have never thought of translating the code back to English to check the clarity. I like it!

By Team SKILL on December 7, 2010
Hi Kari, many thanks.  I'm happy that you find the advise useful.  I hope you're able to find the other references I mentioned.  I'll try to include more examples from Norvig (and others) in upcoming articles.

By nazia on January 8, 2011
nice article about the translation i really like this and i hope that every one will like this

thanks to share with us

By Team SKILL on January 9, 2011
Hi Nazia,  I'm glad you liked the article.  There are plenty more to come.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.