5 ms·

> (...) 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

> (...) 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...

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...