6 ms·

>You better know what you're calling in C. If you don't want to know what you're calling, don't write C. That puts a de-facto cap on either the speed of C deve

>You better know what you're calling in C. If you don't want to know what you're calling, don't write C. That puts a de-facto cap on either the speed of C development or the size of C projects. It is definitely possible to have a project so large that no one person can understand it all. So either you can't have C projects larger than whatever that size is, lest you risk not knowing what you're calling, or you have to accept that developers working on your project will be reading and re-reading parts of source code that haven't changed in years in order to make sure they know what they're calling, rather than re-implementing common patterns in the codebase and trusting to prior diligence. Either way, you're not selling C to me as a language to embark upon a major project with.

bandushrew 10y ago
I have no interesting in convincing you to use C for anything, but it IS true in absolutely any language that if you are changing it, you should know what you are changing and how it works. You don't need to know the entire project, but you had damn well better understand the code right in front of you that you are editing. In literally any language, developers who don't understand what they are changing will cause bugs.
derefr 10y ago
"What you're calling" in the sense of "what the syntax elements, language-intrinsics, and macros you're using mean", not "what you're calling" in terms of plain-function APIs. Macros (in any language, not just C) are the big problem, because you have to know a macro's definition before you can know precisely what its usage rules are. Without macros, C projects can get as large as they like. Everyone must be required to know the language, but you can work on any plain-functional project given that knowledge. Once you start #define-ing tons of preprocessor macro-functions, all bets are off; now your project is essentially its own language that every developer must first familiarize themselves with before usefully contributing, and that does indeed put "a de-facto cap on either the speed ... or the size" of projects.
- kllrnohj 10y ago
  > Macros (in any language, not just C) are the big problem Not true, see: https://doc.rust-lang.org/book/macros.html#hygiene https://doc.rust-lang.org/book/macros.html#hygiene (not unique to Rust, though, Scheme even has some of this like Hygienic macros) Macros don't have to be C-style simple text substitution.
  - derefr 10y ago
    Hygenic macros are still "the big problem." There is a reason there are no thousand-developer FOSS projects written in a Lisp; and there is a reason Ruby is derided for "monkey-patching"; and there is a reason that a single parse-transform in an Erlang project is a very strong code-smell that needs intensive justification. The reason, in all of these cases, is that a project that includes one unique macro definition, is now a project effectively written in a different language—"language Foo, plus macro Bar." HN, for example, is written in Arc, a.k.a. "Racket + several macros." Emacs is written in Emacs Lisp, a.k.a. "MacLisp + quite a few macros." In general, if a project goes on long enough without any prohibition against adding yet another macro to the codebase, eventually that project—like Arc, like Emacs—will have accidentally created an entirely-separate language. But before then—even on the commit of the very first macro definition—the prerequisite knowledge required to contribute to the codebase has now diverged: you can't just jump in as someone who "knows Foo" and immediately understand the logical flow of 100% of the code. To contribute to such projects, people have to learn how the macros change the logical flow—i.e. learn that diverged language. To which they very likely will say: screw that! Thus capping the number of contributors, and/or the speed of development.
    - kazinator 10y ago
      > There is a reason there are no thousand-developer FOSS projects written in a Lisp Yes; the main one being that about 996 of them wouldn't have anything to do. > you can't just jump in as someone who "knows Foo" and immediately understand the logical flow of 100% of the code. Can you just jump into the Linux kernel as "someone who knows C" and understand the logical flow of everything? USB, TCP/IP stack, virtual memory, file systems, block devices, scheduler, ...
marcosdumay 10y ago
> That puts a de-facto cap on either the speed of C development or the size of C projects. I don't think anybody will disagree.
stouset 10y ago
> Either way, you're not selling C to me as a language to embark upon a major project with. Sounds about right. I dearly love C, but it's time to move on. Languages like Rust seem to solve most of the major pitfalls while not sacrificing on speed.
- socmag 10y ago
  Is that something you are just musing out loud, or are you proselytizing? If it is the former free to use whatever language you choose. If it is the latter, can you please keep your opinion as just that. I believe we are all adults here and quite capable of making judgment calls. Rust has some interesting features and lots of other languages too. No need for the drive by.
  - stouset 10y ago
    Who pissed in your cornflakes? I'm not sure how much more diplomatically I could have phrased my previous post. If mentioning a language as one possible modern alternative ("languages like Rust") is enough to set you off, perhaps you need to reconsider who's falling short of adulthood here.
    - socmag 10y ago
      That's not actually what you said. What you said is it is about time we moved on from C and suggested Rust. That seems like your own subjective opinion. Which is fine of course, each to their own. Personally I will continue to use whatever language makes sense for the job no matter what it might be. Happy to take one for the team if that stance doesn't work for you, I'm not the one here passively aggressively proselytizing. And thank you for confirming that by the way.

bandushrew 10y ago

I have no interesting in convincing you to use C for anything, but it IS true in absolutely any language that if you are changing it, you should know what you are changing and how it works. You don't need to know the entire project, but you had damn well better understand the code right in front of you that you are editing. In literally any language, developers who don't understand what they are changing will cause bugs.

derefr 10y ago

"What you're calling" in the sense of "what the syntax elements, language-intrinsics, and macros you're using mean", not "what you're calling" in terms of plain-function APIs. Macros (in any language, not just C) are the big problem, because you have to know a macro's definition before you can know precisely what its usage rules are. Without macros, C projects can get as large as they like. Everyone must be required to know the language, but you can work on any plain-functional project given that knowledge. Once you start #define-ing tons of preprocessor macro-functions, all bets are off; now your project is essentially its own language that every developer must first familiarize themselves with before usefully contributing, and that does indeed put "a de-facto cap on either the speed ... or the size" of projects.

kllrnohj 10y ago
> Macros (in any language, not just C) are the big problem Not true, see: https://doc.rust-lang.org/book/macros.html#hygiene https://doc.rust-lang.org/book/macros.html#hygiene (not unique to Rust, though, Scheme even has some of this like Hygienic macros) Macros don't have to be C-style simple text substitution.
- derefr 10y ago
  Hygenic macros are still "the big problem." There is a reason there are no thousand-developer FOSS projects written in a Lisp; and there is a reason Ruby is derided for "monkey-patching"; and there is a reason that a single parse-transform in an Erlang project is a very strong code-smell that needs intensive justification. The reason, in all of these cases, is that a project that includes one unique macro definition, is now a project effectively written in a different language—"language Foo, plus macro Bar." HN, for example, is written in Arc, a.k.a. "Racket + several macros." Emacs is written in Emacs Lisp, a.k.a. "MacLisp + quite a few macros." In general, if a project goes on long enough without any prohibition against adding yet another macro to the codebase, eventually that project—like Arc, like Emacs—will have accidentally created an entirely-separate language. But before then—even on the commit of the very first macro definition—the prerequisite knowledge required to contribute to the codebase has now diverged: you can't just jump in as someone who "knows Foo" and immediately understand the logical flow of 100% of the code. To contribute to such projects, people have to learn how the macros change the logical flow—i.e. learn that diverged language. To which they very likely will say: screw that! Thus capping the number of contributors, and/or the speed of development.
  - kazinator 10y ago
    > There is a reason there are no thousand-developer FOSS projects written in a Lisp Yes; the main one being that about 996 of them wouldn't have anything to do. > you can't just jump in as someone who "knows Foo" and immediately understand the logical flow of 100% of the code. Can you just jump into the Linux kernel as "someone who knows C" and understand the logical flow of everything? USB, TCP/IP stack, virtual memory, file systems, block devices, scheduler, ...

marcosdumay 10y ago

> That puts a de-facto cap on either the speed of C development or the size of C projects. I don't think anybody will disagree.

stouset 10y ago

> Either way, you're not selling C to me as a language to embark upon a major project with. Sounds about right. I dearly love C, but it's time to move on. Languages like Rust seem to solve most of the major pitfalls while not sacrificing on speed.

socmag 10y ago
Is that something you are just musing out loud, or are you proselytizing? If it is the former free to use whatever language you choose. If it is the latter, can you please keep your opinion as just that. I believe we are all adults here and quite capable of making judgment calls. Rust has some interesting features and lots of other languages too. No need for the drive by.
- stouset 10y ago
  Who pissed in your cornflakes? I'm not sure how much more diplomatically I could have phrased my previous post. If mentioning a language as one possible modern alternative ("languages like Rust") is enough to set you off, perhaps you need to reconsider who's falling short of adulthood here.
  - socmag 10y ago
    That's not actually what you said. What you said is it is about time we moved on from C and suggested Rust. That seems like your own subjective opinion. Which is fine of course, each to their own. Personally I will continue to use whatever language makes sense for the job no matter what it might be. Happy to take one for the team if that stance doesn't work for you, I'm not the one here passively aggressively proselytizing. And thank you for confirming that by the way.