Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.os.linux.misc,alt.folklore.computers Subject: Re: =?UTF-8?Q?Re=3A_Naughty_C=E2=99=AF?= Date: Tue, 6 Jan 2026 17:50:00 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10jji08$8cd$1@reader2.panix.com> References: <10jiufh$1an77$1@paganini.bofh.team> <10jjc9s$3uhtk$1@dont-email.me> <10jjgju$5l5$3@dont-email.me> Injection-Date: Tue, 6 Jan 2026 17:50:00 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="8589"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.os.linux.misc:80597 alt.folklore.computers:233268 In article <10jjgju$5l5$3@dont-email.me>, The Natural Philosopher wrote: >On 06/01/2026 16:12, Chris Ahlstrom wrote: >> Waldek Hebisch wrote this post by blinking in Morse code: >> >>> In alt.folklore.computers c186282 wrote: >>> >>>> Hmm ... look at all the GNU 'compilers' - >>>> FORTRAN, COBOL, Ada, 'D', M2, Rust,C++, >>>> G++, even Algol-68. None are 'compilers' >>>> per-se, but to-'C' TRANSLATORS. So, 'C', >>>> pretty much All Are One And One Is All. >>> >>> No. Compiler as first stage translate given language to a >>> common representation. This representatiton is different >>> than C. Ada and GNU Pascal have parametrized types, there >>> is nothing like that in C. >>> >>> >>> >>> C++ (and some other languages) >>> have exceptions, C do not have them. >> >> What about setjmp()/longjmp() ? > >Exactly. The problem with making high level 'features' in a language is >people then don't see how they actually work. What an odd take. The point of programming is to write programs. The point of maintenance is to make sure those programs continue working over time as technology and environments change. C (and for that matter Unix) were invented to make writing and maintaining programs easier than the techniques that had been used up to that point, not to elucidate the implementation. This idea of C as some kind of glorified "high-level" assembler hasn't been true since we started to see optimizing compilers in the 1970s. >One of the worst features of C libs is malloc() and free() where the >underlying mechanism is opaque. ...because it is utterly irrelevant to 99.99% of programs. If you want to see how it works under the hood, go look up the system interface. But if done properly, that's independent of the user application language. Or, if you can, read the library source if you want to see how `malloc` is implemented: this is one of the benefits of open source software. The claim that `malloc` is bad because it hides the details of memory management is just silly. stdio hides the details of blocks, buffer caches, bus acceses, DMA, asynchronous descriptor queues, IO devices and their access mechanisms, and so on, from programmers. Because, again, it's totally irrelevant for _most_ programs. Is that similarly bad? >auto allocation and garbage collection is even worse. > >Also operator overloading and weak typing. > >You simply do not know where you are. Most programmers don't know that stuff anyway. Most have no idea how their program is loaded into memory or starts running, how the platform is initialized, the implementation of the sorts of abstractions that the OS provides, and so on. >It's all fearfully clever ins a smart alec sort of way but it makes for >a lot of problems downstream... Nonsense. - Dan C.