Thanks, Erik. This article triggered memories of times long past. Only Fortran and Algol substantially preceded the start of my career. I've never used Algol, but Fortran (formula translation) proves my belief in "if all you have is a hammer, everything looks like a nail". Fortran was created as a mathematical computation language, not as a general purpose language.
In the early 1980s, I got a call from the now defunct Prime Computer, in Natick, MA. Without any consultation with corporate marketing, their engineering organization had written a CODASYL (hierarchical data model) DBMS and Prime wanted to turn it into a product. Unfortunately, because Fortran (the language the engineers knew and used) was so ill-suited to the task, the DBMS was painfully slow. Someone in engineering had the idea that turning it into a distributed DBMS would spread the processing load among multiple computers and make the DBMS faster. They wanted me to turn it into a distributed DBMS.
I told them that I was skeptical of the potential of the idea, but they asked me to try anyway. I told them I'd look into it, but made no promises. In those bygone days, networks were very much slower than they are today. I spent a few days modeling alternatives and running the numbers proving that, with the network latency and the extra computation and wait states necessary to manage concurrency and data consistency, a distributed version would have been even slower than the original. I produced a report with my calculations and pretty graphs and presented it to them. They didn't believe the numbers and wanted me to take the contract anyway. I told them that I wasn't willing to waste their money and declined.
Years later, I met a couple of former Prime employees at a conference. The DBMS came up in the conversation and I asked what happened after I declined. They told me the company spent 6 million dollars before finally giving up.
"Microprocessor cache behavior is a big part of performance of computers today. Completely abstracting away memory allocation and freeing creates an obstacle to tuning performance." I don't disagree, but I am concerned about the hardware-specific nature of caching being in the application code. I guess that it's one of the differences between your world and mine. My Android phone has more RAM than the 32k of the first IBM mainframe I worked on.
Sorry, I've had bad experiences with gratuitous optimization. I had a C programmer, at the first company I founded, who cost us a lot of time and money because he compulsively optimized code to the detriment of readability, reliability, and portability which were much more important to us. That really irritated me because I was funding payroll from my own personal funds. He almost cost us the company.
What do you think of Kotlin?
