This week we welcome Bruce Eckel as our PyDev of the Week! Bruce is the author of several books including Thinking in Java, Thinking in C++ and Thinking in Python among others. He also has a Programming Blog that is well worth a look. Let’s spend some time getting to know Bruce better!
Can you tell us a little about yourself (hobbies, education, etc):
My dad was my first employer. He built custom homes and had me do drudge work around the construction site. His head carpenter told me that it was “so I didn’t want to go into construction.”
This was a very effective strategy. I went to multiple colleges for 8 years and ended up with a BS in Applied Physics and an MS in Computer Engineering. Mostly because the thought of getting a regular job sounded like prison.
I chafed at the imposed structure of industrial-age management, and my goal became to escape from that world, which I did a few years later, becoming an independent writer, trainer and consultant. I’ve done that ever since. About ten years ago I started to revisit the whole idea of working for companies and have written fairly extensively about it in ReinventingBusiness. Briefly, I think we are on the cusp of a new age in work, and I’m struggling to help bring that about.
I live in Crested Butte, Colorado, where I hold small conferences and other events. In the summer I mostly mountain bike, and in the winter I’ve recently switched from cross-country skiing to snow biking (I stopped downhill skiing after breaking my leg quite badly; I miss it but the risk/benefit just didn’t work anymore). I have played the lead in a number of theatre productions in our very small town, and I have been experimenting with abstract painting for a dozen years or so. Recently I’ve been helping out with a business accelerator project at the ICELab in our nearby town of Gunnison. I’ve visited a number of incubators and accelerators during my travels but this is the first time I’ve seen one from inside.
I’m also a bit of a workshop junkie. I’ve probably taken 50 workshops at Esalen by now, and others elsewhere. For me it’s a vacation — not only do you go to a different environment, but you have new things to keep your brain occupied so you don’t start thinking about what you are taking a vacation from.
For the last couple of years, as part of my study of Teal organizational structures, I have been working on a practice called Non-Violent Communication, taking three week-long workshops and reading numerous books. This has been one of the many eye-opening experiences in my Reinventing Business pursuits.
Why did you start using Python?
This was sometime in the mid-90s. I had worked predominantly with statically-compiled languages up to that point. I was in Prague, teaching a seminar, when for some reason I started playing with Perl. It felt revolutionary; not just responsive, but also oriented towards making life easy for the programmer. Problem-solving rather than jumping through hoops.
It might have been a couple of months later when I tried looking at some of my “older” Perl code and discovered I couldn’t understand it. That kind of broke Perl for me, as readability is something I consider essential. Shortly after that I discovered Python and have been hooked ever since.
The first project I wrote was a code-extraction tool for my book “Thinking in C++.” This would extract the examples and create makefiles to compile them to test for syntax errors. I had written an earlier version in C++ and it took me two weeks. The rewrite in Python took a half-day (however, I understood the problem thoroughly so that gave me an advantage. Otherwise it might have taken a couple of days). Of course I expected it to run slower, Python being interpreted and all. But it ran faster! This was because C++ iostreams hadn’t had much optimization at the time, but it was one of many lessons about making performance assumptions. Now I just try doing it in Python without worrying about speed, and I can only remember a vanishingly small number of times when performance was an issue.
Ever since, I have been trying to move into the Python world and pull the hole in after me, and I keep getting foiled. Any support tools I create are in Python, however, and I actively stay updated on the newest features in the language. Python just makes me happy, so I continue to try to live there.
What other programming languages do you know and which is your favorite?
I seem to specialize in languages. The ones I know best are the ones I’ve written books about.
My first book was titled “Computer Interfacing with Pascal & C.” That was Turbo Pascal and the interfacing was from Kaypros (a CP/M machine) and early MS-DOS PCs. Yeah, I’ve seen it all.
I was a founding member of the ANSI/ISO C++ standards committee, from 89 or 90 to when the C++ 98 standard was published (the first one). I wrote several books on C++ and worked a long time with that language. I knew C++ 98 very well, having seen its development and spent time with lots of very smart people on the committee — this was much better than more graduate school would have been. However, the language has changed so much in more recent standards that I don’t know it at all. I basically haven’t touched C++ since the publication of “Thinking in C++, Volume 2.”
The reason I moved away from C++ was Java, which I learned by writing “Thinking in Java.” Although Java moved us forward significantly by introducing the virtual machine and garbage collection (up until Java, these ideas had never seen practical use in a language), Java started life hobbled by poor language design decisions that have haunted it ever since. People fall in love with the language for various reasons — sometimes it’s the only language they ever learn — and so have a hard time noticing these flaws, having nothing to compare with. But I see a huge impact in programmer productivity and maintenance costs. Just because Java has advantages over C++ doesn’t make it great.
Despite that, I finally got around to writing my final coverage of Java, called On Java 8. It took two years and is a comprehensive coverage of Java 8, more comprehensive, I think, than “Thinking in Java.”
In the past few months I’ve been working on “Atomic Kotlin” with one of the Kotlin compiler team members, Svetlana Isakova. I’m very impressed with this language — it actually fixes the vast majority of the complaints I have with Java, something I never thought possible. Often, Kotlin even feels Pythonic, high praise indeed. I’m starting to think Kotlin will be the successor to Java, and that’s what we put on the book cover. We hope to finish the book in a few months; it will be available as an ebook first and then a print book. The site for the book is here; right now it just goes to the example repository as the book is still under development but that URL will become a site for the book when it’s ready.
“Atomic Kotlin” was derived from the material in “Atomic Scala,” which I coauthored with Dianne Marsh who is now a director at Netflix. The “Atomic” idea is about the size of the chapters; we wanted to make them as small as possible, ideally covering only a single concept. This gives the reader an easier sense of accomplishment, but it also turns out to make it nicer to write. The book covers have mid-century atomic-age themes.
Dianne and I spent several years struggling with “Atomic Scala.” I’d say we both have a good grasp of the language, but even after all that time, not a great grasp. Scala was an academic, experimental language and as a result contains the artifacts of those experiments. It is in active use for certain projects. Through its experiments, it has contributed greatly to computer science knowledge. However, it ultimately doesn’t fit my vision for a language — there are too many jagged edges for my taste.
Kotlin learned from many other languages and incorporated features that were previously shown to be very beneficial in those other languages. Here’s a small, simple example: the original Java designers declared that operator overloading was “bad” because it was hard in C++ (which it was, but those Java designers just didn’t understand the issues or the landscape — Python had already demonstrated that operator overloading in the context of a garbage collector was easy). Scala added operator overloading along with an experiment that allowed people to make up new operators. This was a great experiment, and it compelled the Kotlin designers to follow the Python approach of (1) having a limited set of predefined operators and (2) overloading operators using text names so they were easy to search for. Kotlin is filled with examples of good design decisions like this.
I coauthored “First Steps in Flex” with James Ward, who was a tech evangelist at Adobe at the time. Flex was quite a well-designed language, but Adobe pulled the plug on it shortly after the book came out. Eventually they made it open source but by then it had lost its following.
I’ve had a couple of Developer Retreats on the Elm language, which is a radical departure from Javascript but I think has the greatest potential of anything I’ve seen for front-end development. Elm is a pure functional language based on Haskell which promises zero run-time errors and the fastest speed vs. any Javascript framework. I tend to be drawn to languages that try to leapfrog significantly over the problems of current, entrenched languages.
Another language I’ve been studying lately is Go. My friend Luciano Ramalho convinced me to come to the Go conference in Denver; he came up to Crested Butte afterward and we held a developer retreat on Python concurrency. I’ve yet to write anything in Go but I’m quite interested in the design of the language and the design process. My greatest interest is in their concurrency model, and I’ve even heard that it’s possible that something modeled after goroutines may appear in Python 3.7 or 3.8, and that could revolutionize Python concurrency.
What projects are you working on now?
- Atomic Kotlin. This book is my primary occupation right now, as we’re trying to get it out in short order.
- Thinking in Python. Although I had long ago given up on [Python 3 Patterns & Idioms](https://bitbucket.org/BruceEckel/python-3-patterns-idioms) for reasons described on that site, I kept getting feedback about how useful people had found what was there. Someone said they’d be interested in helping and we ended up having a developer retreat around it. We made progress but it’s still in its early stages. I will probably spend time on this once the Kotlin book is done, to try to get it into working shape.
- Concurrent Python. This is the project where I think I might make a significant contribution to the Python community. It’s big, complex, and ambitious, and the landscape is evolving. Concurrency is a topic I’ve struggled with for decades so it feels like a valuable pursuit. It’s also an area I think will make interesting conferences, workshops and seminars.
- The upcoming Winter Tech Forum. This is a self-organizing open spaces conference that explores many different areas of technology. We also get outdoors and have many interactive activities. It started as the Java Posse Roundup and evolved into the WTF when the Java Posse stopped broadcasting.
- Refining the idea of the Developer Retreat and doing more of them.
- My Programming Blog. This is where I talk about my technical explorations.
- [New Mindview Website](http://mindviewinc.com/Index.php). The old site could actually be thought of as an early form of a static site (using PHP to insert headers and footers and CSS for basic style elements), but with an amalgam of other technologies like Zope that have been accumulated over the years. I’ve finally started moving everything to static site generators (using Hugo) and it’s a huge relief because it makes the sites so much easier to build and maintain. There’s still a lot of work to do for conversion, though — this site has been accumulating for a long time.
- Starting a “Teal” organization that gets paid for developing open source. You can read about Teal organizations here. I’ve slowly been forming ideas around what kind of Teal organization I’d be excited about, and paid open source is a nut I’d like to crack. I think it will revolutionize the world when software developers can work full-time on what they love, and everyone can use the results.
- I keep wanting to start some kind of podcast, but the format and process keeps eluding me. I want it to be the kind of podcast I personally find fascinating, with all the annoying bits taken out.
Which Python libraries are your favorite (core or 3rd party)?
Click for command-line applications. The more of Armin Ronacher’s work I see, the more impressed I am. I suspect he develops his documentation either in parallel with the library, or perhaps even first, and that’s what makes his designs so good — the process of documenting forces him to really think about what works. I build a lot of command-line tools, and projects usually end up as piles of tools. The moment I switch to a different project I start forgetting how to use that pile. I’ve been looking for years for a good way to organize that pile and to ease the whole command-line mess, and Click just does it right, in my opinion. I’m a big fan.
Pathlib (part of the standard library). Creating command-line tools inevitably involves working with paths. I’ve been trying to imagine object-oriented paths for ages, and it’s always tricky to get the abstractions to work right. Pathlib is an example of very well-thought-out abstractions that solve a common problem in a way that really speeds up and simplifies my programming.
Regular Expressions. I know the joke about having a problem, trying to solve it with regular expressions, now you’ve got two problems. I’ve been using regular expressions long enough to know how to severely limit myself in what I try to do — I do whatever I can achieve *simply* with regular expressions. If you just leverage them, without diving in headfirst and trying to solve everything using regular expressions, they become a remarkably powerful tool that greatly amplifies your programming. The trick is in understanding and achieving that balance. I always treat regular expression programming in an exploratory fashion: Let’s first do something very simple, get that working, then slowly expand until you get a solution.
In the past, I’ve spent quite a bit of time with Beautiful Soup. I was writing books using Microsoft Word (to produce camera-ready pages with built-in table of contents and index generation), then converting them to HTML and processing that to produce an ebook (fortunately I no longer need to do that; I’ve switched to Pandoc Markdown, which isn’t perfect but does just enough). Beautiful Soup is an excellent example of the kind of messy problem Python is ideal for solving. Of course you could solve it in another language, but for some reason Python just adapts to messiness more easily.
How did you end up becoming an author of technical books?
Although I’ve always been drawn to writing (I spent my first year in college as a journalism major, before changing to physics), I saw it as a way to promote myself as a consultant and thus escape the fate of working as an employee. I began by writing magazine articles, back when there were magazines and they paid you for articles. My first book was made from a column I wrote for Micro Cornucopia magazine (long since gone). That was a lot easier and less-intimidating than starting a book from scratch, but once I had done that, other books became easier, and I just kept getting drawn into one book project after another. There were times when I fought it but I’ve come to terms with the idea that I will probably always be working on a book. It’s nice to have projects.
Whether writing was a good strategy for being hired as a consultant is another question. I’ve had periodic consulting jobs over the years — it seems to ebb and flow. I had people think that I was somehow too famous and important; they wanted to hire me but assumed I would be too busy. So writing might have actually driven away more customers than it produced. A more direct approach might have made more sense, but it seems to be my nature to go at things circuitously.
What are the top three things you learned as an author/speaker?
1) It’s about the audience, it’s not about you. Your job is to serve the audience, and anything that doesn’t accomplish this should be cut. I’ve seen many authors fall headfirst into the delusion that the audience is somehow fascinated with them and their lifestyle, and include those things in their books or presentations. When writing, every unnecessary word is work for the reader, so you must do your best to remove those — learn about something called “active voice,” which makes your writing not just more immediate, but also shorter (it also requires endless dilligence and effort).
There’s a fine line — occasionally some personal anecdote or observation or opinion will produce illumination for the reader or listener. And a big part of live presentations is the amount of energy you bring. But it all needs to feed back into the goal of moving the audience forward.
2) If you’re going to travel, stay longer and make it an adventure. Especially when I travel internationally, I want to have experiences that give me a sense of the place I’m going to. Because I require business-class flights for international travel, and those are expensive, I don’t usually ask for a speaking stipend in those cases. I do ask for my hosts to arrange other activities for me; these are usually things like speaking to local user groups and visits to companies and incubators etc., which I enjoy and learn from but also tend to benefit the conference in various ways. My hosts usually show me around and take me to meals as well, so the whole experience feels more like a vacation than work.
3) You must discover what motivates you to write and/or speak. I often get questions from people who want to write, or think they want to write. I usually find there is some underlying motivation, a thing that someone thinks writing will get them. Sometimes writing might be the path to that thing, but if you reveal it early you might find a path that’s a better fit for you. A good resource is Simon Sinek’s Start WithWhy, which helps discover your underlying motivation.
As far as the writing process itself, you’ll find lots of people stridently declaring that you must create a rigid schedule and write every single day, never let up on yourself, be tough, things like that. A very dominating view of the writing process that fits with our Western hierarchical mindset. What I find interesting is that I don’t usually find the writing that comes out of such a process to be particularly interesting or compelling. Almost as if by making writing into work, it sucks the life out of it and turns it into work for the reader.
If I’m not inspired to write, I don’t think I do very good work. But it doesn’t matter, because without inspiration I don’t want to do it. Sometimes the inspiration is trying to unravel a particularly thorny problem, sometimes it’s just that it makes me feel good to be productive. I think there are many writers who work when they’re inspired — but they don’t waste time declaring that this is the “right” way to write, or laying out a rigid set of rules about how to do it. The result is a kind of survivorship bias, where the only advice you hear is about the domination process for writing.
Is there anything else you’d like to say?
Regarding consulting: I would like to do more of it, but I’ve come to realize how tricky it is to find the right match between consultant and customer. There are a large number of activities that people throw into the “consulting” bin, from glorified temp workers to high-level advice (often so high-level that it can’t be effectively used). I’m in what I like to think of as the “practical-advice-and-helping” category. Contrast this with fly-by consulting, where you come in, say the team or company is doing everything wrong and should instead be doing it my way, and fly away. Instead, it requires understanding where a group is and what kind of changes they are ready for/capable of. Often these changes are much smaller and less dramatic than the kind of thing a fly-by promises, but they can produce actual improvements and benefit.
I’ve always charged a significant fee, to compensate for the difficulties and stresses of travel and thinking on your feet. But what if work were a joyful experience? If a company was strained by the fee, I’d happily charge less and give up the higher-paying, more stressful jobs, in order to work in that rarified, joyful atmosphere. The puzzle has always been how to even find such organizations.
Thanks for doing the interview!
Pingback: PyDev of the Week: Bruce Eckel - Codangoâ„¢
Thanks – that was a great interview. Mountain-biking in Crested Butte? Bruce is doing it right. Had the pleasure of riding the 401 in 2000 and it remains the most epic ride of my life.