from Hacker News

50 years of C, the good, the bad and the ugly [video]

by enduku on 12/30/22, 10:28 AM with 254 comments

• by antirez on 12/30/22, 3:03 PM

  A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

• by coldcode on 12/30/22, 4:02 PM

  I bought a C compiler at my job in 1984 because I thought it was the future, then spent nearly a decade writing MacOS apps in C. I even added object extensions to it (for our use) in 1989 because C++ was not an option yet.

  I worked with Objective-C in the late 90s and again in the 2010s, which is basically C with funky object stuff.

  I don't miss it at all. C is very low level and so easy to write bad code in if you don't have solid discipline, the language doesn't help at all, which was not really a design decision back then. The first C compiler we used didn't even support prototypes.

  I exclusively use Swift now.

• by fjfaase on 12/30/22, 1:15 PM

  His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

• by stephc_int13 on 12/30/22, 4:06 PM

  The more I learn about new and less new languages (Zig, Jai, C#) the more I like C and its true simplicity.

  The language has a few irritating historical artefacts and the stdlib API is completely outdated and full of bad design, but there it is still versatile enough for my needs.

• by pjmlp on 12/30/22, 3:03 PM

  > The combination of BASED and REFER leaves the compiler to do the error prone pointer arithmetic while having the same innate efficiency as the clumsy equivalent in C. Add to this that PL/1 (like most contemporary languages) included bounds checking and the result is significantly superior to C.

  https://www.schneier.com/blog/archives/2007/09/the_multics_o...

  "Multics B2 Security Evaluation"

  https://multicians.org/b2.html

  But naturally ignoring it was more fun,

  > Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.

  https://www.bell-labs.com/usr/dmr/www/chist.html

• by FpUser on 12/30/22, 3:38 PM

  He says something like

  >"if you want to write new program in C now think long and hard and pick something else"

  I would not use plain C to write enterprise backend servers. I happily use modern C++ for that.

  For some very low power microcontrollers however I absolutely would. Amount of high quality free tooling and libraries beats everything else.

  From a practical point of view: I've written enough firmware for very lowly microcontrollers like AT90USB1286. Runs like a charm (oldest for 10 years already), did not not require even single bug related update and zero complaints from customers. Changing the language in this particular case would bring no benefits but extra expense.

• by tails4e on 12/30/22, 3:46 PM

  I often wonder why c did not deprecate the bad bits, like the dodgy string functions should at least be behind a switch to enable, like --enable-strcat or something. Even the printf bug when passing a single argument is easily fixed by requiring two arguments at a minimum, etc. Then leveling up the std library to force the use of bounds checked strings and buffers, again hiding the unsafe ones behind switches or unsafe keywords. This woukd allow backwards compatability, while making newer code safer by default.

• by jokoon on 12/30/22, 5:33 PM

  I'm trying to build a language that translates directly to C. I will just implement some features of the language in C, with some headers I can already find.

  It feels like it's the best way I want to do this. That way, a C compiler can do a lot of work I really don't want to do, C already has backends, optimizers, etc etc.

  All I want is a C-like language with native strings, hash map and list, tuples python indentation, vector math, and nothing else, and make it as simple as possible.

  I'm a bit tired of new language trying to do new things, I just want something less verbose than C, but not as powerful as C++, with the feeling of python.

• by jacquesm on 12/30/22, 1:26 PM

  Great talk. Borland should have rated a mention though, their C compiler really popularized C development on Windows.

• by JonChesterfield on 12/30/22, 2:53 PM

  I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.

• by jecel on 12/30/22, 10:19 PM

  An important part of C history is that in the early 1980s the IBM PC and clones became the most popular computer in the world and it was not really compatible with C. You could say your program was "tiny" and limit it to 64KB or fill your code with "near" and "far" pointers (if using Microsoft tools) or use @ instead of * (if using QNX tools), but the cost was not being able to port to/from the VAX/68000 world. All this went away with the 386, but without this problem it is likely that C would have overtaken Pascal even sooner.

  It is not hard to say what is unique about C: it and Forth are the only high level languages with seamless access to memory. If other languages offer it at all, like PEEK and POKE and Basic, it is far more awkward and interrupts your flow. That might be a good thing - the ESPOL compiler mentioned in the talk would print a big fat warning "YOU MUST KNOW WHAT YOU ARE DOING!" after any line in your code doing C-like tricks.

• by Koshkin on 12/30/22, 4:19 PM

  C is like your wife: you love her; you are afraid of her a little; sometimes you wish she was someone else.

• by andsoitis on 12/30/22, 4:57 PM

  Speaker asks: "What can and should replace it?" (i.e. if you started a new project today, what language should you pick instead of C, because C would be the wrong choice).

  He goes on to list the following options (and says C++ does not count), but we'll only know far in the future which would have been the right pick:

  - Rust

  - Go

  - Zig

  - V

  - Nim

  - Swift

  - ...

• by vivegi on 12/31/22, 6:19 AM

  I was in college early '90s in CS&E (Comp Sci & Engg) and we were taught Pascal first, COBOL and then C. Pascal and COBOL in the second year and C in the third year. C++ was already there, and gaining traction and I taught myself C++ (through the Annotated C++ Reference by Stroustrup). By the time I graduated most jobs were expecting C/C++ coding skills and my first job involved coding in C++.

  Nothing compares to the raw power and control we get with C.

  Around '97-98 Java was all the rage. Then Bill Gates did his internet pivot and we had .NET arriving in the '00s. The allure of being able to program in any framework language and interoperate looked like a good thing.

  Over the last 20+ years I had been in the .NET world and just this year I went back to writing in C and it all came back. It is quite refreshing to be completely responsible for every aspect of your code's working. While it is sometimes tedious, nothing beats the power and control of working close to the machine abstraction.

  Just my 2cents.

• by wheelerof4te on 12/30/22, 5:04 PM

  The most complicated and the most simple language at the same time.

• by davidhyde on 12/30/22, 9:11 PM

  I wonder what form a “typescript for c” language would take and if it would be as revolutionary as typescript was for JavaScript applications. I would assume that all the existing c tooling could still be used.