19 ms·

The Curious Case of the Longevity of C

178 points by pablobaz 9y ago

jerrre 9y ago
>Perhaps now it is time for a new generation to make their mark, will their efforts last 40 years? Rust anyone? I'd think it's quite difficult for a new language to replace a language whose main attractive points are it's longevity, stability (not the code and programs coming out of it, but the syntax and tools etc), and broad support. There are many fields where C is easy to beat. But I don't think the next 40 year lasting language will be a C replacement.
- adrianratnapala 9y ago
  Indeed. I think the obvious candidate is JavaScript. C is what it is partly because of its relationship with Unix, and also because it was the language that gave most straightforward access to "the machine" -- whatever that is. And the hard truth is that The Machine was the only real universal platform around. But now we have this thing called The Web, which is not quite as universal but is getting there, and is much more like a single platform. JS has a special relationship with it. The only thing that might upset this JS+Web applecart is WebAssembly. A "C of the Web" (call it W) would be a language high level enough to be pleasant to use, but which would have little or no runtime beyond what is native to WebAsm, and thus anyone could use libraries written in W.
  - iagooar 9y ago
    Javascript might soon become obsolete with the arrival of WebAssembly.
    - krapp 9y ago
      Only where Javascript is being treated like a "compile target." Something is going to have to run the existing Javascript code on the web from now on, so the language itself likely isn't going anywhere, regardless of whether or not other languages can target WASM. Not the mention everywhere else it's been used - WebAssembly definitely isn't replacing Node.js, for instance, or game scripting.
      - marcosdumay 9y ago
        > WebAssembly definitely isn't replacing Node.js, for instance, or game scripting. WebAssembly is certainly able to replace JS in game scripting.
        krapp 9y ago
        People won't be scripting in WebAssembly. Other languages could target WebAssembly, but so could javascript.
    - steveklabnik 9y ago
      The wasm project states that obsoleting JavaScript is a non-goal.
      - flavio81 9y ago
        But this is what will happen eventually. No programmer with more than 5 years of professional experience really likes working with Javascript; they just put up with it. As soon as you can work in <insert your favorite language here> and compile it to WebAssembly, with the added bonus that it will run pretty fast, the popularity of Javascript will diminish drastically.
        steveklabnik 9y ago
        Your second sentence is pretty demonstrably false.
  - panic 9y ago
    Yep. C lives on because it's the language of Unix. JavaScript will live on because it's the language of the Web. It has nothing to do with the language itself -- it's the platform you have access to through it.
  - tim333 9y ago
    I note looking at webassembly.org's getting started page that their hello world example is written in C. Maybe the "C of the Web" will actually be C. (http://webassembly.org/getting-started/developers-guide/ http://webassembly.org/getting-started/developers-guide/)
    - steveklabnik 9y ago
      Due to lack of GC support, C, C++, and Rust are what you can reliably use with wasm at the moment. That integration is coming in the future, and should lead to other languages working well too.
    - kibwen 9y ago
      The ability to compile C code to WASM will be invaluable for porting well-used C libraries to the web, but given that the goal of WASM is to define a ("more-or-less") language-agnostic bytecode, I see little reason why people would prefer to use C when they could continue using Javascript, or, eventually, whatever the 40-years-from-now equivalent of Python is. (Of course, you'll always be able to use C if you do want to, so it's not like it's ever going to risk vanishing.)
      - krapp 9y ago
        > I see little reason why people would continue using C when they could continue using Javascript, or, eventually, whatever the 40-years-from-now equivalent of Python is. People will use C or Python or whatever on the web for the same reasons so many people transpile to javascript today, including that they simply don't like javascript and would rather write code in a language they prefer.
        kibwen 9y ago
        Indeed, but, as much as I admire Typescript, the vast majority of people aren't transpiling anything to Javascript. The grandfather comment was concerned with whether the future "C of the web" would literally be C, but I don't see how the introduction of WASM will start convincing the majority of people to start shipping webapps written in C. C is useful today as a low-level lingua franca, but on the web WASM will be the lingua franca, by definition, and C will be competing with many other languages that compile to WASM.
  - zeveb 9y ago
    > I think the obvious candidate is JavaScript. You're probably right, but egad, JavaScript is an even worse language than C. It's like jumping from the frying pan into the fire. At least it's garbage-collected.
- empath75 9y ago
  I think the redox OS has shown that it's not so hard to build a new OS in rust. I suspect that it won't be long before people are using redox in production (another year or so?). Once there's a viable competitor for linux, perhaps C won't be seen as the default language for system programming any more.
  - lossolo 9y ago
    > I suspect that it won't be long before people are using redox in production (another year or so?) This not realistic. No one serious/big will use it in production for the next 10 years easily. There is no certainty that it will be mainstream OS ever in the future. You will see thousands of problems next year in production that was not seen in testing today. Linux has millions of users and millions of use cases and edge cases, so many drivers written specially for it, tested and proven to work. Stability and maturity is the key for OS today. No one will trade that for some unproven hobbyist OS project.
Santosh83 9y ago
C works everywhere, and everyone knows C, or can learn it in a couple of weeks and get coding. This is a hard combination to wholesale replace, but then not even Rust aims to do that. Instead it aims to chip away gradually, and I don't see why it can't do that .
- foota 9y ago
  I would argue that while writing your first c doesn't take much knowledge (and is much easier than say rust), writing good C is harder than writing e.g., good Java. (Where I'd say some dimensions for good are bug free, reasonable performance, and readability)
- geezerjay 9y ago
  > C works everywhere, and everyone knows C, or can learn it in a couple of weeks and get coding. You hit the nail in the head. The go-to tutorial and reference book of C is «The C programming language» by Brian Kernighan and Dennis Ritchie, which provides a complete and very thorough description of C and its standard library in less than 260 pages. That's unbeatable. As a comparison, the go-to book for C++, «the C++ programming language» by Bjarne Stroustrup, goes beyond 1200 pages and doesn't cover some fundamental aspects of C++, and even «The Rust Programming Language» by Steve Klabnik and Carol Nichols, a book on a programming language which was designed to eat away C's market, is over 400 pages. This speaks volumes on the effort required by anyone to get on their feet and be productive with these programming language.
  - bluejekyll 9y ago
    From the article: “One standard textbook takes 534 pages to explain secure coding standards in C“
    - oblio 9y ago
      Yes, but that comes later. When Joe. D. Newbie wants to start programming, C seems quite approachable, conceptually. Hack away at things in an imperative fashion. There's a reason Visual Basic, Perl, PHP, Java (+IDEs), Javascript are/were the most popular languages. They're easy to get into. I'm not counting C++ because it was piggy-backing on C.
tudorw 9y ago
PHP is having it's 21st this year and is in use on around 200 million websites, I think it'll make it :) Logo is 50 :)
simias 9y ago
I think that during the nineties the focus switched from compiled, small runtime, unmanaged language to higher level, garbage collected, "big runtime" languages like Java or the scripting languages. One notable exception being C++ but its complexity and the difficulty to interface it with other languages meant that it couldn't completely replace C. So for a long time if you wanted to do low level, fast, small, reasonably portable code you simply didn't have much of a choice. Rust is the first language in a long time that I think could end up replacing C in all of its use cases but there's still some way to go. The main difficulty I can foresee is that like C++ it's significantly more complex than C and harder to interface with other programing languages (you end up making an unsafe C interface). I think C is here to stay. The billions of lines of C code out there won't be rewritten in a fortnight.
- zid 9y ago
  Rust would need severe changes to replace C where C shines, being able to cobble object files together into something that works. I can run malloc from userspace and 14 different previous invocations of a C compiler later I have registers with my parameters in touching page tables. ABIs, APIs etc have to be able to propagate size and type information that is basically how C defines them if you want anything to work (pointers, integers, floats). C embeds a remarkable amount of cross-object-file information about a function just with 'int f();'. We know the range of valid values, we know how big the object is, etc. Rust literally has none of these mechanisms and likely never will, interfacing Rust to other Rust, such that you will get any benefit at all from using it would require megs of type, scope, size, etc information to crawl across the calling convention. There's a reason C++ names look like CintFuncf!!!@34$902, Rust doesn't have or plan to have anything like this yet, and it'd need to be 20x more complicated. If you get rid of Rust's magic about being able to remove guards and checks by infering things about the data to make it conform to calling conventions instead of using types, you have just invented C.
  - kibwen 9y ago
    > Rust literally has none of these mechanisms and likely never will It's true that Rust has no stable ABI, but "likely never will" is hyperbole. If people demand it in sufficient quantity then it will happen in time. I personally hope it does someday, but I'm in no hurry. > There's a reason C++ names look like CintFuncf!!!@34$902, Rust doesn't have or plan to have anything like this yet, and it'd need to be 20x more complicated. Rust does have name mangling already. It may not be standardized (again, no stable ABI), but C++'s name mangling isn't standardized either. And I see no justification for why name mangling in Rust would need to be "20x more complicated" than in C++; AFAIK Rust symbols pretty much already imitate C++ symbols in order to play nicely with existing tooling. This would be more informative if you gave some concrete examples. Any hypothetical Rust ABI would be more extensive than the de facto C ABIs, undoubtedly, but the concern here seems unjustified.
colechristensen 9y ago
I'm quite bored by the obsession of some for replacing C. Yes, it does exactly what you tell it to do and that's dangerous. It was a high level language 25 years ago, but today the metaphor should be assembly. Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same. The biggest threat to the tech sector is Linus dying and being replaced by some charlatan who insists on replacing C and using Jira. </offtopic>
- tonyedgecombe 9y ago
  Yes, it does exactly what you tell it to do and that's dangerous. Exactly, if you could get all the benefits without the danger why wouldn't you?
- bluejekyll 9y ago
  > it does exactly what you tell it to do and that's dangerous. gcc: “hold my beer while I optimize out that block of code you clearly didn’t mean to be in your program”
  - hashmal 9y ago
    That's not because of C, that's because of GCC.
    - adrianratnapala 9y ago
      It's because of C as it has been redefined in recent times, but the kinds of people who write standards and compilers. The galling thing is that they did this to win a benchmark war against Fortran.
    - int_19h 9y ago
      gcc does it precisely because the C standard says that it can do so, and any program that's relying on not getting broken that way is not valid C (well, "undefined behavior", but it's the same thing in practice).
qwtel 9y ago
c.f. https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
hellofunk 9y ago
I've always like the description of C as just being "raw memory, but with syntactic sugar." I think C is still so pervasive for 2 simple reasons (I might be wrong): 1) It's a small language. Compared to many newer languages (Swift, modern C++, old C++, Objective-C, Java), it's quite tiny. The language itself can be learned in short time. (Which is deceptive, because properly using what you have learned takes longer than a short time). 2) It's fast. It's just direct memory access, direct and explicit hardware manipulation. And whether justified or not, there is a very large portion of the developer community that remains obsessed with speed. I see it all the time, even when speed isn't not going to matter enough to justify C. I often see people going way out of their way, making their work much more time-consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can.
- danieltillett 9y ago
  The thing I love about C is it almost always does what you want fast, but you are never certain. No matter how much you think you know C, there is always some new edge case to experience. C is exciting.
  - akvadrako 9y ago
    I completely disagree with this. C is the only language I ever used I felt I had mastered. Sometimes I needed to check things in the spec or pause to consider the C99/C89 discrepancies, but essentially I knew everything about it after just a few years of daily use. I've never felt that way with Python, JS, Ruby, Java, C++ or any of the other languages I've used. They are at least 10X more complex in terms of primitives and non-trivial interactions.
    - barrkel 9y ago
      C is deceptive, though. It encourages a mental model of high-level assembler, but it's an assembler for an abstract machine, not the actual machine; and compilers are increasingly making the difference evident.
faragon 9y ago
C is simple and beautiful.
- krapp 9y ago
  C is simple, but beauty is in the eye of the beholder.
- glandium 9y ago
  C looks simple, but is not. That's part of the problem with it.
- bjz_ 9y ago
  C's semantics are far from simple.
- luckydude 9y ago
  I agree. The standard, however, is far from simple and beautiful and what people are bitching about are all the weird semantics codified in the standard (I think). What they are not seeing is the simple and beautiful part, which is a shame because I think that's why C is still around and still popular. It's a little like looking at your spouse. You can fixate on the flaws and you'll hate your spouse. You can fixate on the positives and you have a much better chance at loving your spouse. Having a spouse that is artificially constrained to doing only the things you approve of is kind of what the Rust people are trying to do. Feels sort of weird to me but if that's their thing, go for it. Or maybe that's a messed up analogy?
mmjaa 9y ago
It shouldn't be such a surprise, unless one is ignorant of a stable, decades old, computing maxim: Old computers (and by definition, old computer software) never dies. The users do.
blub 9y ago
If something is to replace C (or C++), I hope it's not Rust, because Rust is even more complicated than C++. People should not have to bend their mind to satisfy some tool like the borrow checker, the tool should do the right thing and allow them to express their ideas in code with as little effort as possible.
- pygy_ 9y ago
  The borrow checker is currently stricter than it should be (it rejects valid programs), which requires workarounds. Once non-lexical lifetimes land, the borrow checker will be less of an issue.
  - steveklabnik 9y ago
    This is true of most sound static analysis; the goal is to reject as few programs as possible, but there's always some things that exist in the world that your system can't take into account.
    - icen 9y ago
      For good reason! This is Rice's theorem.
- aneutron 9y ago
  If it serves the purpose, it is worth the price of changing the way one thinks. You do realise than functional, imperative and procedural programming all coexist in this world. But using functional programming with trees for example makes your job way easier. Except you'll have to change your perspective on programming. It's the same thing with memory safety. If Rust is going to give you a guarantee about the memory safety, then changing your mindset is probably worth. I still consider myself a beginner/novice though, so this is just my opinion.
- kibwen 9y ago
  > Rust is even more complicated than C++ Example? In my experience, those saying this have either never used Rust, or never used C++. A strict compiler does not a complicated language make. To wit, if the response is "lifetimes", note that lifetime tracking is also critically important in C++ (not to mention C), it's just that C++ compilers give one far less help in doing so than Rust does.
rbanffy 9y ago
The "AHL" name brings me fond memories of Creative Computing magazine and their editor, David H. Ahl. Sadly these AHL's are unrelated.
JacobiX 9y ago
Even in relatively new fields like machine learning, nearly every software that we use at work is written in C or is a wrapper around a C library, or in some cases in Fortran (a 60 years old programming language) : we use extensively PyTorch, torch, numpy, LAPACK, Scipy, etc.
reacweb 9y ago
"C is the desert island language". see http://crypto.stanford.edu/~blynn/c/intro.html http://crypto.stanford.edu/~blynn/c/intro.html For me, Linux is a huge development environment dedicated to C programming. Chapter 2 and 3 of manual pages gives C api. C gives the most direct access to kernel. IMHO we should try to find a replacement for C and the first target for this language should be linux kernel. If you can conceive a language that Linus Torvalds accepts, the rest of the planet will follow ;-)
- kwhitefoot 9y ago
  > If you can conceive a language that Linus Torvalds accepts Good luck!
- Sir_Cmpwn 9y ago
  For a new language to have practical applications in the Linux codebase, it has to run on every architecture supported by Linux (and ideally more), and use the same linker and ABI as C. A tall order, to say the least.
jwilk 9y ago
> We rely on Python which is written in C89, a standard older than many of our developers. Python ≥ 3.6 requires (some features of) C99. > Perhaps the reluctance to move to a more ‘modern’ C is that even C99 can’t legally buy a drink Perhaps it's because MSVC didn't fully support anything newer. Source: https://www.python.org/dev/peps/pep-0007/#c-dialect https://www.python.org/dev/peps/pep-0007/#c-dialect
- raverbashing 9y ago
  And to be honest modern C99 stuff do not solve the fundamental problems in C (and solving those gives you something that is not C) (some of the changes) http://www.open-std.org/jtc1/sc22/wg14/www/newinc9x.htm http://www.open-std.org/jtc1/sc22/wg14/www/newinc9x.htm
- ericfrederich 9y ago
  Yeah... good luck taking a newer version of Python an compiling it on Visual Studio 2012. I had to jump through hoops even to get 2.7 to compile and wound up abandoning it because it caused problems down the line with ctypes.
  - pjmlp 9y ago
    VS2012 is quite pre-historic, we already had 2013, 2015 (with three updates) and are now on the third 2017 update. C99 support was added in VS2015 to the extent required by C++14, similarly C11 support was added in 2017 to the extent required by C++17.
    - dragonwriter 9y ago
      > VS2012 is quite pre-historic You don't work in the enterprise domain which is VS’s core market, do you?
      - jdmichal 9y ago
        Still on Visual Studio 2010 here... The pain is that everyone has to move at once due to the way the project files are upgraded when you open them in a newer version.
userbinator 9y ago
Add to this the disastrously central role that C has played in our ongoing computer security nightmare One sees plenty of news on the downsides, but on the other hand the lack of security has also enabled console homebrew, iOS jailbreaking, Android rooting, and a bunch of other creatively liberating activities which involve doing something not officially sanctioned. It's worth pondering whether we would be better off, had everyone switched to something much "safer" (maybe even with formal verification) a long time ago. I think it's debatable.
- kibwen 9y ago
  Contrarily, had we 'switched to something much "safer" a long time ago', then by now--out of sheer necessity--we may have been adept at leveraging economics and politics to make hardware user-hackable. As it is we could just be using the swiss-cheese safety of C as a crutch to avoid having to tackle the hard social problems of getting people to care about liberated devices.
  - ColanR 9y ago
    Or the number of people interested would have dried up.
    - kibwen 9y ago
      Possible, but doubtful. For ages the default state of software was closed-source, and yet the desire to share and be free did not dry up. People yearn for freedom, and in its absence they will make it, but mildly-comfortable half-solutions have a great way of defusing movements. But slowly the pool of exploits will dry up, either because we stop using C or because we finally figure out a way to write C securely, and we'll find ourselves decades behind at the necessary task of producing hardware that is open by design rather than open by accident.
- jstewartmobile 9y ago
  Best comment of the thread! "Be careful what you wish for..."
- 9y ago
jstewartmobile 9y ago
As maddening as it may be, my gut tells me it has more to do with the precompiler than anything else. When it comes to wrestling with cross-platform differences, I don't know of a corresponding feature in Rust or Go that is equally powerful (or equally ugly!). As long as computing remains a battleground where rich assholes put vastly different wrappers around the exact same shit so they can wring more money out of us, I will probably be writing in that abominable assembly language w/ turing-complete string-paster for many years to come.
- kibwen 9y ago
  Speaking of the C preprocessor, I found this recently: from the Firefox source code, a red-black tree written entirely in 800 lines of C macros: http://searchfox.org/mozilla-central/rev/f54c1723befe6bcc7229f005217d5c681128fcad/memory/build/rb.h http://searchfox.org/mozilla-central/rev/f54c1723befe6bcc722... . Submitted for your enjoyment. :)
  - jstewartmobile 9y ago
    I've used OpenBSD's version of that more times than I care to remember: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.29 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/...
  - nikbackm 9y ago
    Looks to be some small amount of C code in those macros as well.
  - throwme211345 9y ago
    Why would someone do that?
    - dboreham 9y ago
      Because long ago (and probably in a different product) making a function call was significantly costly and worthwhile optimizing away via macros.
Veedrac 9y ago
C was so successful because it had, and to a large extent still has, no competitors.
- dboreham 9y ago
  It was also free.
  - pjmlp 9y ago
    Only on UNIX, until Sun started to charge money for their SDK, which lead to many devs starting to help GCC development.
- pjmlp 9y ago
  On UNIX, it was barely used outside AT&T until companies started to base their workstation OSes on UNIX.
walshemj 9y ago
So COBOL and Fortan is still going strong in the areas its appropriate for.
- goatlover 9y ago
  Lisp is still around too. SmallTalk as well.
jasonmaydie 9y ago
it's time we admitted bad code isn't because of the tools we use but a function of how we write code. You can write bad code even in "safe" languages. Leak memory with languages that come with a GC, etc etc.
- Ar-Curunir 9y ago
  Yes, but some languages make it far easier than others.
throwaway2016a 9y ago
C was the first language I learned in the mid-90s and I still go back to it once and a while when I want raw speed and direct memory access. I know other languages, sure, but I have yet to find a suitable replacement that lets me do what I want to do on a machine level without getting in the way. Lately I've been doing some of the stuff I would normally do in C in GoLang instead. But it still can't match C in performance. (beats the hell out of Node.js though which is where I do most of my middle-tier / front-end code) It also makes an excellent foot gun for the same reason.
deleted 9y ago
[deleted]
jdblair 9y ago
My 2 cents, from the perspective of someone who built a career on writing software in C for small devices. C has longevity b/c its compact and provides a straightforward model of memory on the machine. I understand the desire to use safe, garbage collected, memory safe language when you're serving HTTP requests, but sometimes you need to access the hardware: twiddle a GPIO or read from a DMA device. This is where I've yet to see a good replacement for C, and by extension, C++ (b/c its fundamentally still just C). Maybe rust is there, but I don't have experience there to judge. [edited for clarity]
- steveklabnik 9y ago
  To be clear, since I have seen this pop up lately, Rust doesn't have a GC and absolutely gives you access to hardware. The challenges for it on embedded are mostly toolchain issues.
  - scruple 9y ago
    So, are vendors working on rust toolchains for their hardware? I'm asking from a place of genuine curiosity, I left embedded a number of years ago. I've always viewed the 'rust breaking into embedded' problem as a toolchain issue, as well. But, my intuition is that vendors will be slow to release rust support in toolchains because the industry is still firmly in the "we write in C" camp.
    - steveklabnik 9y ago
      That's what I meant by challenges; it's pretty much "can LLVM support the chip and then did someone put in the compiler work in rustc", rather than "vendors are directly providing Rust support." Your intuition is mine as well.
    - analog31 9y ago
      This is an interesting thread... https://news.ycombinator.com/item?id=14071282 https://news.ycombinator.com/item?id=14071282 In my view the industry inertia is a chicken and egg thing. You want a chip that runs your existing code. Then you want to write new code on your existing chip. And you have ongoing projects at different stages, sharing chips and code.
zeveb 9y ago
> In 1987 this code took around half an hour to run, today 0.03 seconds. Progress eh? The thing I take away when reading this is that in 1987 there were superior languages to C which — while usable — were just a bit too sluggish, and hence lost out. I'm thinking specifically of Smalltalk & Lisp, but I'm sure that there are others (maybe ML was around that far back?). Well, if a program which once ran in half an hour can now run in 300 milliseconds, I think that maybe we should reconsider using just a little of that extra performance to run a better language environment. Imagine if we had OSes written in safe languages which catch errors rather than allowing programs to misbehave. Honestly, it's hard for me to do because I've become so accustomed to crashes. Recently I've been doing some X programming with Lisp, and it's amazing — even when I make a mistake, things keep on running properly. I just see an error and that's that. Well, most of the time, anyway. Nothing's perfect. Still, the experience is orders of magnitude better than writing C. I mean that literally, not figuratively. (Also, as an aside: when I switched tabs to the article, it displayed for just a second, then disappeared. Reader mode didn't even work. I had to enable JavaScript just to view some text. What gives‽)
- andrewmcwatters 9y ago
  > reconsider using just a little of that extra performance Welcome to software development, where the code is shit, and the hardware improvements don't matter.
tlb 9y ago
I wonder if the danger of C is something people like, deep down. I spent some time talking to people who do dangerous jobs, thinking about automating their jobs with robots. Most of them liked the danger. They enjoyed having mastered the art of not getting killed by falling tree branches, or live wires, or runaway trucks, or whatever the job involved. They felt satisfaction at doing a job where, if someone else tried to do it, they'd probably get hurt on their first day. You can imagine various ways this could have evolved in hunter-gatherer societies. Most new languages are far safer than C. For some that's the main selling point, for others it's just a side-effect of having GC. I wonder if you could get a lot of traction with a language as expressive as Ruby, but with footguns galore. I'm not sure that space has been adequately explored.
- AnimalMuppet 9y ago
  I wouldn't put it as "danger", exactly. It's freedom. The language won't trap you, pretty much ever. You need to write directly to hardware registers? Fine. You need to drop into assembly for a bit? Go for it. However down-and-dirty you have to get, you can do it. Whereas with some other languages, if you ever need to get more down-and-dirty than the language is designed to allow, even for just a little bit of your program, well, too bad - you're not allowed to.
  - pjmlp 9y ago
    I could do all of that in Turbo Pascal, Turbo Basic and Modula-2 compilers.
    - AnimalMuppet 9y ago
      Ah, I had forgotten that Turbo Pascal let you drop into assembly. But could you write directly to a hardware address? I don't know, but I doubt it - Turbo Pascal ran on the PC, which didn't have memory-mapped hardware. You could do an outp. But in C, you could do *(unsigned long*)0xFFFE0004 = 0x8000FF2C; which was either absolutely necessary or absolutely stupid, depending on whether or not you had custom memory-mapped hardware at the specified address. Could you do that in Turbo Pascal? What's more, Turbo Pascal was PC-only, at least initially. If you had to work on a 68000-based embedded system running PDOS (not PC-DOS), and you had to use Pascal, it wasn't Turbo Pascal. It was just bog-standard Pascal. Inline assembler? No way. Pointer to a variable-sized array? Can't do it (you cannot give it a type). It was painful to work in that environment. And that environment was Pascal as specified by the language standard. Turbo Pascal fixed most of the problems, but it trampled all over the standard to do it. (At least it did have separate compilation.) Why was it painful to work in that environment? First, we couldn't access our custom hardware without having to link to an assembly-language subroutine. In doing so, we lost type safety, which led to at least one hard-to-find crash. It also was just much more difficult and error-prone to write those routines. Second, we wanted to have a user-specified variable-sized array. We wound up having to create the largest array we could given the memory the machine had, and only using the part that the user specified, which was a pretty ugly kludge. Third, Pascal was just clumsier to use than C. It was more verbose and more finicky. (One part I remember in particular was the semicolons. You couldn't have a semicolon on the last statement in a block. As you added or removed statements, you kept having to fiddle with the semicolons, including on lines other than the ones you were changing.)
raarts 9y ago
> Add to this the disastrously central role that C has played in our ongoing computer security nightmare Hindsight is 20/20. C was simply the pervasive language when the internet happened. C was designed when the world was a friendlier place, where buffer overflows did not exist. It was embraced by everyone because of its speed and simplicity. No C programmer was raised/educated to have security in the front of his mind. Hell, many programmers of any language still don't. Stop bashing C and start using Oauth instead of inventing your own authentication schemes.
- taeric 9y ago
  I fully agree with the advice, but I do worry that we are creating a monoculture for authentication. The pessimist in me says it is not if, but when a major vulnerability appears in the Oauth stack. Good thing about most vulnerabilities is that the blast radius can be rather small.
- lomnakkus 9y ago
  > No C programmer was raised/educated to have security in the front of his mind. It's not about having security in the front of his/her mind. People make mistakes and always will. In C those mistakes very frequently turn into easily exploitable bugs. That is the security problem with C -- not that programmers somehow don't think about security enough[1]. [1] Of course this is also true, but it's not part of the argument against C.
- mrec 9y ago
  > many programmers of any language still don't I wonder if anyone's trying an explicitly adversarial approach to early CS education. Split your class into two teams, each team produces an implementation, each team scores points for finding vulnerabilities in the other team's implementation. Doesn't really matter what they're implementing as long as there's untrusted input involved.
- eighthnate 9y ago
  > It was embraced by everyone because of its speed and simplicity. Exactly. The same thing with TCP/IP. People complain about C and TCP/IP because security wasn't baked into these technologies. That's because that wasn't the big concern back then. And the reason C and TCP/IP have legs is because they are very good at what they do. You get the same thing with people complaining about SQL, HTML and every other language/protocol/technology.
dingo_bat 9y ago
In my mind, C very closely resembles what's going on in my mind's model of the computer. I "think" in C when I'm thinking about an algorithm. It's almost exactly the same as the fake language people sometimes use for explaining an algorithm. I think this property contributes towards the popularity. No "artificial" abstractions like classes, templates, modules, imports etc. Just think of the first step you would do to solve a problem, and write it. Then think of the next step, and write that. And you get fast, portable code that produces tiny binaries! What more do you need?
- unboxed_type 9y ago
  Thou shall embrace the true power of functional programming
Animats 9y ago
C was originally a language for modest size programs on machines with 64K address spaces. C isn't a bad language for a thousand line program. It's a terrible language for a million line program. Just to get memory safety, there's too much that has to be manually coordinated across compilation unit boundaries. The three big questions in C are "how big is it?", "who owns it?", and "who locks it?" The language gives zero help with all of those issues. Most later languages deal with some or all of those issues.
- dxhdr 9y ago
  C could use a few features to help with million line codebases, like namespaces. Beyond that, programs that large require good human engineering to manage complexity.
- baybal2 9y ago
  If you look for million line C program, you invariably have to deal with something like Glib
yellowapple 9y ago
"We use git for source control. hg, largely written in Python, was started within a few days with the same goals. Who won?" I somehow doubt git's popularity has a whole lot to do with it having been written in C.
makecheck 9y ago
Binary compatibility is as much a reason as the language itself. For C++ I remember spending years trying to carefully track compiler versions, precise build setup, etc. or your library would probably fail to link. I have never had a binary compatibility problem with a plain C library.
asnyc 9y ago
C exposes you to low level programming environment, memory management and system internals. Its a great base to build upon for programmers. Even after more than a decade, I still have fond memories for K&R C - a must read for programmers.

178 points by pablobaz 9y ago

>Perhaps now it is time for a new generation to make their mark, will their efforts last 40 years? Rust anyone? I'd think it's quite difficult for a new language to replace a language whose main attractive points are it's longevity, stability (not the code and programs coming out of it, but the syntax and tools etc), and broad support. There are many fields where C is easy to beat. But I don't think the next 40 year lasting language will be a C replacement.

adrianratnapala 9y ago
Indeed. I think the obvious candidate is JavaScript. C is what it is partly because of its relationship with Unix, and also because it was the language that gave most straightforward access to "the machine" -- whatever that is. And the hard truth is that The Machine was the only real universal platform around. But now we have this thing called The Web, which is not quite as universal but is getting there, and is much more like a single platform. JS has a special relationship with it. The only thing that might upset this JS+Web applecart is WebAssembly. A "C of the Web" (call it W) would be a language high level enough to be pleasant to use, but which would have little or no runtime beyond what is native to WebAsm, and thus anyone could use libraries written in W.
- iagooar 9y ago
  Javascript might soon become obsolete with the arrival of WebAssembly.
  - krapp 9y ago
    Only where Javascript is being treated like a "compile target." Something is going to have to run the existing Javascript code on the web from now on, so the language itself likely isn't going anywhere, regardless of whether or not other languages can target WASM. Not the mention everywhere else it's been used - WebAssembly definitely isn't replacing Node.js, for instance, or game scripting.
    - marcosdumay 9y ago
      > WebAssembly definitely isn't replacing Node.js, for instance, or game scripting. WebAssembly is certainly able to replace JS in game scripting.
      - krapp 9y ago
        People won't be scripting in WebAssembly. Other languages could target WebAssembly, but so could javascript.
  - steveklabnik 9y ago
    The wasm project states that obsoleting JavaScript is a non-goal.
    - flavio81 9y ago
      But this is what will happen eventually. No programmer with more than 5 years of professional experience really likes working with Javascript; they just put up with it. As soon as you can work in <insert your favorite language here> and compile it to WebAssembly, with the added bonus that it will run pretty fast, the popularity of Javascript will diminish drastically.
      - steveklabnik 9y ago
        Your second sentence is pretty demonstrably false.
- panic 9y ago
  Yep. C lives on because it's the language of Unix. JavaScript will live on because it's the language of the Web. It has nothing to do with the language itself -- it's the platform you have access to through it.
- tim333 9y ago
  I note looking at webassembly.org's getting started page that their hello world example is written in C. Maybe the "C of the Web" will actually be C. (http://webassembly.org/getting-started/developers-guide/ http://webassembly.org/getting-started/developers-guide/)
  - steveklabnik 9y ago
    Due to lack of GC support, C, C++, and Rust are what you can reliably use with wasm at the moment. That integration is coming in the future, and should lead to other languages working well too.
  - kibwen 9y ago
    The ability to compile C code to WASM will be invaluable for porting well-used C libraries to the web, but given that the goal of WASM is to define a ("more-or-less") language-agnostic bytecode, I see little reason why people would prefer to use C when they could continue using Javascript, or, eventually, whatever the 40-years-from-now equivalent of Python is. (Of course, you'll always be able to use C if you do want to, so it's not like it's ever going to risk vanishing.)
    - krapp 9y ago
      > I see little reason why people would continue using C when they could continue using Javascript, or, eventually, whatever the 40-years-from-now equivalent of Python is. People will use C or Python or whatever on the web for the same reasons so many people transpile to javascript today, including that they simply don't like javascript and would rather write code in a language they prefer.
      - kibwen 9y ago
        Indeed, but, as much as I admire Typescript, the vast majority of people aren't transpiling anything to Javascript. The grandfather comment was concerned with whether the future "C of the web" would literally be C, but I don't see how the introduction of WASM will start convincing the majority of people to start shipping webapps written in C. C is useful today as a low-level lingua franca, but on the web WASM will be the lingua franca, by definition, and C will be competing with many other languages that compile to WASM.
- zeveb 9y ago
  > I think the obvious candidate is JavaScript. You're probably right, but egad, JavaScript is an even worse language than C. It's like jumping from the frying pan into the fire. At least it's garbage-collected.
empath75 9y ago
I think the redox OS has shown that it's not so hard to build a new OS in rust. I suspect that it won't be long before people are using redox in production (another year or so?). Once there's a viable competitor for linux, perhaps C won't be seen as the default language for system programming any more.
- lossolo 9y ago
  > I suspect that it won't be long before people are using redox in production (another year or so?) This not realistic. No one serious/big will use it in production for the next 10 years easily. There is no certainty that it will be mainstream OS ever in the future. You will see thousands of problems next year in production that was not seen in testing today. Linux has millions of users and millions of use cases and edge cases, so many drivers written specially for it, tested and proven to work. Stability and maturity is the key for OS today. No one will trade that for some unproven hobbyist OS project.

Santosh83 9y ago

C works everywhere, and everyone knows C, or can learn it in a couple of weeks and get coding. This is a hard combination to wholesale replace, but then not even Rust aims to do that. Instead it aims to chip away gradually, and I don't see why it can't do that .

foota 9y ago
I would argue that while writing your first c doesn't take much knowledge (and is much easier than say rust), writing good C is harder than writing e.g., good Java. (Where I'd say some dimensions for good are bug free, reasonable performance, and readability)
geezerjay 9y ago
> C works everywhere, and everyone knows C, or can learn it in a couple of weeks and get coding. You hit the nail in the head. The go-to tutorial and reference book of C is «The C programming language» by Brian Kernighan and Dennis Ritchie, which provides a complete and very thorough description of C and its standard library in less than 260 pages. That's unbeatable. As a comparison, the go-to book for C++, «the C++ programming language» by Bjarne Stroustrup, goes beyond 1200 pages and doesn't cover some fundamental aspects of C++, and even «The Rust Programming Language» by Steve Klabnik and Carol Nichols, a book on a programming language which was designed to eat away C's market, is over 400 pages. This speaks volumes on the effort required by anyone to get on their feet and be productive with these programming language.
- bluejekyll 9y ago
  From the article: “One standard textbook takes 534 pages to explain secure coding standards in C“
  - oblio 9y ago
    Yes, but that comes later. When Joe. D. Newbie wants to start programming, C seems quite approachable, conceptually. Hack away at things in an imperative fashion. There's a reason Visual Basic, Perl, PHP, Java (+IDEs), Javascript are/were the most popular languages. They're easy to get into. I'm not counting C++ because it was piggy-backing on C.

tudorw 9y ago

PHP is having it's 21st this year and is in use on around 200 million websites, I think it'll make it :) Logo is 50 :)

simias 9y ago

I think that during the nineties the focus switched from compiled, small runtime, unmanaged language to higher level, garbage collected, "big runtime" languages like Java or the scripting languages. One notable exception being C++ but its complexity and the difficulty to interface it with other languages meant that it couldn't completely replace C. So for a long time if you wanted to do low level, fast, small, reasonably portable code you simply didn't have much of a choice. Rust is the first language in a long time that I think could end up replacing C in all of its use cases but there's still some way to go. The main difficulty I can foresee is that like C++ it's significantly more complex than C and harder to interface with other programing languages (you end up making an unsafe C interface). I think C is here to stay. The billions of lines of C code out there won't be rewritten in a fortnight.

zid 9y ago
Rust would need severe changes to replace C where C shines, being able to cobble object files together into something that works. I can run malloc from userspace and 14 different previous invocations of a C compiler later I have registers with my parameters in touching page tables. ABIs, APIs etc have to be able to propagate size and type information that is basically how C defines them if you want anything to work (pointers, integers, floats). C embeds a remarkable amount of cross-object-file information about a function just with 'int f();'. We know the range of valid values, we know how big the object is, etc. Rust literally has none of these mechanisms and likely never will, interfacing Rust to other Rust, such that you will get any benefit at all from using it would require megs of type, scope, size, etc information to crawl across the calling convention. There's a reason C++ names look like CintFuncf!!!@34$902, Rust doesn't have or plan to have anything like this yet, and it'd need to be 20x more complicated. If you get rid of Rust's magic about being able to remove guards and checks by infering things about the data to make it conform to calling conventions instead of using types, you have just invented C.
- kibwen 9y ago
  > Rust literally has none of these mechanisms and likely never will It's true that Rust has no stable ABI, but "likely never will" is hyperbole. If people demand it in sufficient quantity then it will happen in time. I personally hope it does someday, but I'm in no hurry. > There's a reason C++ names look like CintFuncf!!!@34$902, Rust doesn't have or plan to have anything like this yet, and it'd need to be 20x more complicated. Rust does have name mangling already. It may not be standardized (again, no stable ABI), but C++'s name mangling isn't standardized either. And I see no justification for why name mangling in Rust would need to be "20x more complicated" than in C++; AFAIK Rust symbols pretty much already imitate C++ symbols in order to play nicely with existing tooling. This would be more informative if you gave some concrete examples. Any hypothetical Rust ABI would be more extensive than the de facto C ABIs, undoubtedly, but the concern here seems unjustified.

colechristensen 9y ago

I'm quite bored by the obsession of some for replacing C. Yes, it does exactly what you tell it to do and that's dangerous. It was a high level language 25 years ago, but today the metaphor should be assembly. Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same. The biggest threat to the tech sector is Linus dying and being replaced by some charlatan who insists on replacing C and using Jira. </offtopic>

tonyedgecombe 9y ago
Yes, it does exactly what you tell it to do and that's dangerous. Exactly, if you could get all the benefits without the danger why wouldn't you?
bluejekyll 9y ago
> it does exactly what you tell it to do and that's dangerous. gcc: “hold my beer while I optimize out that block of code you clearly didn’t mean to be in your program”
- hashmal 9y ago
  That's not because of C, that's because of GCC.
  - adrianratnapala 9y ago
    It's because of C as it has been redefined in recent times, but the kinds of people who write standards and compilers. The galling thing is that they did this to win a benchmark war against Fortran.
  - int_19h 9y ago
    gcc does it precisely because the C standard says that it can do so, and any program that's relying on not getting broken that way is not valid C (well, "undefined behavior", but it's the same thing in practice).

qwtel 9y ago

c.f. https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect

hellofunk 9y ago

I've always like the description of C as just being "raw memory, but with syntactic sugar." I think C is still so pervasive for 2 simple reasons (I might be wrong): 1) It's a small language. Compared to many newer languages (Swift, modern C++, old C++, Objective-C, Java), it's quite tiny. The language itself can be learned in short time. (Which is deceptive, because properly using what you have learned takes longer than a short time). 2) It's fast. It's just direct memory access, direct and explicit hardware manipulation. And whether justified or not, there is a very large portion of the developer community that remains obsessed with speed. I see it all the time, even when speed isn't not going to matter enough to justify C. I often see people going way out of their way, making their work much more time-consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can.

danieltillett 9y ago
The thing I love about C is it almost always does what you want fast, but you are never certain. No matter how much you think you know C, there is always some new edge case to experience. C is exciting.
- akvadrako 9y ago
  I completely disagree with this. C is the only language I ever used I felt I had mastered. Sometimes I needed to check things in the spec or pause to consider the C99/C89 discrepancies, but essentially I knew everything about it after just a few years of daily use. I've never felt that way with Python, JS, Ruby, Java, C++ or any of the other languages I've used. They are at least 10X more complex in terms of primitives and non-trivial interactions.
  - barrkel 9y ago
    C is deceptive, though. It encourages a mental model of high-level assembler, but it's an assembler for an abstract machine, not the actual machine; and compilers are increasingly making the difference evident.

faragon 9y ago

C is simple and beautiful.

krapp 9y ago
C is simple, but beauty is in the eye of the beholder.
glandium 9y ago
C looks simple, but is not. That's part of the problem with it.
bjz_ 9y ago
C's semantics are far from simple.
luckydude 9y ago
I agree. The standard, however, is far from simple and beautiful and what people are bitching about are all the weird semantics codified in the standard (I think). What they are not seeing is the simple and beautiful part, which is a shame because I think that's why C is still around and still popular. It's a little like looking at your spouse. You can fixate on the flaws and you'll hate your spouse. You can fixate on the positives and you have a much better chance at loving your spouse. Having a spouse that is artificially constrained to doing only the things you approve of is kind of what the Rust people are trying to do. Feels sort of weird to me but if that's their thing, go for it. Or maybe that's a messed up analogy?

mmjaa 9y ago

It shouldn't be such a surprise, unless one is ignorant of a stable, decades old, computing maxim: Old computers (and by definition, old computer software) never dies. The users do.

blub 9y ago

If something is to replace C (or C++), I hope it's not Rust, because Rust is even more complicated than C++. People should not have to bend their mind to satisfy some tool like the borrow checker, the tool should do the right thing and allow them to express their ideas in code with as little effort as possible.

pygy_ 9y ago
The borrow checker is currently stricter than it should be (it rejects valid programs), which requires workarounds. Once non-lexical lifetimes land, the borrow checker will be less of an issue.
- steveklabnik 9y ago
  This is true of most sound static analysis; the goal is to reject as few programs as possible, but there's always some things that exist in the world that your system can't take into account.
  - icen 9y ago
    For good reason! This is Rice's theorem.
aneutron 9y ago
If it serves the purpose, it is worth the price of changing the way one thinks. You do realise than functional, imperative and procedural programming all coexist in this world. But using functional programming with trees for example makes your job way easier. Except you'll have to change your perspective on programming. It's the same thing with memory safety. If Rust is going to give you a guarantee about the memory safety, then changing your mindset is probably worth. I still consider myself a beginner/novice though, so this is just my opinion.
kibwen 9y ago
> Rust is even more complicated than C++ Example? In my experience, those saying this have either never used Rust, or never used C++. A strict compiler does not a complicated language make. To wit, if the response is "lifetimes", note that lifetime tracking is also critically important in C++ (not to mention C), it's just that C++ compilers give one far less help in doing so than Rust does.

rbanffy 9y ago

The "AHL" name brings me fond memories of Creative Computing magazine and their editor, David H. Ahl. Sadly these AHL's are unrelated.

JacobiX 9y ago

Even in relatively new fields like machine learning, nearly every software that we use at work is written in C or is a wrapper around a C library, or in some cases in Fortran (a 60 years old programming language) : we use extensively PyTorch, torch, numpy, LAPACK, Scipy, etc.

reacweb 9y ago

"C is the desert island language". see http://crypto.stanford.edu/~blynn/c/intro.html http://crypto.stanford.edu/~blynn/c/intro.html For me, Linux is a huge development environment dedicated to C programming. Chapter 2 and 3 of manual pages gives C api. C gives the most direct access to kernel. IMHO we should try to find a replacement for C and the first target for this language should be linux kernel. If you can conceive a language that Linus Torvalds accepts, the rest of the planet will follow ;-)

kwhitefoot 9y ago
> If you can conceive a language that Linus Torvalds accepts Good luck!
Sir_Cmpwn 9y ago
For a new language to have practical applications in the Linux codebase, it has to run on every architecture supported by Linux (and ideally more), and use the same linker and ABI as C. A tall order, to say the least.

jwilk 9y ago

> We rely on Python which is written in C89, a standard older than many of our developers. Python ≥ 3.6 requires (some features of) C99. > Perhaps the reluctance to move to a more ‘modern’ C is that even C99 can’t legally buy a drink Perhaps it's because MSVC didn't fully support anything newer. Source: https://www.python.org/dev/peps/pep-0007/#c-dialect https://www.python.org/dev/peps/pep-0007/#c-dialect

raverbashing 9y ago
And to be honest modern C99 stuff do not solve the fundamental problems in C (and solving those gives you something that is not C) (some of the changes) http://www.open-std.org/jtc1/sc22/wg14/www/newinc9x.htm http://www.open-std.org/jtc1/sc22/wg14/www/newinc9x.htm
ericfrederich 9y ago
Yeah... good luck taking a newer version of Python an compiling it on Visual Studio 2012. I had to jump through hoops even to get 2.7 to compile and wound up abandoning it because it caused problems down the line with ctypes.
- pjmlp 9y ago
  VS2012 is quite pre-historic, we already had 2013, 2015 (with three updates) and are now on the third 2017 update. C99 support was added in VS2015 to the extent required by C++14, similarly C11 support was added in 2017 to the extent required by C++17.
  - dragonwriter 9y ago
    > VS2012 is quite pre-historic You don't work in the enterprise domain which is VS’s core market, do you?
    - jdmichal 9y ago
      Still on Visual Studio 2010 here... The pain is that everyone has to move at once due to the way the project files are upgraded when you open them in a newer version.

userbinator 9y ago

Add to this the disastrously central role that C has played in our ongoing computer security nightmare One sees plenty of news on the downsides, but on the other hand the lack of security has also enabled console homebrew, iOS jailbreaking, Android rooting, and a bunch of other creatively liberating activities which involve doing something not officially sanctioned. It's worth pondering whether we would be better off, had everyone switched to something much "safer" (maybe even with formal verification) a long time ago. I think it's debatable.

kibwen 9y ago
Contrarily, had we 'switched to something much "safer" a long time ago', then by now--out of sheer necessity--we may have been adept at leveraging economics and politics to make hardware user-hackable. As it is we could just be using the swiss-cheese safety of C as a crutch to avoid having to tackle the hard social problems of getting people to care about liberated devices.
- ColanR 9y ago
  Or the number of people interested would have dried up.
  - kibwen 9y ago
    Possible, but doubtful. For ages the default state of software was closed-source, and yet the desire to share and be free did not dry up. People yearn for freedom, and in its absence they will make it, but mildly-comfortable half-solutions have a great way of defusing movements. But slowly the pool of exploits will dry up, either because we stop using C or because we finally figure out a way to write C securely, and we'll find ourselves decades behind at the necessary task of producing hardware that is open by design rather than open by accident.
jstewartmobile 9y ago
Best comment of the thread! "Be careful what you wish for..."
9y ago

jstewartmobile 9y ago

As maddening as it may be, my gut tells me it has more to do with the precompiler than anything else. When it comes to wrestling with cross-platform differences, I don't know of a corresponding feature in Rust or Go that is equally powerful (or equally ugly!). As long as computing remains a battleground where rich assholes put vastly different wrappers around the exact same shit so they can wring more money out of us, I will probably be writing in that abominable assembly language w/ turing-complete string-paster for many years to come.

kibwen 9y ago
Speaking of the C preprocessor, I found this recently: from the Firefox source code, a red-black tree written entirely in 800 lines of C macros: http://searchfox.org/mozilla-central/rev/f54c1723befe6bcc7229f005217d5c681128fcad/memory/build/rb.h http://searchfox.org/mozilla-central/rev/f54c1723befe6bcc722... . Submitted for your enjoyment. :)
- jstewartmobile 9y ago
  I've used OpenBSD's version of that more times than I care to remember: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.29 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/...
- nikbackm 9y ago
  Looks to be some small amount of C code in those macros as well.
- throwme211345 9y ago
  Why would someone do that?
  - dboreham 9y ago
    Because long ago (and probably in a different product) making a function call was significantly costly and worthwhile optimizing away via macros.

Veedrac 9y ago

C was so successful because it had, and to a large extent still has, no competitors.

dboreham 9y ago
It was also free.
- pjmlp 9y ago
  Only on UNIX, until Sun started to charge money for their SDK, which lead to many devs starting to help GCC development.
pjmlp 9y ago
On UNIX, it was barely used outside AT&T until companies started to base their workstation OSes on UNIX.

walshemj 9y ago

So COBOL and Fortan is still going strong in the areas its appropriate for.

goatlover 9y ago
Lisp is still around too. SmallTalk as well.

jasonmaydie 9y ago

it's time we admitted bad code isn't because of the tools we use but a function of how we write code. You can write bad code even in "safe" languages. Leak memory with languages that come with a GC, etc etc.

Ar-Curunir 9y ago
Yes, but some languages make it far easier than others.

throwaway2016a 9y ago

C was the first language I learned in the mid-90s and I still go back to it once and a while when I want raw speed and direct memory access. I know other languages, sure, but I have yet to find a suitable replacement that lets me do what I want to do on a machine level without getting in the way. Lately I've been doing some of the stuff I would normally do in C in GoLang instead. But it still can't match C in performance. (beats the hell out of Node.js though which is where I do most of my middle-tier / front-end code) It also makes an excellent foot gun for the same reason.

deleted 9y ago

[deleted]

jdblair 9y ago

My 2 cents, from the perspective of someone who built a career on writing software in C for small devices. C has longevity b/c its compact and provides a straightforward model of memory on the machine. I understand the desire to use safe, garbage collected, memory safe language when you're serving HTTP requests, but sometimes you need to access the hardware: twiddle a GPIO or read from a DMA device. This is where I've yet to see a good replacement for C, and by extension, C++ (b/c its fundamentally still just C). Maybe rust is there, but I don't have experience there to judge. [edited for clarity]

steveklabnik 9y ago
To be clear, since I have seen this pop up lately, Rust doesn't have a GC and absolutely gives you access to hardware. The challenges for it on embedded are mostly toolchain issues.
- scruple 9y ago
  So, are vendors working on rust toolchains for their hardware? I'm asking from a place of genuine curiosity, I left embedded a number of years ago. I've always viewed the 'rust breaking into embedded' problem as a toolchain issue, as well. But, my intuition is that vendors will be slow to release rust support in toolchains because the industry is still firmly in the "we write in C" camp.
  - steveklabnik 9y ago
    That's what I meant by challenges; it's pretty much "can LLVM support the chip and then did someone put in the compiler work in rustc", rather than "vendors are directly providing Rust support." Your intuition is mine as well.
  - analog31 9y ago
    This is an interesting thread... https://news.ycombinator.com/item?id=14071282 https://news.ycombinator.com/item?id=14071282 In my view the industry inertia is a chicken and egg thing. You want a chip that runs your existing code. Then you want to write new code on your existing chip. And you have ongoing projects at different stages, sharing chips and code.

zeveb 9y ago

> In 1987 this code took around half an hour to run, today 0.03 seconds. Progress eh? The thing I take away when reading this is that in 1987 there were superior languages to C which — while usable — were just a bit too sluggish, and hence lost out. I'm thinking specifically of Smalltalk & Lisp, but I'm sure that there are others (maybe ML was around that far back?). Well, if a program which once ran in half an hour can now run in 300 milliseconds, I think that maybe we should reconsider using just a little of that extra performance to run a better language environment. Imagine if we had OSes written in safe languages which catch errors rather than allowing programs to misbehave. Honestly, it's hard for me to do because I've become so accustomed to crashes. Recently I've been doing some X programming with Lisp, and it's amazing — even when I make a mistake, things keep on running properly. I just see an error and that's that. Well, most of the time, anyway. Nothing's perfect. Still, the experience is orders of magnitude better than writing C. I mean that literally, not figuratively. (Also, as an aside: when I switched tabs to the article, it displayed for just a second, then disappeared. Reader mode didn't even work. I had to enable JavaScript just to view some text. What gives‽)

andrewmcwatters 9y ago
> reconsider using just a little of that extra performance Welcome to software development, where the code is shit, and the hardware improvements don't matter.

tlb 9y ago

I wonder if the danger of C is something people like, deep down. I spent some time talking to people who do dangerous jobs, thinking about automating their jobs with robots. Most of them liked the danger. They enjoyed having mastered the art of not getting killed by falling tree branches, or live wires, or runaway trucks, or whatever the job involved. They felt satisfaction at doing a job where, if someone else tried to do it, they'd probably get hurt on their first day. You can imagine various ways this could have evolved in hunter-gatherer societies. Most new languages are far safer than C. For some that's the main selling point, for others it's just a side-effect of having GC. I wonder if you could get a lot of traction with a language as expressive as Ruby, but with footguns galore. I'm not sure that space has been adequately explored.

AnimalMuppet 9y ago
I wouldn't put it as "danger", exactly. It's freedom. The language won't trap you, pretty much ever. You need to write directly to hardware registers? Fine. You need to drop into assembly for a bit? Go for it. However down-and-dirty you have to get, you can do it. Whereas with some other languages, if you ever need to get more down-and-dirty than the language is designed to allow, even for just a little bit of your program, well, too bad - you're not allowed to.
- pjmlp 9y ago
  I could do all of that in Turbo Pascal, Turbo Basic and Modula-2 compilers.
  - AnimalMuppet 9y ago
    Ah, I had forgotten that Turbo Pascal let you drop into assembly. But could you write directly to a hardware address? I don't know, but I doubt it - Turbo Pascal ran on the PC, which didn't have memory-mapped hardware. You could do an outp. But in C, you could do *(unsigned long*)0xFFFE0004 = 0x8000FF2C; which was either absolutely necessary or absolutely stupid, depending on whether or not you had custom memory-mapped hardware at the specified address. Could you do that in Turbo Pascal? What's more, Turbo Pascal was PC-only, at least initially. If you had to work on a 68000-based embedded system running PDOS (not PC-DOS), and you had to use Pascal, it wasn't Turbo Pascal. It was just bog-standard Pascal. Inline assembler? No way. Pointer to a variable-sized array? Can't do it (you cannot give it a type). It was painful to work in that environment. And that environment was Pascal as specified by the language standard. Turbo Pascal fixed most of the problems, but it trampled all over the standard to do it. (At least it did have separate compilation.) Why was it painful to work in that environment? First, we couldn't access our custom hardware without having to link to an assembly-language subroutine. In doing so, we lost type safety, which led to at least one hard-to-find crash. It also was just much more difficult and error-prone to write those routines. Second, we wanted to have a user-specified variable-sized array. We wound up having to create the largest array we could given the memory the machine had, and only using the part that the user specified, which was a pretty ugly kludge. Third, Pascal was just clumsier to use than C. It was more verbose and more finicky. (One part I remember in particular was the semicolons. You couldn't have a semicolon on the last statement in a block. As you added or removed statements, you kept having to fiddle with the semicolons, including on lines other than the ones you were changing.)

raarts 9y ago

> Add to this the disastrously central role that C has played in our ongoing computer security nightmare Hindsight is 20/20. C was simply the pervasive language when the internet happened. C was designed when the world was a friendlier place, where buffer overflows did not exist. It was embraced by everyone because of its speed and simplicity. No C programmer was raised/educated to have security in the front of his mind. Hell, many programmers of any language still don't. Stop bashing C and start using Oauth instead of inventing your own authentication schemes.

taeric 9y ago
I fully agree with the advice, but I do worry that we are creating a monoculture for authentication. The pessimist in me says it is not if, but when a major vulnerability appears in the Oauth stack. Good thing about most vulnerabilities is that the blast radius can be rather small.
lomnakkus 9y ago
> No C programmer was raised/educated to have security in the front of his mind. It's not about having security in the front of his/her mind. People make mistakes and always will. In C those mistakes very frequently turn into easily exploitable bugs. That is the security problem with C -- not that programmers somehow don't think about security enough[1]. [1] Of course this is also true, but it's not part of the argument against C.
mrec 9y ago
> many programmers of any language still don't I wonder if anyone's trying an explicitly adversarial approach to early CS education. Split your class into two teams, each team produces an implementation, each team scores points for finding vulnerabilities in the other team's implementation. Doesn't really matter what they're implementing as long as there's untrusted input involved.
eighthnate 9y ago
> It was embraced by everyone because of its speed and simplicity. Exactly. The same thing with TCP/IP. People complain about C and TCP/IP because security wasn't baked into these technologies. That's because that wasn't the big concern back then. And the reason C and TCP/IP have legs is because they are very good at what they do. You get the same thing with people complaining about SQL, HTML and every other language/protocol/technology.

dingo_bat 9y ago

In my mind, C very closely resembles what's going on in my mind's model of the computer. I "think" in C when I'm thinking about an algorithm. It's almost exactly the same as the fake language people sometimes use for explaining an algorithm. I think this property contributes towards the popularity. No "artificial" abstractions like classes, templates, modules, imports etc. Just think of the first step you would do to solve a problem, and write it. Then think of the next step, and write that. And you get fast, portable code that produces tiny binaries! What more do you need?

unboxed_type 9y ago
Thou shall embrace the true power of functional programming

Animats 9y ago

C was originally a language for modest size programs on machines with 64K address spaces. C isn't a bad language for a thousand line program. It's a terrible language for a million line program. Just to get memory safety, there's too much that has to be manually coordinated across compilation unit boundaries. The three big questions in C are "how big is it?", "who owns it?", and "who locks it?" The language gives zero help with all of those issues. Most later languages deal with some or all of those issues.

dxhdr 9y ago
C could use a few features to help with million line codebases, like namespaces. Beyond that, programs that large require good human engineering to manage complexity.
baybal2 9y ago
If you look for million line C program, you invariably have to deal with something like Glib

yellowapple 9y ago

"We use git for source control. hg, largely written in Python, was started within a few days with the same goals. Who won?" I somehow doubt git's popularity has a whole lot to do with it having been written in C.

makecheck 9y ago

Binary compatibility is as much a reason as the language itself. For C++ I remember spending years trying to carefully track compiler versions, precise build setup, etc. or your library would probably fail to link. I have never had a binary compatibility problem with a plain C library.

asnyc 9y ago

C exposes you to low level programming environment, memory management and system internals. Its a great base to build upon for programmers. Even after more than a decade, I still have fond memories for K&R C - a must read for programmers.