13 ms·
C isn't a programming language anymore (2022)
- orionblastar 8mo agoI always thought that C was a stepping stone to learn other languages. Like Pascal, it was educational to learn. My Comp Sci courses in 1986-1990 used Turbo Pascal and Turbo C.
- twangist 8mo agoC was never a gateway to any flavor of Pascal, a "police state language".
- Nevermark 8mo agoIt's not a coincidence that Rust was invented in 1984 by some animals on a farm! Stay in thy lane, programmer!
- TZubiri 8mo agoI think so to, for most devs C is like Latin, or Roman Law, not something we develop and use, but rather something we learn for context and to understand future developments. There's some people that still develop on C for sure, but it's limited to FOSS and embedded at this point, Low Level proprietary systems having migrated to C++ or Rust mostly. I agree with the main thesis that C isn't a language like the others, something that we practice, that it's mostly an ancient but highly influential language, and it's an API/ABI. What I disagree with is that 'critiquing' C is productive in the same way that critiquing Roman Law or Latin or Plato is productive, the horse is dead, one might think they are being clever or novel for finding flaws in the dead horse, but it's more often a defense mechanism to justify having a hard time learning the decades of backwards compatibility, edge cases and warts that have been developed. It's easier to think of the previous generation as being dumb and having made mistakes that could have been fixed, and that it all could be simpler, rather than recognize that engineering is super complex and that we might as well dedicate our full life to learning this craft and still not make a dent. I applaud the new generation for taking on this challenge and giving their best shot at the revolution, but I'm personally thinking of bridging the next-next generation and the previous generation of devs, the historical complexity of the field will increase linearly with time and I think if we pace ourselves we can keep the complexity down, and the more times we hop unto a revolution that disregards the previous generation as dumb, the bigger the complexity is going to be.
- uecker 8mo agoThere is also still a lot of low-level proprietary code developed in C. I would guess far more than what is developed in Rust. I fully agree about your last point. The proposed solutions to some of the deficiencies of C are sometimes worse than the disease while its benefits are often exaggerated, at the same time adding unnecessary layers of complexity that will haunt us for decades. In contrast, my hope would be to to carefully revise the things we have, but this takes time and patience.
- TZubiri 8mo ago>There is also still a lot of low-level proprietary code developed in C. I would guess far more than what is developed in Rust. Do you mean that there's still code being developed, or that it still exists? Because I meant the former, the latter is true of a lot of dead languages like fortran and cobol, and it would cement the idea of being a dead language.
- nacozarina 8mo agoNone of the alternatives have stability. What was exemplary & idiomatic rust pre-pandemic would be churlish & rejected now and the toolchain use would be different anyway. Carpenters, plumbers, masons & electricians work on houses 3-300 yrs old, navigate the range of legacy styles & tech they encounter, and predictably get good outcomes. Only C has, yet, given use that level of serviceability. C99, baby, why pay more? When there’s an alternative that can compete with that sort of real-world durability, C will get displaced.
- charleslmunger 8mo agoC99, but with a million macros backporting features from newer language versions and compiler extensions. Lovely features you don't get with ordinary c99: free_sized #embed static_assert Types for enum Alignof, alignas, aligned_alloc _Atomic
- okanat 8mo agoThe replacement has already happened. It is HTTP and JSON for 99% of the software developed today. The reason C stayed has multiple reasons but most obvious ones are for me are: - People just stopped caring about operating systems research and systems programming after ~2005. Actual engineering implementations of the concepts largely stopped after the second half of 90s. Most developers moved on to making websites or applications in higher level programming languages. - C hit a perfect balance of being a small enough language to grok, being indepedent of the system manufacturers, reflecting the computer architecture of 80s, actually small in syntax and code length and quite easy to implement compilers for. This caused lots of legacy software being built into the infrastructure that gave birth to the current contemporary popular OSes and more importantly the infrastructure of the Internet. Add in .com bubbles and other crises, we basically have/had zero economic incentive to replace those systems. - Culture changed. We cared more about stability, repairability and reusability. Computers were expensive. So are programmers and software. Now computers are cheap. Our culture is more consumerist than ever. The mentality of "move fast and break things" permeated so well with economic policy and the zeitgeist. With AI it will get worse. So trying to make a real alternative to C (as a generic low level OS protocol) has reduced cultural value / optics. It doesn't fill the CVs as well. It doesn't mean that people haven't tried or even succeeded. Android was successful in multiple fronts in replacing C. Its "intents" and low level interface description language for hardware interfaces are great replacement for C ABI. Windows' COM is also a good replacement that gets rid of language dependence. There are still newer OSes try like Redox or Fuchsia.
- pizlonator 8mo agoIt’s weird how whiny this post is. Like there’s zero intellectual curiosity about why C got this way, and why C gets to be the foundation for how systems software is written. I could write a whole essay about why, but now isn’t the time. I’m just going to enjoy the fact that TFA and the author don’t get it.
- ranger_danger 8mo agoWhat is TFA?
- jagged-chisel 8mo agoThe Fine/Fabulous/Fucking Article Choose your own adjective
- SoftTalker 8mo agoFeatured
- leoc 8mo agoTo further explain: it comes from 'RTFA' https://en.wiktionary.org/wiki/RTFA https://en.wiktionary.org/wiki/RTFA which was developed on Slashdot as a variation on 'RTFM'.
- munificent 8mo ago> why C gets to be the foundation for how systems software is written. Is there an answer here more interesting than "it's what Unix and Windows were written in, so that's how programs talked to the OS, and once you have an interface, it's impossible to change"?
- pizlonator 8mo agoYes
- 8mo ago
- TZubiri 8mo ago[flagged]
- majorchord 8mo ago[flagged]
- TZubiri 8mo agoI think we can be accomodating of a wide array of diagnosable mental conditions in software. I'm thinking of Terry King's TempleOS, Ken Reitz's Requests. Being upfront about it by authors dispels a lot of the potential tension and substantially changes the way we interact. I understand there may be a conflict and not everyone will want to advertise their diagnosis, but in my experience once it becomes clear that's what's going on, it helps all the parties involved.
- SanjayMehta 8mo agoIt is exactly as you describe.
- CGamesPlay 8mo agoThis is just an ad hominem attack. Doesn't seem like the author is "in over their head"; they seem to have a pretty solid grasp of actual identifiable gaps between implementations and various specs, and the article was written with the same kind of "chastising" tone as you would see from any grey-bearded hacker who's unsatisfied with the way things are.
- player1234 8mo ago[dead]
- yoshuaw 8mo agoThis is the same author who found and reported ABI incompatibilities between clang and gcc: https://faultlore.com/abi-cafe/book/trophies.html https://faultlore.com/abi-cafe/book/trophies.html — Given these incompatibilities have since been addressed, I think it's fair to say there were indeed issues with C.
- ranger_danger 8mo agoI try not to put much stock in black-and-white opinions because I think the answer is rarely that simple.
- mjg59 8mo agoI really don't understand why people keep misunderstanding this post so badly. It's not a complaint about C as a programming language. It's a complaint that, due to so much infrastructure being implemented in C, anyone who wants to interact with that infrastructure is forced to deal with some of the constraints of C. C has moved beyond merely being a programming language and become the most common interface for in-process interoperability between languages[1], and that means everyone working at that level needs to care about C even if they have no intention of writing C. It's understandable how we got here, but it's an entirely legitimate question - could things be better if we had an explicitly designed interoperability interface? Given my experiences with cgo, I'd be pretty solidly on the "Fuck yes" side of things. (Of course, any such interface would probably end up being designed by committee and end up embodying chunks of ALGOL ABI or something instead, so this may not be the worst possible world but that doesn't mean we have to like it) [1] I absolutely buy the argument that HTTP probably wins out for out of process
- SanjayMehta 8mo agoVHDL vs Verilog is a good parallel from the chip world. VHDL was designed from ground up. Verilog is loosely based on C. Most designs are done in Verilog.
- pjmlp 8mo agoVHDL tends to reign in European hardware companies.
- direwolf20 8mo agoI wonder why there aren't many successful European hardware products.
- pjmlp 8mo agoI would assert any company that doesn't go bankrupt is successful, doesn't need to be late stage capitalism. Other than that, Nokia until Microsoft placed an agent on it, Phillips that contributed to CDs, ASML...
- agentultra 8mo agoI mean… an ABI is more like an agreement. It isn’t a specification. It’d be nice if everything was neatly specified and sound. But as the author notes near the end… there’s a lot of platforms and they all have their own quirks. There has to be an ABI that has to be agreed upon by everyone. Otherwise there wouldn’t be any interoperability. And if we didn’t have the SystemV ABI — what would we use instead? Prepare for a long debate as every language author, operating system designer, and platform under the sun argues for their respective demands and proposals. And as sure as the sun rises in the East someone, somewhere, would write an article such as this one decrying that blessed ABI. SystemV shouldn’t be the be all and end all, IMO. But progress should be incremental. Because a lingua franca loses its primary feature and utility when we all return to our own fiefdoms and stop talking to one another in the common tongue. It’s a pain in the metaphorical butt. But it’s better, IMO, than the alternatives. It’s kind of neat that SystemV works so well let alone at all.
- groundzeros2015 8mo agoWhat languages does this author like which has a written spec?
- ChrisSD 8mo agoThis article isn't about languages. It's about the protocol for two or more languages to talk to each other. There is no specification for this. The System V ABI is as close as we get to an actual specification but not everyone uses it and in any case it only covers a small part of the protocol.
- groundzeros2015 8mo ago> He’s trying to materially improve the conditions of using C itself as a programming language. > I’m trying to materially improve the conditions of using literally any language other than C.
- bigbuppo 8mo agoTL;DR author loves rust and writing a subset of a c compiler is hard
- themafia 8mo ago> C was elevated to a role of prestige and power We didn't do it to annoy you or to foist bad APIs on you. We did it because it was the best language for writing machine code at the time. By miles. Not understanding why this is true will lead you to make all the same mistakes the languages "bested" by C made.
- hacker_homie 8mo agoIt's not that it was made this way to annoy you, it was all we had. The whole world shouldn't "need to be fixed" because you won't spend the time to learn something. Rust doesn't even have a stable Internal ABI that's why you have to re-compile everything all the time.
- cornhole 8mo agodoesn’t mean it can’t be improved, but also doesn’t guarantee that the new way isn’t some sort of brand new hell
- Animats 8mo agoThe trouble with C as an API format is that there's no size info. That's asking for buffer overflows. There's an argument for full type info at an API, but that gets complicated across languages. Things that do that degenerate into CORBA. Size info, though, is meaningful at the machine level, and ought to be there. Apple originally had Pascal APIs for the Mac, which did carry along size info. But they caved and went with C APIs.
- Panzerschrek 8mo ago> Anyone who spends much time trying to parse C(++) headers very quickly says “ah, actually, fuck that” and asks a C(++) compiler to do it. That's exactly my case. For my programming language I have wrote a tool for C headers conversion using libclang. And even with help of this library it wasn't that easy, I have found a lot of caveats by trying converting headers like <windows.h>.
- smallstepforman 8mo agoC’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. There are more but I understand the logic/usability/history behind them. The above points should have been addressed in the 80’s.
- abcd_f 8mo agoArrays decaying to pointers is probably the biggest non-platform specific design oversight. As you said, it's easy to see where it came from, but it should've been fixed long ago.
- 1718627440 8mo ago> but it should've been fixed long ago. Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.
- pjmlp 8mo agoWorse than that, lets remember that WG14 rejected Dennis Ritchie proposal for fat pointers, and the C authors decided it was more fun to keep their own way with other programming languages than try to improve C from WG14. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.pdf https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...
- abcd_f 8mo agoI read through the RFC and I think it's fair it was rejected, because this was ultimately a half-measure, with severe usability restrictions. Fat pointers are clearly a way to deal with arrays (and also get "slices" and non-zero terminated strings for free!), but it's just not possible to retrofit them into the language without breaking existing code.
- Woodi 8mo agoDo someone pays for anti-C propaganda ?? All that logic breaking accusations... Eg. here, from memory: > ...you want to read 32 bits from file but OH NOOES long is 64 bit ! The language ! The imposibility ! But when you read something ot unserialize some format you just need to know based on format schema or domain knowledge. Simple and straightforward like that ! You do not do some "reflections" on what language standard provide and then expect someone send you just that !! So that anti-C "movement" is mostly based on brainless exampless. Not saying C is perfect. But it is very good and I bet IBM and other big corps will keep selling things written and actively developed in C/C++ + adding hefty consulting fees. In the meantime proles has been adviced to move to cpu-cycle-eating inferior languages and layers over layers of cycle burning infra in cloud-level zero-privacy and guaranteed data leaks. Oh, btw. that femous Java "bean" is just object with usually language delivered "basic type"... How that poor programmer from article should know what to read from disc when he just have types Java provides ?? How ? Or maybe he should use some domain knowledge or schema for problem he is trying to solve ?? And in "scripting language" with automatic int's - how to even know how many bits runtime/vm actually use ? Maybe some reflection to check type ? But again how that even helps if there is no knowledge in brain how many bits should be read ?? But calling some cycle burning reflection or virtual and as much as posible indirect things is what fat tigers love the moust :)
- black_13 8mo ago[dead]
- anthk 8mo agoC under Plan9 it's pretty easy to understand. Under current BSD's and worse... GNUs, it's a nightmare. With C++ it's the same. Within the Haiku code it's half understandable, the whole spec it's to get driven mad in days.
- bfrog 8mo agoC isn't really the protocol though, its just a way every language has of exporting simple symbols. Otherwise how else does this work, you'd never every language to understand every other languages symbol name encoding scheme, some of which are complete jibberish (I'm looking hard your way C++). The real protocol in action here is symbolic linking and hardware call ABIs. You could always directly call Rust functions, but you'd have to know where to symbolically look for them and how to craft its parameters for example. If this is well defined then its possible. If its poorly defined or implementation specific (c++) then yeah its a shit show that is not solvable.
- chuckadams 8mo agoI remember reading some crank on slashdot decades ago seriously claiming that Windows was not an operating system. This type of argument hasn’t gotten any more intelligent since.
- chuckadams 8mo agoFollowing up, I see that's not really what the author was trying to say: it's that for a growing number of purposes, like gluing together two languages that aren't C, that the C ABI is still dominating things where the C language shouldn't even be involved. Write clickbait, get kneejerk. I guess some other things are at least as old as C.
- mayhemducks 8mo agoI prefer pragmatism over ontology. The word "is" complicates discussions in unproductive ways. Good read though. Thinking about C as not just a language but also a protocol is a different perspective that is useful for the mental model.
- president_zippy 8mo agoOP, I would strongly recommend you try to play devil's advocate against your own case before making it, so you have a chance to refine your thoughts and rebut at least the top 2-3 counterarguments. More than that, you would do well to understand the concept of Chesterton's Fence as it applies to engineering: "In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."" -G.K. Chesterton #1: What you consider a "language" is one with its own official runtime. By your logic, Javascript is not a language either because the interpreter is usually written in C++ (e.g. V8, spidermonkey). #2: Dogfooding a compiler and a runtime is common practice because most people believe that it will help the makers of a language identify bugs in their implementation or identify undefined behavior in the very definition of their language. However, every language must bootstrap from another language: most languages bootstrapped from a compiler written in C. If you trace the lineage from compiler to compiler to ... compiler, you'll most likely find that the second C compiler ever written was written in C and the first compiler was written in some architecture's assembly language. The same still applies for the new, new language of C99 which is less than half the age of C. C is so mature that rooting out new undefined behaviors is no longer a significant concern. #3: libc is not just a "language runtime", it's the interface into the OS kernel for most operating systems. The runtime for every "real language" as you describe it ultimately uses libc. It doesn't make sense to separate the functions in the C99 standard from the OS's own syscalls and special-purpose user land functions call C standard library functions, and C's standard library relies on the OS's special functions. If they were separate libraries, there would be a circular dependency. Think of C not as "not a language" but as a language that serves the unusual purpose of being the foundation for nearly everything else. You have a point on integer types being a mess, but we have stdint.h for that.
- 1vuio0pswjnm7 8mo agoRust is a good way to get bad C programmers to stop using C But Rust evangelists cannot stop people from using any particular language Assembly is the only language that matters. It's the only language the computer "understands" Everything other language is just an abstraction over it When it comes to abstractions not everyone has the same preferences