I like reading blogs’ older posts. Especially when I discover a blog and I find their view on a subject that I was interested in back when the author wrote the post. For example I like reading posts about downfall of Netscape or Adobe Flash. I will write a complete post about that. It’s been a while that I’m reading software/CS related blogs for about 3 hours a day and I wanted to write one major thing that I have learned from reading hundreds of old blog posts. That pretty much “Every problem that we are solving today, people faced a version of it in the past”. I’m not talking about the stuff, rather I’m talking about the challenges.
Housing in Toronto has become a big issue in the past two years. You hear news about the bubble everyday. Most people say it was easier to buy a house 20 years ago. There are jokes about how old people bought a house with selling an onion. I also taught like that. That conditions were really different and people did not have any difficulties in two decades ago. Until I read this post by Lawrence Kesteloot. In the post he is mentioning the exact same problems that we have today he had in twenty years ago. Actually the vocabulary has not changed so much either; such that if you don’t know the year the post was written you might think it’s a recent writing.
It is true that the things are changing with the time but the main background problems persist. Let me give you some examples. With the rise of K8s there is a hot debate today between micro-service architecture and monolith applications. But you know what? the same issue was there the in 60 years ago when people wanted to decide how to design OS kernels. You could create a modular kernel consisted of many simple modules or you can create a big kernel which has lots of features. You know what? The old problem is as hard as the problem today! Having lots of modules means more communication needed but a big kernel could save that, but a big kernel is going to be a mess to develop and debug. Similarly, whoever thinks the new trendy way of micro-serivces is a superior to monolith appsin every term, is just a fool. Emacs vs vim or windows vs unix have pretty much the same design decisions.
Golang is becoming more popular every year, because it has lots of good design decisions for programmers as smart human (but not too smart). I confronted two identical axioms in Go and Unix: “Be liberal in what you accept, and conservative in what you send” in Unix Philosophy is the same as “Accept interfaces, return structs” in Go. Which means the brand new popular problem solver Golang is doing like the way the good old Unix did. Uncle bob writes well:
Every new generation likes to think that their world is vastly different from the generation before. Every new generation is wrong about that; which is something that every new generation learns once the next new generation comes along to tell them how much everything has changed.
Robert Martin
What I realized from the similarities between the design problems in the past to now, is that it is not possible to make good design decisions for a new software without looking at the previous softwares. When a new language is released some trendy people just want to try that and say everything about the new one is perfect and the old ones are totally garbage but you know what? C, C++ have stayed for a while and are going to stay for a long time in future.