This interview with Unit Testing Succinctly and Imperative to Functional Programming Succinctly author Marc Clifton is part of a series of Q&A blog posts with our Succinctly series authors.
Why write a book for Syncfusion?
I love technical writing at least as much as I do designing apps and writing code. When I first encountered Code Project in 2002, I made it my goal to be the number one article author (by count), and five years later achieved that goal. With 178 articles at the time of writing this, you can see that I’m pretty addicted to technical writing. So, when Syncfusion contacted me to write an e-book on unit testing, it was natural for me to jump at the opportunity, especially because I really appreciate that Syncfusion offers the e-books for free to the community. I’ve also gotten to know some really great people at Syncfusion and have had a lot of fun conversations, so all around, I’m impressed and feel a certain loyalty to them. Since the book on unit testing, I’ve also written an e-book on transitioning from imperative to functional programming. I think this is a really important topic because functional programming requires a very different mindset when it comes to both software design and its implementation, so I really appreciated the opportunity to voice my thoughts through an e-book.
Are these books your first technical manuals?
No, I’ve been writing technical manuals since my 20s. The funny thing is, users said my manuals were a pleasure to read, but they didn’t really need to read the manual because my software was so intuitive. Back in the Reagan days, I wrote a lot of acceptance test procedures for the low light and multispectral camera systems we were developing. I really enjoyed working with the hardware engineers and marketing people on really getting the content as clear and succinct as possible for the end-user. One of the more interesting projects was writing the acceptance test procedure for MX Missile Train’s video surveillance security system (as well as having written a lot of the firmware). The stories I could tell…
What is your favorite outdated technology?
Pen and paper. There are times when it’s really useful to work out on paper a complex problem, whether it’s architecture or an algorithm. It’s faster, the surface is bigger (I tend to use large poster paper when working out stuff), it’s easy to make side notes and diagrams to express ideas, and in particular it’s easy to make notes about edge cases, and there’s something about also being a bit more physically active (usually standing up at least) that helps to get the creative juices flowing, as opposed to working something out sitting in a chair. Also, it’s a lot more satisfying to crumple up a bad idea and throw it to the cat to play with than to hit the delete button on the computer.
Marc Clifton and the ever-useful pen and paper
What have you learned since writing the e-book about functional programming?
It’s a cliché, but I’ve learned that there’s so much more to learn. The e-book Imperative to Functional Programming Succinctly covers just the tip of the iceberg. For example, design patterns are completely different in functional programming and I also think that design patterns in general are becoming outdated—certainly with functional programming, the idea of “thought patterns” seems more relevant. With the Web Servers Succinctly book I’m currently writing, I learned that there are a dozen different ways, if not more, to write a web server, and there is no “right way,” only the right way for the particular web application at hand—which is an interesting conclusion and indicates to me that there’s a need for a lot more flexibility (think modularization) with web server implementations.
Do you have another reference that you would recommend to people interested in functional programming and unit testing?
Tomas Petricek’s work (not just in functional programming) is amazing. Read his blog; read his books. Also, learn other functional programming languages. It really helps to understand more deeply some of the concepts when working with pure functional programming languages like Haskell, and impure functional programing languages like Erlang, Julia, and Scala. Each has unique things to offer that strengthen a developer’s understanding of functional programming. However, don’t get fooled into thinking that languages like C#, Ruby, Java, or even JavaScript are functional programming languages—they’re not. They just happen to support some functional programming-ish constructs.