3 ms·

All these come with additional complexity on the syntactic as well as semantic levels. C++ templates are an interesting in-between, between solid and "soft" str

All these come with additional complexity on the syntactic as well as semantic levels. C++ templates are an interesting in-between, between solid and "soft" structure. Not dissimilar to hygienic Lisp macros I think. But all this stuff multiplies complexities of using the language as well as compiler design. Not saying that other approaches are bad, just that C has some qualities that are underappreciated, or simply not understood by many. In case of the preprocessor, while it's certainly flawed, it's good that it's a mechanism that is completely orthogonal to the language. Which means it doesn't interact with the normal syntax and semantics of the language, isn't a complexity multiplier. There is a single, well-chosen interaction point: the lexical syntax (token stream). This makes it hard or impossible to implement certain user-defined extensions in a robust way, but also allows you to do many important tasks of factoring out syntactic boilerplate just fine. And you can do some extremely practical hacks with it that other systems just don't let you do at all. In any case, the cost of using it is very "self-contained".

kaba0 4y ago
> it's good that it's a mechanism that is completely orthogonal to the language I don’t know, doing what equals to find and replacing string inside a Programming language (with a bit exaggeration on my part) seems like a terrible terrible idea, even just for the very trivial reason of outputting paired number of brackets. It is also terrible from a readability and maintainability point of view with quite a few insane hacks of hacks done to implement basic functionality in other languages (there is an infamous macro in the linux kernel that is so cleverly hacky that it is on another level). And all that for nothing, as the language is incapable of expressing even such a basic thing as a generic array/vector-like data structure without a huge indirection, let alone more complex things. Minimalism is a nice goal, but without abstractibility/expressivity it is useless.
- jstimpfle 4y ago
  > (there is an infamous macro in the linux kernel that is so cleverly hacky that it is on another level) Probably that says more about the particular programmer than it says about macros. Also on a Linux kernel scale some tradeoffs are different. > And all that for nothing, as the language is incapable of expressing even such a basic thing as a generic array/vector-like data structure Something you often do not do when programming in C. You do not want "vector", reallocating by a constant factor without second thoughts, for "serious" systems programming. Same goes for much of the other stuff that is in STL for example. And you can in fact design macros in a few lines that allow you to do something like DECLARE_CHUNKLIST(My_Foo_Type) foo_chunklist; CHUNKLIST_PUSH(&foo_chunklist) = make_foo(); I.e. In fact no terrible noise involved. The hack employed here is #define DECLARE_CHUNKLIST(type) union { type *_type; struct { /* chunklist implementation ... */ } _impl; } which allows the list to carry its own type to support operations like CHUNKLIST_PUSH. For good ergonomics this relies on typeof(). But again, there is a lot of "serious" programming that gets by just fine without any of such hacks. Sometimes you're programming an event handling system where you mostle use fixed-size but dynamically-allocated buffers and push those around. There is very little generic code used here, the functions you write are dealing with concrete flat buffers mostly.

kaba0 4y ago

> it's good that it's a mechanism that is completely orthogonal to the language I don’t know, doing what equals to find and replacing string inside a Programming language (with a bit exaggeration on my part) seems like a terrible terrible idea, even just for the very trivial reason of outputting paired number of brackets. It is also terrible from a readability and maintainability point of view with quite a few insane hacks of hacks done to implement basic functionality in other languages (there is an infamous macro in the linux kernel that is so cleverly hacky that it is on another level). And all that for nothing, as the language is incapable of expressing even such a basic thing as a generic array/vector-like data structure without a huge indirection, let alone more complex things. Minimalism is a nice goal, but without abstractibility/expressivity it is useless.

jstimpfle 4y ago
> (there is an infamous macro in the linux kernel that is so cleverly hacky that it is on another level) Probably that says more about the particular programmer than it says about macros. Also on a Linux kernel scale some tradeoffs are different. > And all that for nothing, as the language is incapable of expressing even such a basic thing as a generic array/vector-like data structure Something you often do not do when programming in C. You do not want "vector", reallocating by a constant factor without second thoughts, for "serious" systems programming. Same goes for much of the other stuff that is in STL for example. And you can in fact design macros in a few lines that allow you to do something like DECLARE_CHUNKLIST(My_Foo_Type) foo_chunklist; CHUNKLIST_PUSH(&foo_chunklist) = make_foo(); I.e. In fact no terrible noise involved. The hack employed here is #define DECLARE_CHUNKLIST(type) union { type *_type; struct { /* chunklist implementation ... */ } _impl; } which allows the list to carry its own type to support operations like CHUNKLIST_PUSH. For good ergonomics this relies on typeof(). But again, there is a lot of "serious" programming that gets by just fine without any of such hacks. Sometimes you're programming an event handling system where you mostle use fixed-size but dynamically-allocated buffers and push those around. There is very little generic code used here, the functions you write are dealing with concrete flat buffers mostly.