Moving the kernel to modern C [LWN.net]

Moving the kernel to modern C

Posted Mar 4, 2022 7:42 UTC (Fri) by wtarreau (subscriber, #51152)
In reply to: Moving the kernel to modern C by marcH
Parent article: Moving the kernel to modern C

> But operator overloading and inheritance are very different: with them you don't know _which source tab in your own editor you should look at_! In other words, you get lost in _your own code_.

Exactly. More than a decade ago, one of our project died after the ruby developer who was leaving admitted he was totally unable to tell us which assignments or operations were causing database accesses! Because doing a=b+c could *possibly* perform requests ina database to fetch some values or store the results. It became so deep that the code was a living being of itself that noone could tame anymore, and fixing bugs became totally impossible. Definitely a very bad idea. The only thing it provides is ease of *writing* code, but we must never forget that we write once and read it many times.

Moving the kernel to modern C

Posted Mar 4, 2022 14:36 UTC (Fri) by dvdeug (guest, #10998) [Link]

= or + doing database requests is insane, but so is naming the function f() or add() or shelia(). I was not familiar that any dynamically typed language had operator overloading; in a statically typed language, the types of a, b and c would have made automatic renaming possible. Clarity of naming is important, and I'd argue that there's a conservation of information; the more ambiguous the types, the more explicit the function naming needs to be to compensate.

> The only thing it provides is ease of *writing* code

One of the recent Scheme additions was writing (add (times a c) b) as {a * c + b}, because it actually is easier to read code like that, and

"hi " + name.toString + " and good morning"

is also easier to read than

"hi".append(name.toString).append ("and good morning")