Being Idiomatic in code vs Dogmatic and why the distinction is important

Question

After we finished the final in one of my C++ courses, there was one more optional lecture given (obviously the final was already done so most people didn't go), but I didn't have much else to do so I went.

My professor talked at length about the differences as a software engineer in being dogmatic in a language vs being idiomatic. He mentioned that dogmas are something to be taken with a light touch. "A good programmer makes their design patterns and code styles known, but questions each decision as practical vs dogmatic. Is this developer injecting OOP in this project because he's being dogmatic, or idiomatic?"

Idioms have to do with writing a language in a way that's generally accepted as "best practice" by the language. When you're learning a spoken language, a speaker may translate one-to-one from their native language, which may get the gist across, but a native speaker of the other language would probably phrase it in a different/better way.

The professor urged us to learn the idioms and question the dogmas. I think i understand what he was getting at, but am still confused as to the difference and how it applies to coding.

Would anyone be able to sort of clarify what he meant, and maybe provide some examples as to blindly following dogmas versus learning idioms.

Thanks!

Answer 1

After seeing that no one is answering after a few days I will lead you down the trail of what hopefully will be the next steps in a journey that will enrich your coding ability in the spirit of the door your professor opened.

First my background so you can understand that this is not an off the cuff answer but one earned through decades of coding. My first computer was an Atari 800 and my first time programming for a course was with Fortran 77 using a key punch machine, so yes I have lived much of the computer revolution.

When I started programming, OOP, functional programming, machine intelligence and such were not words used in colloquial talks about programming, now those words are as common an ants.

Probably the most eye opening experience I had related to idiomatic vs dogmatic way of coding and forcing myself to think about everything along the way was when I translated some neural network code from Python into F#. Since neural networks rely on matrices that are mutable and Python is easy to work with such mutable matrices, it is easy to work with neural networks with Python.

F# is functional and one of the main idioms is that of immutable data. Knowing it would be a very bad idea I created an immutable matrix in F# and ran the code. Needless to say the memory usage was pegged and IIRC quickly resulted in a stack overflow. Obviously the matrices had to be coded as mutable and this took me into a world where I felt that I was turning my back on the reasons for using F#. In the end the code worked as expected and I learned a lot from the experience, it reminded me of this quote

Learn the Rules Like a Pro, So You Can Break Them Like an Artist. by Pablo Picasso

---

Now to answer to your question

Being Idiomatic in code vs Dogmatic and why the distinction is important

If you write code that will be written and read by others, especially in a production environment, then you need to write code that first works correctly then code that can be easily understood so that it can be maintained. If you write non-idiomatic code in a programming language then it is harder for others to understand, often indicates that you do not fully understand the programming language and is often hard for code analysis tools to analyze because it could be a corner case they can not reason about which could result in a bug getting into production.

If you code in multiple languages after a while you will see that each language has a community around it and they often have different ethos. As a point of fact, look at how each programming language typically has a different tool chain. Not only does one need to learn the idiomaticness of the language but the ethos of the community.

If you want your code to have a long and productive life in production then write it so that the community will use it, understand it and possibly note it as an example. If it is not idiomatic, it tends to have a higher chance of going to bit heaven and replaced with something idiomatic.

---

A word that leads to many examples of idioms outside of programming is canonical.

One of my favorite and simplest examples of this is when writing integers.

The canonical form of the integer one is 1.

but these are also valid forms of the integer one.

01
001
0001
00001

Imagine a world were users did not use the canonical form of the integer one and instead used a different representation of numbers, e.g. Roman, Babylonian, Mayan, etc. (ref)

Now image going to the a grocery store and trying to figure out the price of something written with a different number system.

---

Side note:

When translating the code I asked a few questions on SO, here is one of the main ones, the others are around the same time frame.

How to determine type of nested data structures in Python?