Hello to all Clojure lovers. We are happy to be part of this community. As the year 2023 is coming to an end, we decided to have our last Clojure Corner with Yehonathan Sharvit the author of Data-Oriented Programming: Reduce Software Complexity.
Ela: Hello everyone, Yehonathan Sharvit thank you for accepting our invitation, please let me introduce Iain Wood our Corner leader, and Jiri Knesl, Flexiana founder. I hope you guys enjoy your time here.
Yehonathan: Ready to go!
Iain: Yehonathan, you are best known for your book, Data-Oriented Programming. Could you tell us how you came to write it? Did you always want to be a writer?
Yehonathan: Ever since I was a teenager, I’ve always looked up to book authors with a kind of awe. I used to think, “Wow, these folks must be super smart because they write books!”
So, you can imagine my excitement when Manning approached me to write a book for them. But I also had this mix of emotions – excitement and fear, like, “Can I really do this?”
Turns out, the whole experience taught me something valuable. It’s not just about being super smart to write a book. I realized that anyone with passion and dedication can actually pull it off.
Iain: So how did Manning come to approach you? And what was it like working with them?
Yehonathan: Manning’s acquisition editor reached out to me via email and expressed their interest in finding an author for “Get Programming with Clojure”. I was not just interested, but incredibly honored by this opportunity. So, we set up a Skype meeting (audio only) where they introduced me to their “Get Programming with” series and walked me through the book writing process. It’s quite a substantial amount of work, typically spanning about two years, and the chances of becoming a best-seller are quite slim. However, they assured me that I would receive support in the form of a mentor, a technical writer, and a content editor to guide me throughout the journey.
They also mentioned the relatively low author’s royalties (around 10%), but that didn’t bother me at all because my motivation wasn’t primarily driven by financial gain. Instead, I saw it as an opportunity to fulfill a childhood dream.
They requested that I send them a proposal containing the book pitch, the target audience, and a table of contents. I was so thrilled about this opportunity that I managed to send them everything they asked for within just a week. My expectations were modest, but to my great surprise, they gave me the green light to move forward.
Iain: Was “Data-Oriented Programming” the first thing you wrote?
Yehonathan: My journey into blogging kicked off in March 2016, fueled by my deep enthusiasm for Clojure. The language had a unique allure, and I was eager to share the fascinating discoveries I was making with the wider community. Things like destructuring, immutability, and macros were some of the captivating aspects that I wanted to delve into and explain to my readers.
One neat trick I found was embedding a live code evaluator (known as Klipse) right within my articles. It made it much easier for readers to grasp the concepts I was discussing.
One of the highlights of my blogging adventure was when I published an article titled “Rich Hickey for dummies,” and it miraculously made it to the front page of HackerNews. However, this moment of triumph was short-lived. Just a few minutes after publication, a member of the Clojure core team contacted me, pointing out that I couldn’t use Rich Hickey’s name in the article. Consequently, I had to rename it to “The concepts behind Data-Oriented Programming.” Unfortunately, the revised title didn’t capture the same level of attention as the original one.
Iain: What would you say it takes to be a writer?
Yehonathan: I am not sure I am a good writer but I am definitely a better writer than I was when I started writing my book. To share what I’ve learned, I wrote a blog post titled “A Hundred Things I Learned Writing My First Technical Book.”
The standout lesson for me is the importance of clarity in writing, echoing my mentor at Manning’s philosophy “A bad writer makes his readers think he is smart. A good writer makes his readers think they are smart”.
When writing a chapter, a well-thought-out plan is indispensable. On average, a chapter takes me 20 hours, with the majority of that time dedicated to developing a comprehensive plan. And I forced myself not to write a single line before the plan was completed.
It’s also important not to get too attached to your drafts. Being open to criticism is vital, as it can lead to significant improvements in your work. At Manning, I benefited greatly from the critiques of two professionals (a technical reviewer and a content reviewer ) who reviewed each chapter I wrote, ensuring the text was clear enough.
In summary, clarity, planning, and openness.
Iain: “A bad writer makes his readers think he is smart. A good writer makes his readers think they are smart”. I love this
I would like to ask more about your book, but I haven’t finished reading it yet. So, I will switch tack for the next question.
There seems to be so much potential for Clojure and yet it still sort of flies under the radar as far as the mainstream is concerned. How do you see the future of the language?
Yehonathan: I don’t think I have something interesting to share about the future of Clojure
Iain: Data-Oriented Programming was intriguing and very readable. Is there a sequel in the pipeline?
Yehonathan: Not for the moment.
Jiri: How do typical OOP developers react to data-oriented programming when they hear about it for the first time?
Yehonathan: I have seen mainly two kinds of reactions:
- People who are so attached to how they are used to writing code that they cannot even consider a different paradigm.
- Open-minded folks who are willing to consider a different approach, but are suspicious about the feasibility of writing code at scale without using static types.
Jiri: For example, when I am now working with OOP languages, I work in Clojure-ish mode (which you would probably name data-oriented programming) where data are separated from classes. Where most OOP folks would say I have an anemic model, I break SRP and encapsulation principles.
How would you react to people who will argue this way?
Yehonathan: I’d say it’s a trade-off between safety and flexibility:
- When you are in total control of the pieces of data you process (like when you write a compiler for instance), OOP’s safety guarantee is an advantage.
- But your program processes information that comes from the outside, the flexibility of DOP is an advantage.
Jiri: Absolutely. Also, encapsulation of similar data structures in different classes/objects might either lead to code duplication or mixins/traits that have many disadvantages.
Are there any companies you are aware of that have adopted DOP in non-functional programming languages?
Yehonathan: That’s a great question. Michael Nygard in his foreword to my book mentions that he was doing DOP in Java, even before Clojure was invented. But besides that, I am not aware of any companies adopting DOP nowadays in non-functional languages.
Jiri: Interesting. I think many people who move back to OOP from FP might adopt a similar style.
How does work with SQL databases work in DOP?
Yehonathan: We simply get rid of ORMs! We receive data as lists of maps.
Jiri: How do you represent business logic? Is there any concept of entities that are based on a domain and not on the database structure?
Yehonathan: There could be. In that case, we simply write a stateless function (super easy to test) that transforms the DB entity into the BL entity.
Jiri: I think this is very similar to Clojure projects I see.
How do you structure the web applications you develop?
Yehonathan: I think this question is decoupled from DOP as a programming paradigm.
Jiri: In a way, it is. You can do the MVC app with DOP or with a more OOP approach with ORM.
But there are approaches, that are very different and might not work well with DOP. For example ASP .NET WebForms or PowerBuilder DataWindow.
Yehonathan: Then I don’t know how to answer this question
Ela: One last question before closing our last 2023 Clojure Corner,
How do you see 2024 for Clojure and functional programmers?
Yehonathan: Here’s a prediction for 2024: some cool library/framework will emerge and it will be inspired by Clojure.
As the year 2023 is coming to an end, you can take your time during this joyous holiday to read our other Clojure Corners and plan for your next project with us.
