3 ms·

It's a high performance, portable, systems programming, with a huge history. That's why people still use it. I'd argue most programmers today don't need to prog

by jryan49 11y ago

It's a high performance, portable, systems programming, with a huge history. That's why people still use it. I'd argue most programmers today don't need to program in such a language.

nickpsecurity 11y ago
Also known as the legacy effect. Like COBOL, the cost to rewrite, retrain, retool and so on for new language is too high to be worth it. There's also a certain mindset the new thing would have to be compatible with that's somewhat unique to C. Even C-like languages such as Cyclone couldn't break past that.
- RodgerTheGreat 11y ago
  I like the term "platform nepotism" to describe the fact that in Unix, C has special treatment from the perspective of APIs and ABIs. If you want to interact with the kernel or standard system libraries you must use a C-style calling convention against routines designed with the C type system in mind. Any other language must pay the cost of closing that gap, whether the cost is paid in extra tooling, clumsy rearrangement of activation records, typecasts, loss of type safety, using a restricted subset of normal language features, etc. A vast selection of libraries for most platforms impose similar bottlenecks. Unless you're willing to uproot an immense pre-existing platform, C will always have an upper hand. Reinventing all those wheels will take a long time, so it's good to see that there are a few efforts already underway.
  - nickpsecurity 11y ago
    Very, very well-said. There is no out when one is locked into broken architecture. Any escape comes at a cost.
    - jryan49 11y ago
      I wouldn't call it "broken". The tools we have today will be "broken" by tomorrow's standards as well.
      - nickpsecurity 11y ago
        Not necessarily the same. I didn't call the Oberon System broken because it had a sane CPU, problem areas hidden behind good interfaces, whole system in safer language, and thorough documentation of every aspect. Whether I like it or not for my needs, I wouldn't call that a broken system in any way. C is so poorly designed [1] that we're just now getting formal semantics, reliable analysis, and CPU's that handle it safely. UNIX ecosystem is similarly broken [2] [3]. Intel CPU's have all kinds of legacy holdovers, bugs, over-privileged components, and complexity in general. So, calling the current stacks broken by design makes sense without any implications for future stacks that might be better or worse. Want to have one that's better? Just make a sensible design, document it well, aim for simplicity where possible, keep it efficient, ensure its safe in normal operation, and give it good interfaces for extension/maintenance. Those tend to lead to better designs or implementations. The crap we use today largely evolved due to social and market forces, not good technical reasons. [1] http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG [2] https://queue.acm.org/detail.cfm?id=2349257 https://queue.acm.org/detail.cfm?id=2349257 [3] http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.de...

by jryan49 11y ago

It's a high performance, portable, systems programming, with a huge history. That's why people still use it. I'd argue most programmers today don't need to program in such a language.

nickpsecurity 11y ago

Also known as the legacy effect. Like COBOL, the cost to rewrite, retrain, retool and so on for new language is too high to be worth it. There's also a certain mindset the new thing would have to be compatible with that's somewhat unique to C. Even C-like languages such as Cyclone couldn't break past that.

RodgerTheGreat 11y ago
I like the term "platform nepotism" to describe the fact that in Unix, C has special treatment from the perspective of APIs and ABIs. If you want to interact with the kernel or standard system libraries you must use a C-style calling convention against routines designed with the C type system in mind. Any other language must pay the cost of closing that gap, whether the cost is paid in extra tooling, clumsy rearrangement of activation records, typecasts, loss of type safety, using a restricted subset of normal language features, etc. A vast selection of libraries for most platforms impose similar bottlenecks. Unless you're willing to uproot an immense pre-existing platform, C will always have an upper hand. Reinventing all those wheels will take a long time, so it's good to see that there are a few efforts already underway.
- nickpsecurity 11y ago
  Very, very well-said. There is no out when one is locked into broken architecture. Any escape comes at a cost.
  - jryan49 11y ago
    I wouldn't call it "broken". The tools we have today will be "broken" by tomorrow's standards as well.
    - nickpsecurity 11y ago
      Not necessarily the same. I didn't call the Oberon System broken because it had a sane CPU, problem areas hidden behind good interfaces, whole system in safer language, and thorough documentation of every aspect. Whether I like it or not for my needs, I wouldn't call that a broken system in any way. C is so poorly designed [1] that we're just now getting formal semantics, reliable analysis, and CPU's that handle it safely. UNIX ecosystem is similarly broken [2] [3]. Intel CPU's have all kinds of legacy holdovers, bugs, over-privileged components, and complexity in general. So, calling the current stacks broken by design makes sense without any implications for future stacks that might be better or worse. Want to have one that's better? Just make a sensible design, document it well, aim for simplicity where possible, keep it efficient, ensure its safe in normal operation, and give it good interfaces for extension/maintenance. Those tend to lead to better designs or implementations. The crap we use today largely evolved due to social and market forces, not good technical reasons. [1] http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG [2] https://queue.acm.org/detail.cfm?id=2349257 https://queue.acm.org/detail.cfm?id=2349257 [3] http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.de...