6 ms·

To be fair you're rolling in the luxury of hindsight. It wasn't that log ago that a supercomputers had only a few MB of memory. Price US$7.9 million in 1977 (e

To be fair you're rolling in the luxury of hindsight. It wasn't that log ago that a supercomputers had only a few MB of memory. Price US$7.9 million in 1977 (equivalent to $33.3 million in 2019) Weight 5.5 tons (Cray-1A) Memory 8.39 Megabytes https://en.wikipedia.org/wiki/Cray-1#Cray-1M https://en.wikipedia.org/wiki/Cray-1#Cray-1M in the 1970s. Dig up the spec of the PDP and be, well, something'd. Not sure what. Glad you were born now, I guess.

qsort 6y ago
Not sure how this is relevant to the topic at hand. Sure, there are many features of C that are easy to laugh at but in context make a lot of sense, but the macro system is not one of them. Hart/Levin LISP had hygienic macros, just saying... And you don't even need the full generality of a compiler to have limited but still useful AST-rewriting macros, there are a ton of ways this could be implemented very cheaply in terms of both memory and cpu, none of which are rocket science. Seriously, the fact that textual macros are terrible isn't even a controversial point. Maybe I'm too young to be a Real Programmer(tm), but this 'everything is text' idea never made sense to me.
- deleted 6y ago
  [deleted]
- Supermancho 6y ago
  > 'everything is text' idea never made sense to me. As a Programmer(tm), you spend more time debugging code (or specifically, reading it) than writing code. Everything as text makes this less painful than sussing it out of ASM behavior. It's a natural conclusion, given enough time.
- renox 6y ago
  I don't know: debugging textual macro isn't fun but it isn't that hard either (provided you can convince your stupid build system to add a -E to your compiler flags), debugging AST macro sounds to me like debugging templates: a nightmare..
  - qsort 6y ago
    It's true that going down the macro rabbit hole is hardly ever a win, no matter how you handle it. But I don't buy that textual macros are really any better. For starters, they are impossible to reason about, because they can always involve action at a distance. Also you are completely giving up whatever type safety you have (which is admittedly not much in pure C, but better than nothing), and because cpp has no notion of what valid C looks like, your program could even compile without even printing a warning if you write a macro that's wrong just in the right way. There are cases where a simple textual macro is fine, and that's what the designers probably envisioned. But it's a slippery slope: because the macro system is there, it will be used, and because it will be used, it will shape how the language looks around itself.
- AnimalMuppet 6y ago
  Lisp's syntax (or lack thereof) make it much easier to write a macro processor for than something like C, though. If your position is "They shouldn't have used something with that complicated a syntax", that might be a defensible point, but now we're not talking about the preprocessor.
  - qsort 6y ago
    My position is that the preprocessor (at least as far as textual substitution macros are concerned) was a mistake even considering the technical limitations of the time, unlike features like raw pointers, abundance of undefined behavior, void, etc., that are bad right now but were completely understandable (and likely even better than any other realistic alternative) at the time. constexpr + inline would have covered 99% of the macro use cases. Alternatively, a limited system of AST rewriting wouldn't have been significantly harder to write than cpp and would have achieved many of the same goals. As a totally random, non-factual, non-argumentative guess that could be 100% wrong, I believe the idea of the preprocessor was influenced by the general 'unix philosophy' principle that everything should be treated as text.
    - throwaway_pdp09 6y ago
      No offence but you're not recognising that things were very, very different. C was designed as a language for small sytems. It's used for ridiculously large and inapprpriate thinga now. The #include is terrible but it was ok back then - things were small enough to hold in your head. No longer. Compilers were simpler back when C was designed. IIRC PDPs often had just a few K of memory. A megabyte would be huge in the 80's. A textual preprocessor can be done in a couple of K I'd guess, or less. Also a preprocessor is useful for many other things unrelated to the C language. I understand your frustration but things started that way for a good reason, please don't criticise unless you really understand that. Feel free to criticise the inertia that means we have much the same stuff nearly half a century later (but also understand why).

qsort 6y ago

Not sure how this is relevant to the topic at hand. Sure, there are many features of C that are easy to laugh at but in context make a lot of sense, but the macro system is not one of them. Hart/Levin LISP had hygienic macros, just saying... And you don't even need the full generality of a compiler to have limited but still useful AST-rewriting macros, there are a ton of ways this could be implemented very cheaply in terms of both memory and cpu, none of which are rocket science. Seriously, the fact that textual macros are terrible isn't even a controversial point. Maybe I'm too young to be a Real Programmer(tm), but this 'everything is text' idea never made sense to me.

deleted 6y ago
[deleted]
Supermancho 6y ago
> 'everything is text' idea never made sense to me. As a Programmer(tm), you spend more time debugging code (or specifically, reading it) than writing code. Everything as text makes this less painful than sussing it out of ASM behavior. It's a natural conclusion, given enough time.
renox 6y ago
I don't know: debugging textual macro isn't fun but it isn't that hard either (provided you can convince your stupid build system to add a -E to your compiler flags), debugging AST macro sounds to me like debugging templates: a nightmare..
- qsort 6y ago
  It's true that going down the macro rabbit hole is hardly ever a win, no matter how you handle it. But I don't buy that textual macros are really any better. For starters, they are impossible to reason about, because they can always involve action at a distance. Also you are completely giving up whatever type safety you have (which is admittedly not much in pure C, but better than nothing), and because cpp has no notion of what valid C looks like, your program could even compile without even printing a warning if you write a macro that's wrong just in the right way. There are cases where a simple textual macro is fine, and that's what the designers probably envisioned. But it's a slippery slope: because the macro system is there, it will be used, and because it will be used, it will shape how the language looks around itself.
AnimalMuppet 6y ago
Lisp's syntax (or lack thereof) make it much easier to write a macro processor for than something like C, though. If your position is "They shouldn't have used something with that complicated a syntax", that might be a defensible point, but now we're not talking about the preprocessor.
- qsort 6y ago
  My position is that the preprocessor (at least as far as textual substitution macros are concerned) was a mistake even considering the technical limitations of the time, unlike features like raw pointers, abundance of undefined behavior, void, etc., that are bad right now but were completely understandable (and likely even better than any other realistic alternative) at the time. constexpr + inline would have covered 99% of the macro use cases. Alternatively, a limited system of AST rewriting wouldn't have been significantly harder to write than cpp and would have achieved many of the same goals. As a totally random, non-factual, non-argumentative guess that could be 100% wrong, I believe the idea of the preprocessor was influenced by the general 'unix philosophy' principle that everything should be treated as text.
  - throwaway_pdp09 6y ago
    No offence but you're not recognising that things were very, very different. C was designed as a language for small sytems. It's used for ridiculously large and inapprpriate thinga now. The #include is terrible but it was ok back then - things were small enough to hold in your head. No longer. Compilers were simpler back when C was designed. IIRC PDPs often had just a few K of memory. A megabyte would be huge in the 80's. A textual preprocessor can be done in a couple of K I'd guess, or less. Also a preprocessor is useful for many other things unrelated to the C language. I understand your frustration but things started that way for a good reason, please don't criticise unless you really understand that. Feel free to criticise the inertia that means we have much the same stuff nearly half a century later (but also understand why).