3 ms·
>Naturally it was only due to the current shortage of those mythical C developers that never make memory corruption mistakes. the repetition of this cutesy lin
by serf 6y ago
>Naturally it was only due to the current shortage of those mythical C developers that never make memory corruption mistakes.
the repetition of this cutesy line lately almost feels like there is some programming language astro-turfing campaign going on somewhere that I haven't become fully aware of yet.
i'm not saying that it's wrong -- safe languages producer safe(r) products -- but to be upset about the unsafe nature of C is, in my opinion, to be upset about the very thing that makes C a powerful language.
The host of foot-gun abstractions and abilities that come along with C are exactly the kinds of reasons why someone would choose C for a project in the first place : flexibility and a sort of 'freedom of expression' that is unmatched everywhere else except for maybe assembly language.
- pjmlp 6y ago"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C. A. R. Hoare, Turing award lecture in 1981, http://www.labouseur.com/projects/codeReckon/papers/The-Emperors-Old-Clothes.pdf http://www.labouseur.com/projects/codeReckon/papers/The-Empe...