22 ms·
Some Were Meant for C (2017) [pdf]
- dang 7y agoDiscussed at the time: https://news.ycombinator.com/item?id=15179188 https://news.ycombinator.com/item?id=15179188
- morenoh149 7y agothe other discussion mentions D as a better C. Anyone ever try to build "C the good parts"?
- oddity 7y agoThey did. Many times. First they made "C the good parts" by gathering all the various C bits then in use to make something portable and called it C89. Then they made "C the good parts" by removing all the parts that made C slow to write and called it Perl. Then they made "C the good parts" by making C easier but still fast and called it Java. In the meantime, we've gotten Objective-C and C++, which were attempts to make C better while preserving backwards compatibility. C++ has gone on to spawn its own legacy of "No actually, these are the good parts" with D, Clay, Rust, and various half-steps along the way that want some of the features of C++ but not all of the features of C++. I don't think they'll stop, because as it turns out, people use tools for different reasons and it's very rare that a general purpose tool solves your very specific problem perfectly. I'm inherently skeptical of any "X the good parts" because the "good parts" are domain specific.
- tejuis 7y agoI agree. If you take the tool perspective, it is easy to understand that different tools are needed for different tasks. Don't use hammer for sawing. No single language scales to all corners of programming problems. Actually I really don't get this endless "silver bullet" discussion. C has its place and for very good reasons. Also the author makes really good points about the integration aspects of C.
- pjmlp 7y agoBeing the language to write UNIX clones, that is all about it.
- nwmcsween 7y agoSo by your definition the windows kernel is unix?
- derefr 7y agoCompared to the architecture of an OS targeting, say, hardware with native capability handling, Windows and Unix are virtually indistinguishable. They're both just "that ugly bag of compromises you make to abstract over a register machine that can peek and poke at an unprotected address space, with the OS managing an MMU through CPU-interrupt-triggered context switches to enable a kind of multitasking where each task perceives itself as living on a single core and is unaware of being pre-empted unless it checks for it after the fact." There are examples of OSes that don't work like that, despite targeting x86. For example, bare-metal Forth.
- pjmlp 7y agoNo, because Windows has plenty of C++ on it and Microsoft Security Team advocates using C#, Rust and constrained C++ (Core Guidelines) as the future of systems programming on Windows. https://github.com/Microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf https://github.com/Microsoft/MSRC-Security-Research/blob/mas... They are also very clear that C is done on Windows, and compatibility is only to the extent required by ISO C++ and a couple of key FOSS projects. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... UNIX is C's platform, there is hardly any reason to use it outside of non-UNIX OSes. Plenty other languages offer system programming features, with better type safety and equal portability.
- cjfd 7y agoI read this thought quite often here on hacker news but it is a bit alien to me. To me the charm of programming is the ability to---at least in theory---write anything. This is also embodied in the idea of Turing completeness. There is a continuum between the possibilities of a programming language and the possibilities of a configuration file. As soon as one says that a programming language is suitable for a particular purpose one has moved a few steps towards the configuration file end of this continuum. This is, of course, a personal preference but I very much prefer to enjoy the power of programming language as opposed to the lack thereof of configuration files. Therefore, I like programming languages that attempt to be useful for any purpose. My favorite language is still C++ and if I were to switch to something else I would be inclined towards Rust.
- MrBuddyCasino 7y ago> Then they made "C the good parts" by making C easier but still fast and called it Java. That one doesn't feel right. More like "figure out how to nudge the C++ crowd into the general direction of Smalltalk without them noticing".
- dnautics 7y agoIs java really smalltalk under the hood? Ruby certainly is. I always got the feeling that java was c++ with a bit more religion about OO, a well defined and platform independent standard library, and no multiple inheritance.
- otabdeveloper1 7y ago> I always got the feeling that java was c++ with a bit more religion about OO No way. C++ was always much more into the functional programming paradigm. (See the STL, for example.) The connection between C++ and OOP is because OOP was the insane hype at the time when C++ was being invented. The OOP lipservice was mandatory in order to be taken seriously by the fashion-driven programming industry, but real C++ programmers always looked down on OOP and considered it a code smell and crutch.
- 0815test 7y ago> The connection between C++ and OOP is because OOP was the insane hype at the time when C++ was being invented. Not really, the C++ OOP features were directly modeled after very similar features in Simula. C++ was specifically designed as a way of bringing these sorts of features to C, although it did include other improvements to the language as well. Templates and the STL as we know it were a relatively late addition to the language. It's also worth mentioning that there's only a handful of things about OOP that could be genuinely considered "a code smell"; in fact you could restrict that concern to one feature, viz. implementation inheritance. Object-based programming which follows the "composition over inheritance" guideline can still broadly tap into the improved-modularity benefits that 'objects' are generally known for.
- 7y ago
- dnautics 7y agoI'm skeptical about X the good parts, but hey "JavaScript the good parts" is really a thing in my experience.
- morenoh149 7y agoI actually meant like a book like JavaScript: The Good Parts by Douglas Crockford. But thanks for your insight!
- e9 7y agoI would change it to: some were meant to c
- tejuis 7y agoThat came to mind immediately. :)
- jamiecollinson 7y agoFrom the intro it's a reference to a song lyric (which I wasn't familiar with): While some were meant for sea, in tug-boats ’Round the shore’s knee, (Milling with the sand, and always coming back to land), For others, up above Is all they care to think of, Up there with the birds and clouds, and Words don’t follow. —Tiny Ruins, from “Priest with Balloons”
- millstone 7y agoWhat is lovely about C is its paper-thin layer atop the syscall pokey bits: signal, vfork, mmap, etc. No surprise that other languages either start by using libc, or find their way there eventually.
- pjmlp 7y agoThis is only true for UNIX based OSes, given that libc is naturally the door into the OS, and contains much more than what ISO C compliant libc is supposed to have.
- fiddlerwoaroof 7y agoAnd not even all unices: MacOS has several APIs where the specified interface is the Objective-C interface, not the C one.
- bluetomcat 7y agoThe "killer feature" of C is the simple semantics of the language (despite all the dark undefined corners), which can be implemented relatively straightforward on a variety of ISAs. There isn't any need for runtime support because of the lack of fancy language features. That makes it the most natural way to call into the operating system, without any concerns that the chunk of memory returned by mmap has to be somehow managed by the language runtime.
- ido 7y agoI wonder how bi-directional this has been since the rise of c? i.e. CPU manufacturers defining ISAs that are well suited for usage with c.
- saagarjha 7y agoI think that the fact that we essentially have instructions on most architectures well suited for the implementation of certain operations common in C answers this pretty well.
- 7y ago
- danieltillett 7y agoThe best thing about C (apart from speed) is that for every issue with the language there is a tool that fixes the problem. It can do everything everywhere even if it's sometimes not the best choice.
- lone_haxx0r 7y agoIf C didn't have (as much) undefined behavior it would be practically perfect. There's not much else that I would change about it.
- sgillen 7y agoHonest question. What has stopped people from creating a standard with no undefined behavior? Is such a thing impossible? Have people done it?
- adrianN 7y agoSee for example here https://blog.regehr.org/archives/1287 https://blog.regehr.org/archives/1287 > After publishing the Friendly C Proposal, I spent some time discussing its design with people, and eventually I came to the depressing conclusion that there’s no way to get a group of C experts — even if they are knowledgable, intelligent, and otherwise reasonable — to agree on the Friendly C dialect. There are just too many variations, each with its own set of performance tradeoffs, for consensus to be possible.
- bluetomcat 7y ago> What has stopped people from creating a standard with no undefined behavior? Because making C safer would introduce a lot more complexity in the runtime environment and instrumentation, and that is even hard to achieve correctly or has varying performance implications across all ISAs that C compilers are currently targeting. Consider out of bounds indexing. To determine that an instruction is touching a memory region that is not, in abstract terms, a C array or a memory allocation by malloc and friends, now you need to insert long traps in memory, and even then, there is nothing stopping you from accessing array `b` through, for example, `a + 42`.
- archgoon 7y agoRemoving undefined behavior is not actually the same as making C safer. In fact, in a sense, well defined C exists (many versions in fact), it's whatever your C compiler spits out with whatever combination of flags have been passed in.
- MaysonL 7y agoThe only reason C is as popular as it is is that it was used to write Unix, which was widely distributed and implemented. The rest is just following on that. It's just like the reason human (and other mammals) have their optic nerve passing through the retina creating a blind spot: pure historical accident.
- oytis 7y agoYes and no. It can explain why C dominates over other low-tech languages, like e.g. Pascal. But when people talk about replacing C they usually mean replacing it with some feature-rich language. And why C survives and dominates certain areas despite lacking all the fancy features is a totally different question.
- edwinyzh 7y agoHello, why you can Pascal a low-tech language? Recently I heard about 'low-tech programming', not sure what does it actually mean.
- C1sc0cat 7y agoPascal isn't a low level language its a teaching one
- _0ffh 7y agoThat's an age old discussion. The practical Pascal variants like Turbo Pascal and Quick Pascal, which compiled to native code, are essentially on par with C regarding the features. That includes access to absolute memory addresses, port I/O and the speed of the resulting code. I've done over a decade of Turbo Pascal coding, and going on three decades of C, and I agree they feel like essentially much the same thing.
- C1sc0cat 7y agoHumm ok but sounds risky I can recall PET programming where you would poke raw assembly code and BBC basic could inline Assembly , not sure that means BASIC is a low level language.
- aap_ 7y agoI don't like how people on the internet hate on C all the time. To me C is a wonderfully simple and elegant language that I can most of the time very clearly express my thoughts in. I find that this not the case with many other languages. This is the reason I use C. Of course compiler writers are trying to sabotage this but I don't write any critical code so if I get hit by an occasional bug it's not a big problem. I think C is misunderstood, perhaps because it is used everywhere and standards for critical pieces of software are applied to non-critical ones. E.g. never freeing memory, even leaking it by destroying all references to it, can be totally fine if your program just runs for a few seconds. Just allocate what you need, throw it away, and let the OS clean up when you're done. This is perfectly fine but I feel like many people wouldn't accept this kind of code because it's not acceptable in other circumstances. Anyway, the author makes a few good points that are important but often overlooked, but I don't think I'd agree with him on the safety aspect in section 6. Making a safe C implementation doesn't really appear possible. If you allow casting integers to pointers, how do you implement these saftey checks he's talking about?
- GlennS 7y agoI feel like C has to go in the bucket of 'bad languages' these days, because it doesn't have sensible unicode support built in. But that doesn't mean you can't have fun with it, or write good computer programs. It just means that user inputted text is always going to be a pain.
- Nursie 7y agoTo be fair it doesn't really have strings 'built in' particularly well either. It directly manipulates memory patches, and the string support that is there is mostly a very simple abstraction on that. If you want support for unicode etc, there are libraries.
- solarkraft 7y agoBut then that brings you compatibility issues, overhead ...
- kosma 7y agoObligatory (and hilarious) read: "The Night Watch"[0] by James Mickens. > You might ask, “Why would someone write code in a grotesque language that exposes raw memory addresses? Why not use a modern language with garbage collection and functional programming and free massages after lunch?” Here’s the answer: Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. [0]https://www.usenix.org/system/files/1311_05-08_mickens.pdf https://www.usenix.org/system/files/1311_05-08_mickens.pdf
- holografix 7y agoGot me LOL’ing several times! Thanks for sharing
- roca 7y agoIt's dumb that in 2017 the author doesn't say anything specific about Rust, which is by far the strongest "C replacement" candidate. The author doesn't deal with the problem that the "direct access to memory without abstractions" style they love so very easily drifts into undefined behaviour. It also optimizes very poorly due to lack of aliasing information, unless you enable type-based alias analysis in which case accidental undefined behavior is catastrophic. The "dynamically checked C" they propose as a solution to C's safety issues is no solution at all until you can get it to work in practice. A lot of really great people, including the researchers he cites, have tried really hard to make it work and have failed in practice. He doesn't seem to understand why they failed or have any insight into how to overcome the problems.
- sevensor 7y agoI will always have a soft spot for C. It was my first language. I wrote my first linked list in C. 30 seconds later I had my first segfault. C was the entrance to the rabbit hole for me. I went down through assembly language, down through logic design, circuit design, and transistor theory, all the way down to fabrication and quantum mechanics. It was a long time before I came back from that trip. Today, I wouldn't use C for everything, or even for many things, but I'm glad I know it and I'm glad it's the substratum that holds most everything else together. I'm glad because C is an idea you can hold in your head. I can look at old C, I can look at new C, and it's all pretty sensible. (Excepting macro abuse, deliberate obfuscation, or gross incompetence.) It's hard to say that about most any other language.