4 ms·

The whole bulleted list from "Custom Memory Safety"... this makes me want to run away towards the horizon and scream. In the 90's it was very common that big s

The whole bulleted list from "Custom Memory Safety"... this makes me want to run away towards the horizon and scream. In the 90's it was very common that big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library. I had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff and yet the authors believed themselves to be geniuses. I mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that. My favorite C code is the one that has no macros, as few of typedefs as possible, no acrobatics with alloca() or any platform-dependent stuff. I think, FIO is a good example of what I'm talking about. The whole thing just sounds like "yeah, it's a swamp, but it's my swamp and I like my swamp!" kind of thing.

woodruffw 4y ago
Well put. Another way to think about it: every major OS and systems vendor has had some custom “safe” C variant over the years, to empirically mediocre results. It's unlikely that this author has done better; it’s much more likely they simply haven’t received the same scrutiny.
- gavinhoward 4y ago
  Author here. I know this. The only reason the custom stuff works for me is because it works for me. I accept no outside contributions, and this is one reason why.
simplotek 4y ago
> (...) big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library. It sounds like you're talking about using libraries as if it was a bad thing. > had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff (...) Where do you think "off-the-shelf" stuff comes from? It sounds like you're trying to mistepresent the adoption of subjectively sub-optimal libraries as somehow the issue caused by using libraries and frameworks. > mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that. You're showing a tremendously naive and misguided belief that libraries are somehow bad. Languages such as Rust flourish with the adoption of third party libraries,some of them euphemistically described as "not stable". Languages such as C++ flourish with third-party components like Boost and POCO. But applying the same principle to a language like C warrants an automatic and mindless putdown like blindly accusing anything of being bad? It makes no sense.
- davisoneee 4y ago
  A more generous interpretation would be that if you have a communal library, rather than everyone having their own individual libraries, it's easier to vet it for correctness. Rust takes the communal approach. The parent was suggesting that every company has an insular library approach. NIH. Many people that go off the beaten track often fall into the same ditch.
  - menaerus 4y ago
    Correctness yes but what about other requirements people have such as performance, extended functionality, domain-specific optimizations, predictability, etc. Third-party libraries were not born out of the thin air but because of different parties having different and very much often disjoint requirements so it's not particularly NIH syndrome.
- d0mine 4y ago
  There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that).
  - simplotek 4y ago
    > There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that) You're somehow trying to imply that libraries are not reusable if they are not widely shared, which makes no sense at all. The best argument you could make is regarding stability, but you simply cannot lay any such claim just from the library's licensing. Accusing internal libraries of being half-baked, badly designed, or bug-riddled is just a cheap blanket putdown.
- crabbone 4y ago
  > It sounds like you're talking about using libraries as if it was a bad thing. I don't see the relationship... how do you make such a leap? > Where do you think "off-the-shelf" stuff comes from? I worked on proprietary projects that eventually went public domain. So, I can tell you where off-the-shelf comes from from personal experience. Proprietary in-house tools have the benefit of not having to deal with many things that an off-the-shelf tool would have to deal because they can choose the kind of hardware to run on, the kind of supporting libraries, their versions and combinations to use, the kind of developer tools to support and so on. off-the-shelf tools, in order to be successful must cover a much wider area of ecosystem in order to be relevant. Here to give you a better example: C doesn't have its own concurrency primitives, no concurrency model etc. But, you could build an extension, let's call it CC to have some sort of concurrency based on pthreads library. If, for your internal needs, you only use CC on Linux -- you are golden and everything works fine. Once you try to make CC into off-the-shelf product you have to do something about pthreads missing from other platforms. Off-the-shelf products are typically born as in-house products, but they need an extra step to become what their name implies. In the specific case of what OP described as their own extension to C, I can vividly imagine a language that doesn't cut it as an off-the-shelf one. Making an off-the-shelf language would've also guided OP to a much larger departure from C because memory safety is only one of the big problems with the language. And this is what happened to a bunch of other languages which already walked a big chunk of that departure journey. This is why I would've been frustrated having to use the language like OP's: it would've felt like not enough change and too much headache to adjust to my target environment than could be had by using actual off-the-shelf languages. > You're showing a tremendously naive and misguided belief that libraries are somehow bad. I have no idea where you get this from. If anything, I say the exact opposite...
deleted 4y ago
[deleted]
esjeon 4y ago
> My favorite C code is the one that has no macros, as few of typedefs as possible, no acrobatics with alloca() or any platform-dependent stuff. You've just outlined a perfectly good subset of C. I'm pretty sure people who write C extensively even to this date mostly end up there. The beauty of using C these days is that one gets to control every single byte without going through hoops and loops. Also, any C code can be reliably integrated into other languages using FFI, which is quite universal. So, yeah, no need to create dirty hacks.
- nayuki 4y ago
  > The beauty of using C these days is that one gets to control every single byte No, not even close: Struct padding, compiling switch as if-else vs. jump, implicit arithmetic promotion to int, stack layout of local variables, and many other issues. If you want to control every byte, write in assembly language.
  - chrchang523 4y ago
    Nit: struct padding and arithmetic promotion don't support this point. In practice, C compilers provide struct-packing extensions that cover the uncommon cases where default padding wouldn't yield the layout you want. And they'll let you opt-in to a style where arithmetic promotions are forced to be explicit as they are in e.g. Go. So it would usually be ridiculous to drop down to assembly for either of these reasons today.
sacnoradhq 4y ago
C++ is the F-35. Much touted. Expensive to maintain. Expensive to get rid of. Doesn't quite live up to the hype. Borland C++ and Visual C++: never the two shall meet. They might as well been entirely different languages.
- thesuperbigfrog 4y ago
  >> C++ is the F-35. Much touted. Expensive to maintain. Expensive to get rid of. Doesn't quite live up to the hype. Quite literally. The F-35 software is C++ code: https://www.stroustrup.com/JSF-AV-rules.pdf https://www.stroustrup.com/JSF-AV-rules.pdf
  - pjmlp 4y ago
    Given all software problems that plagued F-35 during all its development, including mid-flight avionics reboots, I don't think Bjarne Stroustroup actually realizes that it isn't a good idea to advertise it.
    - SubjectToChange 4y ago
      Name a better plane. The F-35 is a great plane and its export success reflects that.
avgcorrection 4y ago
In either case it doesn’t matter: - It’s their subjective opinion (the author makes that clear) - The author works alone So there’s no risk that one would have to work with this dialect.
gavinhoward 4y ago
Author here. Don't worry; I do not accept outside contributions, so this code will not be imposed on anybody but myself. But it works for me. It fits my brain really well.

woodruffw 4y ago

Well put. Another way to think about it: every major OS and systems vendor has had some custom “safe” C variant over the years, to empirically mediocre results. It's unlikely that this author has done better; it’s much more likely they simply haven’t received the same scrutiny.

gavinhoward 4y ago
Author here. I know this. The only reason the custom stuff works for me is because it works for me. I accept no outside contributions, and this is one reason why.

simplotek 4y ago

> (...) big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library. It sounds like you're talking about using libraries as if it was a bad thing. > had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff (...) Where do you think "off-the-shelf" stuff comes from? It sounds like you're trying to mistepresent the adoption of subjectively sub-optimal libraries as somehow the issue caused by using libraries and frameworks. > mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that. You're showing a tremendously naive and misguided belief that libraries are somehow bad. Languages such as Rust flourish with the adoption of third party libraries,some of them euphemistically described as "not stable". Languages such as C++ flourish with third-party components like Boost and POCO. But applying the same principle to a language like C warrants an automatic and mindless putdown like blindly accusing anything of being bad? It makes no sense.

davisoneee 4y ago
A more generous interpretation would be that if you have a communal library, rather than everyone having their own individual libraries, it's easier to vet it for correctness. Rust takes the communal approach. The parent was suggesting that every company has an insular library approach. NIH. Many people that go off the beaten track often fall into the same ditch.
- menaerus 4y ago
  Correctness yes but what about other requirements people have such as performance, extended functionality, domain-specific optimizations, predictability, etc. Third-party libraries were not born out of the thin air but because of different parties having different and very much often disjoint requirements so it's not particularly NIH syndrome.
d0mine 4y ago
There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that).
- simplotek 4y ago
  > There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that) You're somehow trying to imply that libraries are not reusable if they are not widely shared, which makes no sense at all. The best argument you could make is regarding stability, but you simply cannot lay any such claim just from the library's licensing. Accusing internal libraries of being half-baked, badly designed, or bug-riddled is just a cheap blanket putdown.
crabbone 4y ago
> It sounds like you're talking about using libraries as if it was a bad thing. I don't see the relationship... how do you make such a leap? > Where do you think "off-the-shelf" stuff comes from? I worked on proprietary projects that eventually went public domain. So, I can tell you where off-the-shelf comes from from personal experience. Proprietary in-house tools have the benefit of not having to deal with many things that an off-the-shelf tool would have to deal because they can choose the kind of hardware to run on, the kind of supporting libraries, their versions and combinations to use, the kind of developer tools to support and so on. off-the-shelf tools, in order to be successful must cover a much wider area of ecosystem in order to be relevant. Here to give you a better example: C doesn't have its own concurrency primitives, no concurrency model etc. But, you could build an extension, let's call it CC to have some sort of concurrency based on pthreads library. If, for your internal needs, you only use CC on Linux -- you are golden and everything works fine. Once you try to make CC into off-the-shelf product you have to do something about pthreads missing from other platforms. Off-the-shelf products are typically born as in-house products, but they need an extra step to become what their name implies. In the specific case of what OP described as their own extension to C, I can vividly imagine a language that doesn't cut it as an off-the-shelf one. Making an off-the-shelf language would've also guided OP to a much larger departure from C because memory safety is only one of the big problems with the language. And this is what happened to a bunch of other languages which already walked a big chunk of that departure journey. This is why I would've been frustrated having to use the language like OP's: it would've felt like not enough change and too much headache to adjust to my target environment than could be had by using actual off-the-shelf languages. > You're showing a tremendously naive and misguided belief that libraries are somehow bad. I have no idea where you get this from. If anything, I say the exact opposite...

deleted 4y ago

[deleted]

esjeon 4y ago

> My favorite C code is the one that has no macros, as few of typedefs as possible, no acrobatics with alloca() or any platform-dependent stuff. You've just outlined a perfectly good subset of C. I'm pretty sure people who write C extensively even to this date mostly end up there. The beauty of using C these days is that one gets to control every single byte without going through hoops and loops. Also, any C code can be reliably integrated into other languages using FFI, which is quite universal. So, yeah, no need to create dirty hacks.

nayuki 4y ago
> The beauty of using C these days is that one gets to control every single byte No, not even close: Struct padding, compiling switch as if-else vs. jump, implicit arithmetic promotion to int, stack layout of local variables, and many other issues. If you want to control every byte, write in assembly language.
- chrchang523 4y ago
  Nit: struct padding and arithmetic promotion don't support this point. In practice, C compilers provide struct-packing extensions that cover the uncommon cases where default padding wouldn't yield the layout you want. And they'll let you opt-in to a style where arithmetic promotions are forced to be explicit as they are in e.g. Go. So it would usually be ridiculous to drop down to assembly for either of these reasons today.

sacnoradhq 4y ago

C++ is the F-35. Much touted. Expensive to maintain. Expensive to get rid of. Doesn't quite live up to the hype. Borland C++ and Visual C++: never the two shall meet. They might as well been entirely different languages.

thesuperbigfrog 4y ago
>> C++ is the F-35. Much touted. Expensive to maintain. Expensive to get rid of. Doesn't quite live up to the hype. Quite literally. The F-35 software is C++ code: https://www.stroustrup.com/JSF-AV-rules.pdf https://www.stroustrup.com/JSF-AV-rules.pdf
- pjmlp 4y ago
  Given all software problems that plagued F-35 during all its development, including mid-flight avionics reboots, I don't think Bjarne Stroustroup actually realizes that it isn't a good idea to advertise it.
  - SubjectToChange 4y ago
    Name a better plane. The F-35 is a great plane and its export success reflects that.

avgcorrection 4y ago

In either case it doesn’t matter: - It’s their subjective opinion (the author makes that clear) - The author works alone So there’s no risk that one would have to work with this dialect.

gavinhoward 4y ago

Author here. Don't worry; I do not accept outside contributions, so this code will not be imposed on anybody but myself. But it works for me. It fits my brain really well.