Hacker News Reader

I don't think C is un-opinioniated. It's opinions are just quite popular, so people don't think they are opinions.

I mean, there are always matters of degree. Sure C imposes some structure by nature of it's syntactic choices, but it's extremely wide-open when compared to other programming languages.

Lisp, for example, is very opinionated when it comes to things like side-effects. Go is opinionated when it comes to how memory should be managed. Rust is opinionated about when data should be readable and writable, and passed between threads.

C doesn't impose any of these restrictions, largely by virtue of being low-level, and moreover, it should be possible to implement whatever data transforms are implemented in any of those other languages in C as well. The inverse is not the case, so I would argue that C is more permissive than any of those languages.

Is Lisp opinionated about side-effects? Maybe Clojure is, but have you looked at Common Lisp or Emacs? I can't think of a less-opinionated-about-side-effects application than Emacs.

Lisp is opinionated about side effects like this.

* In the absence of language extensions, you don't have a pointer type that can be incremented all over the place and dereferenced. You don't just mutate memory willy nilly.

* In relation to the above point, (in the absence of a language extension like "locatives") there is no address-of operator; we can't pass the address of a variable somewhere to have it changed. This can be simulated with a lexical closure, whereby we provide the function to do perform the change, which is called from somewhere. "Use lexical closures as thunks if you want var parameters" is quite opinionated.

* All mutation takes place through data-structure-specific functions (like rplaca for mutating the car of a cons cell), or dedicated special forms (like setq for mutating a variable). The use of generalized places like (incf (car x)) compiles into type-safe function calls. On one particular Lisp, CLISP, that looks like:

  1> (macroexpand '(incf (car x)))
  (LET* ((#:TEMP-3341 X) (#:NEW-3340 (+ (CAR #:TEMP-3341) 1)))
    (SYSTEM::%RPLACA #:TEMP-3341 #:NEW-3340))

there is no idea there of calculating some effective address and just clobbering bits through that pointer. The original value is accessed using car, and the mutation happens opaquely inside the SYSTEM::%RPLACA function. That could be inlined by the compiler, but the model is basically that mutation of objects is done via an API.

* The argument evaluation order of standard functions is well-defined, so side effects occurring in argument forms are well sequenced:

   (let ((x 0))
     (list (incf x) (incf x) (incf x)))
   --> (1 2 3) ;; required result in ANSI Lisp

(Scheme bungles this by having less of an opinion; it has C-like unspecified argument eval order.)

> Lisp, for example, is very opinionated when it comes to things like side-effects

Ermm...no, it's not. Functional programming languages do tend to do that, but most lisps aren't functional--certainly, it's not a defining characteristic of the language family.

> C doesn't impose any of these restrictions, largely by virtue of being low-level, and moreover, it should be possible to implement whatever data transforms are implemented in any of those other languages in C as well. The inverse is not the case, so I would argue that C is more permissive than any of those languages.

1. Turing equivalence.

2. Because it's so close to the hardware, c inherits the opinions of all the major ISA designers.

> Ermm...no, it's not. Functional programming languages do tend to do that, but most lisps aren't functional--certainly, it's not a defining characteristic of the language family.

Fair enough. I haven't worked with Lisp since university days, but I think the point stands with any strict functional language.

> 1. Turing equivalence.

Ok technically it's possible to write programs which perform the same computation any two turing-complete languages, but what I mean is that, for example, it's easier to emulate how an arbitrary Go program performs that computation from C than in the other direction.

edit:

> 2. Because it's so close to the hardware, c inherits the opinions of all the major ISA designers.

That's one way to look at it. Another way is that C just gives you an interface to the hardware as it is, and doesn't make many judgements about which abstractions should be built on top of it by default.

C is not close to the hardware: vectors are a bolted on afterthought, especially multidimensional arrays. The carry flag and floating point environment are afterthoughts. One of my coworkers uses assembly for just this reason!

C does not have vectors. C++ has them. Do you mean arrays? Arrays are just translated to pointer arithmetic formulas based on the type/size of the array's elements.

> C doesn't impose any of these restrictions, largely by virtue of being low-level, and moreover, it should be possible to implement whatever data transforms are implemented in any of those other languages in C as well.

You're conflating lack of guardrails & helpers with "low-level". C is not lower level than Rust or C++, not at all. It's just more dangerous, and that danger brings no "low-level-ness" advantages.

> it should be possible to implement whatever data transforms are implemented in any of those other languages in C as well.

Define what you consider "possible" here. There's a bunch of things I'd consider "not possible" in C that you can do trivially in C++/Rust, such as the codegen templates & coroutines perform, for example. If you throw enough macro pre-processor hacks at it to the point it doesn't reassemble C in the slightest sure you can sort of pull it off. But is that sort of thing considered "possible in C"? Or have you just made a second language in front of C that happens to compile to C via the hello world of compilers?

Even with macros I'm not entirely sure you can actually do something like static_assert in C since you can't put an #error in a macro substitution. Or more practically defining the backing type of an enum

C is not opinionated enough w.r.t. side effects and order of evaluation, which means that programmers have to learn to be highly opinionated "human compilers" to avoid writing bogus code.

There's a reasonably unambiguous way to measure how "opinionated" a language is, which is to look at the size of its runtime necessary to run programs in that language [1]. C's is not huge, but it is necessary and non-zero. By contrast, many other languages have huge runtimes.

There are some languages that can get smaller than C. Assembler, obviously, is basically the smallest. Rust does have a default runtime, but it's thin, and most of the rest of it can be shut off. Still, it's not a long list of languages that are less opinionated than C.

[1]: If you want to get really technical, this is "relative to the hardware it is running on". C gets a bit of a bonus here because the hardware has over the decades actively targeted C. Particularly visible in the processor's support for calling conventions, and manipulating a "stack" so natively. (While a stack is really, really convenient, it is not, strictly speaking, necessary for programs to be structured that way.) But for the sake of simplicity I'll ignore that for now.

I think of "opinionated" more as a measure of how how much structure a language imposes on you as a programmer.

For instance, Javascript has a massive runtime, but I'd say it's an extremely unopinionated language. If you want, you can implement a Javascript function which rewrites itself every time it's executed.

In my opinion Rust is an extremely opinionated language.

That's a perfectly valid definition of opinionated, and it measures another aspect of a language.

Languages have a lot of aspects.

I used this aspect because upthread we were discussing memory management and "portable assembly". In another context I'd happily use this concept instead.

Indeed. For instance, C has opinions like:

- If you're a variadic function, you're forbidden to know directly how many arguments you have been given and what their types are"

- If you're any function, you may know who called you, without resorting to platform-specific extensions that come with various limitations.

- You may not know which areas of your activation chain are root pointers, for implementing accurate garbage collection.

- You may not dynamically construct a function call with arbitrary arguments and invoke it

I've always argued against the idea that "portable assembly" is a useful way to look at C. It is terrible for the purpose in the sense that the compiler is allowed to generate code that has little to do with what you wrote in terms of procedure. Assembly on the other hand is useful exactly because it affords minute control of procedure.

In my view, C is a secretly declarative language where your program is a declaration of constraints for the optimizing back-end that just happens to look a lot like procedural code.

I can write what looks like function containing a loop or a memory write and call it from main only to end up with a program that only loads a constant in a register and returns. Because of this and the sometimes complex conditions that enable some optimizations, it's hard to argue about C code in terms of its performance without falling back on analyzing the actual "non-portable" assembler output of the compiler.

Have a look at Zig. That's what it's trying to achieve.

Thanks, I will check it out.

C will remain relevant because Linux is written in C. Accessing all the core functionality of the os (networking, files, ipc...) requires using C libraries the os provides.

Even stronger than that - C will remain relevant because Linux (or OS in general) MUST be written in C (or assembly, but good luck with that).

C's flaw: memory can fail. C's (necessary) advantage for writing an OS: memory can fail.

This is quite easy to refute: https://www.redox-os.org/ http://menuetos.net/

And what does “memory can fail” mean? Cosmic rays? Those aren’t really good for anything afaik.

Using libc isn't a strong requirement. There's nothing stopping you from making your own syscalls for everything in the language of your choice. I recon C remains relevant because replacing what's already been written in it is a lot of work for very little benefit.

Making raw syscalls directly is precisely what Go does, in fact.

I only heard about that because they ran into several issues and random crashes. Afaik the kernel just assumes it is dealing with a C style caller.

I think that manu of C issues come from the APIs rather than the language. You could do safe memory management by only using refcounts in the api and sticking to it. You could have bound checking in the strings library. But strings are 0 ended (more an API design since strings are not in C). Not saying that its bad design because it allows >256 length strings with only one byte of overhead. But it is a compromise that made sense but has its drawbacks. There are a few stdlib complements in C (strlcpy, antirez sds lib for strings) but it's a shame a more modern lib/runtime has not been established as a standard while keeping C strengths. Or maybe I'm ignorant.

Zero-terminated strings are part of c.

  "asdf" // c string literal, terminated by a 0

Ah, sure I forgot this one. Dunno, I thought C with better strings and libs would go a long way without going full c++/go/nim/rust/zig.

> I don't think C's memory management is bad. It's not right for heaps of problems

Pun intended?

I think you're right. I'm by no measure a C programmer, but I've always regarded it as something that people don't like coding in because it's difficult, not because it's a bad language. Most people complaining about C are like guitar players complaining about the piano. It's more complex, but it has to be given its role.

That said, the fact that K&R didn't specify the size of an int or long complicated matters, but it seems to be an accident of history, not a mistake in design. They had no choice.

I'm a C programmer. I don't know if I'd say it's a bad language, but I definitely hate it. I agree wholeheartedly with OP about the quality of life stuff.

I'm constantly amazed by what C will let you do. The footguns and lack of type checking. C compilers will link a function to a variable for instance. Don't forward declare your functions, and you might not even get a warning (yes some compilers don't give warnings by default for implicit functions). The linker will then go to the symbol table find anything that matches and place a function call. That's just one example, but they're many. C builds erroneous code.

>yes some compilers don't give warnings by default for implicit functions

Broken or ancient compilers. That's as much C's fault as it's Intel's fault that Windows 10 doesn't run on Pentium MMX. Implicit functions are not part of C; they were gotten rid of back in 1999!

I agree to some extent (I'd also add that undisciplined and apathetic programmers are an even bigger problem).

I have to disagree about implicit functions not being a part of C anymore. I've yet to see one generate an error; this is optional, and frequently not used. I'm including brand new, state of the art compilers, even (default) gcc. Of course, not even emitting a warning is bananas.

I confirmed this, with the following snippet:

// start fail.c

int fail = 0;

// end fail.c

int main(void)

{

   fail();
   return 0;

}

gcc --std=c99 -g main.c fail.c -o main.exe && gdb main.exe -ex run

# Cmd line junk, however a warning was emitted for implicit function "fail"

Program received signal SIGSEGV, Segmentation fault.

0x00407020 in fail ()

>I have to disagree about implicit functions not being a part of C anymore. I've yet to see one generate an error;

This is not really a debatable matter. There's an international standard for what is, and what is not a part of the C language.

Errors as you seem to understand them are optional for everything else except for the #error preprocessor directive. For all the other invalid C programs, only a diagnostic (like the warning you got) is required, and a conforming implementation is free to complete translating the invalid translation unit. I don't see why that would be an issue, as it's very easy to switch those warnings into translation errors if wanted.

My preferred workaround for this is to write C code that is accepted by a C++1x compiler under fairly strict warning settings, and use a few standard macros that compile to the usual unsafe constructs in C but allow the C++ compiler to enforce extra rules. E.g. I use {S,K,R}_CAST macros instead of plain C casts.

Although it was great for it's time, I think now (2019) it's rather silly that you de facto must learn three languages to use C:. C, C preprocessor, and make.

If I had to do that every day (I don't use c, except passingly, and usually in read-only mode) I'd tear my hair out, and that's even before the inevitable footguns I'd write.

That's not even the half of it. Dealing with the differences between compilers, oftentimes preemptively, and various standards. For a very long time, it was common to build under c89 "just in case". Now you have to deal with the differences between c89, c99, and various industry/internal standards. That's not even considering how configurable compilers are, and all the features to consider. Then as you said, make or IDE.

Much of this isn't necessarily specific to C (lots of toolchains include build scripts, complicated settings, different language revisions, standards, ect., ect., ect.) It does feel especially bad in C though.

> I think now (2019) it's rather silly that you de facto must learn three languages to use C:. C, C preprocessor, and make.

That's basically the case with nearly every language. Most will have some sort of equivalent of the pre-processor and it's usually a lot more complicated, c++ template craziness, code generation tools, dynamic meta-programming tools, etc. For all it's faults the simple text substitution of most macros is the least complicated option.

Most languages will have there own build tools as well, sometimes it will be the same language with something like rake, other times it's xml or it's own language. And they're nearly always inferior to make in many ways.

> the fact that K&R didn't specify the size of an int or long complicated matter

I disagree. I'm glad they didn't -- we may have been stuck with 2 byte ints and 4 byte longs!

To quote the standard:

> A "plain" int object has the natural size suggested by the architecture of the execution environment

If you want a portable assembler, you absolutely need a type like C's int. Meanwhile, stdint.h provides fixed-width integers if you really need them.

> I disagree. I'm glad they didn't -- we may have been stuck with 2 byte ints and 4 byte longs!

At least then "long" would have a usage, whereas currently it's entirely dead & useless, and it'd be much easier to deal with printf's string formatting than the PRId64 nonsense.

The named-size types (int32_t, etc..) are king anyway