PyDev of the Week: Thomas Passin

This week we welcome Thomas Passin as our PyDev of the Week! Thomas is the mastermind behind the GF4 Graphics Calculator application. Thomas also helps out with the Leo Editor.

Let’s take a few moments to get to know Thomas better!

Can you tell us a little about yourself (hobbies, education, etc):

I’m retired from regular work, and my current non-programming hobbies are hiking mountain trails, baking bread, and reading. I was serious about photography for about a decade, but that has faded out. I also used to play the classical guitar, but with a certain number of years on me, I’ve lost that last bit of fine motor control needed to make it enjoyable.

I went to MIT for undergraduate work, then Masters’ level work in physics at the University of Chicago. I’m self-taught in programming. Until 2006, I wrote software to help me in my work, not to create products per se. In 2006 I was asked to pick up and update an existing project – a java project. It turned out it couldn’t really be updated and I ended up re-implementing it with new algorithms and data sources.

That project was a system to run under Tomcat, so it had to be in java. However, I wrote almost everything except the actual servlet interfaces in Jython. The computing, output formatting, database access – all in Jython. What a blessing to be able to use Jython instead of doing everything in java! One of the interesting things about the project is how it calls from java into Jython classes, and from Jython code into java.

I’ve been updating and maintaining that system ever since, even after I retired.

Otherwise, I spent many years working requirements, Systems Engineering, and Enterprise Architecture. They helped me to value good organization and simplicity in software. I also learned that there are always requirements, even if they haven’t been written down and even if the project is a small personal one.

Why did you start using Python?

I can’t remember anymore how I came to start using Python. It was around 1998, about the same time I started working with XML. Before then, the language I had used the most was Turbo Pascal, which I liked a lot. I had actually written a DOS graphics mode windows manager using Turbo Pascal, back in 1989 – 1990. It had movable and overlapping windows, drop-down menus whose items could be disabled, simple dialog boxes, mouse handling, most of the basics. I wrote a number of programs using that framework.

When I encountered Python, apparently my brain had some real affinity for the way it worked. It was so easy to understand and write (originally) simple programs for! It quickly became my program of choice, although I later had to do a few projects with java and C#. By contrast, c/c++ seem to be at odds with the way my mind works, and they are always struggles for me. There’s too much boilerplate that gets in the way of understanding.

What other programming languages do you know and which is your favorite?

My first real exposure to programming was in 1972 with a DEC PDP-8I. I had been asked to design and build a piece of hardware that would have a number of parallel channels, originally 16 but expandable to 64. I implemented it mostly with series 7400 TTL logic circuits. But I needed to test it. I knew it would eventually be interfaced to a PDP-10. I had access to a PDP-8I, which had some similarities to the 10.

I learned enough PDP-8I assembler to write code to test and exercise my system. Then I discovered that FOCAL, DEC’s answer to BASIC, had slots for three (unimplemented) commands and I used those slots for commands that we could use to exercise and control my system with FOCAL, which was a lot easier than any alternative.

In the mid-1980s we needed to use a waveform digitizer (there were no high-performance digital interactive oscilloscopes then; this was basically a single-shot oscilloscope with no display). We had a high-end CPM computer – a 8-bit Z80 processor with all 64k of RAM – but at least it had a set of graphics primitives built in. Our department computer guru had decided that FORTH would be a good language for controlling the device and getting that data out. I would be the one to use the system, so I had an interest.

Our part-time programmer (not the guru) couldn’t get the controller working (an integrated circuit) and I got interested since I had interfaced my own device the previous decade. Long story short, we got it working, and we learned how to draw a graph of the digitized data. This was essential, otherwise, you couldn’t know if you captured your transient data or not. I went on to write an extensive program in FORTH to work with the data that ended up being the ancestor of my GF4 Graphics Calculator (see below for more).

I’ve written something in at least these languages: assembler (Z80, x86, and PDP-8I), FORTH, FOCAL, BASIC, Turbo Pascal, C#, VB for .NET, a bit of FORTRAN, java, javascript, and of course Python/Jython. I’ve also worked extensively with XML, XSLT, and HTML, a little AWK, and use some SQL.

My favorite language, far and away, is Python. Javascript is all right – it gets a bad rap from many people, but I find it reasonable to work with. You don’t need to use all its features, after all, just the more Pythonic ones. If I had a need for much faster programs I’d seriously consider Julia – whose syntax and REPL have been influenced by Python.

What projects are you working on now?

I work on my own GF4 Graphics Calculator (more below), I still maintain and develop the Tomcat servlet application I mentioned earlier, and I’m fairly actively involved with the Leo Editor.

Leo

Leo is a massively capable piece of software, the brainchild of Edward K. Ream (“ekr”), who was featured in this series a few years back.

I won’t get into much about what Leo is since ekr talked about it in the linked post, except to say that it is hard to describe! That’s because it is so programmable and flexible. It’s a programming editor and IDE – especially suited to Python programming – and an ideal environment for writing all kinds of documentation, especially Sphinx documentation.

What many people don’t realize, even some experienced Leo users, is that Leo can be a framework for all kinds of serious non-IDE applications (written in Python) because it’s so scriptable and provides so many services. For example, I have written a browser bookmark manager that runs in Leo. I use it most every day.

Leo is somewhat like EMACS in its extensibility, quite different in its organizing principles, and uses Python instead of LISP.

Anyway, I use Leo all the time – I’m composing these interview replies using it – and I have contributed a number of small improvements to its internals, like highlighting of the current line, for example. I’ve also contributed several plugins.

Leo’s web site URL has changed since ekr’s 2018 interview. Find it at https://github.com/leo-editor/leo-editor.

GF4

I’ll say more about the GF4 project below. When I’m programming, if I’m not working on Leo I’ll probably be working with GF4, either the programming end or doing data analysis with it. It too is written in Python. I manage the code base and the documentation with Leo.

What’s the origin story of the GF4 Graphics Calculator?

As I mentioned earlier, GF4 grew out of earlier work, a FORTH program for a CP/M machine that captured and displayed transient waveforms from a waveform digitizer. As I started to use it in the lab, I found I wanted to do more mathematical processing with the data – overlaid waveforms to compare, averaging, adding and subtracting, differentiation and integration of waveforms, and so on. So I kept adding functionality.

I was very familiar with Hewlett-Packard’s “reverse polish notation” (RPN) hand calculators, and FORTH is of course also a stack-based language. So it seemed natural to use an RPN-style interface. In those days, you typed commands on a one-line command line, and the plots were displayed in the rest of the screen. The waveforms were 512 dots across the screen, with the data being 8-bit integers. The FORTH program called on the built-in graphics package of the computer. The waveforms were treated much like numbers in an RPN calculator with a stack of depth two.

I didn’t name the program in those days, but it would have been GF0.

Some years later I was again working extensively with 2-D plots, although from a variety of sources. By that time we had PCs and Turbo Pascal. I re-implemented the functionality with Turbo Pascal. Later, when Turbo Pascal came out with a better set of graphics primitives and added object orientation – I think it was version 5.5 – and I had written my DOS graphics mode windows manager – I re-implemented it again. This version had more advanced math routines, including LOWESS smoothing and Fast Fourier Transforms. I was very happy with that version, although accessing all the commands through drop-down menus was not quite optimum. And of course, DOS graphics at that time had only a resolution of 320 X 200 pixels and 16 colors. This version was GF2. It had some specialized capabilities to help with some of the work I was doing at that time. GF2 was my first real foray into object-oriented programming, and it had a companion program GSTAT that shared most of the code base. GSTAT had more statistical functions, but without the work-specific functionality.

Later again, Turbo Pascal morphed into Delphi and also provided Windows programming capability. I ported GF2/GSTAT to Delphi/Windows. Of course, the event loop, menu construction code, screen painting, etc. were very different, but I was able to keep the organization and most of the actual code unchanged. This was GF3. It worked well enough but I never really liked it. This would have been around the year 2000.

Finally, a few years ago I decided to re-implement the program again, this time in Python/Tk. I used Matplotlib for most of the plotting-specific code that for earlier versions I had written myself, and Numpy and Scipy for many of the math routines that I had also written for previous versions. Once again the organization of code modules was nearly unchanged, although I found some sneaky ways to break up some of the modules into smaller pieces. This version is what I call GF4.

Now that the program is written in Python, it’s much easier to experiment with and add capability. There is a change to the mechanics of the user interface, which is now based on a side window that contains command buttons, rather like a hand calculator keyboard. This works much better than the old drop-down menus. The program is more of a pleasure to work with than ever before.

The code’s organization is pretty good, and Python being so easy to work with it was nearly trivial to add plugins and an extended help system to the program.

GF4 is on GitHub as an open-source project at https://github.com/tbpassin/gf4-project.

Which Python libraries are your favorite (core or 3rd party)?

It’s hard to apply the term “favorite”, but I use MatplotLib and Numpy extensively in GF4. GF4’s GUI is done with Tk, although I can’t say I’m terribly fond of it. Leo’s GUI is handled with PyQt. PyQt can be hard to learn how to use – since it’s so big and complicated – but its developers have tried hard to have consistency across its classes and methods. This is a good thing. If I were to start GF4 over again, I would consider using PyQt for the GUI.

What are the top three things you have learned so far while working on GF4 Graphics Calculator?

1. A good metaphor helps a great deal with a good user interface. Try hard to keep interactions with the program consistent. The Graphics Calculator changed massively over the years in terms of language, implementation, and user interface, but the underlying metaphor of an RPN calculator for graphs has stood the test of time – over 35 years by now.

2. Reworking and refactoring helps to keep a program’s foundation strong and adaptable.

3. Organization is more important than code details in most cases.

Is there anything else you’d like to say?

Mostly a call for simplicity and good organization as far as possible. My motto is “Start simple because it’s only going to get more complicated.”

Always remember Brian Kernighan’s famous quote:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Thanks for doing the interview, Thomas!