5 ms·

... as if all development of C stopped with the first ANSI standard? C99 and C11 are great languages. VLAs, anonymous structs, variable initializers, atomics..

... as if all development of C stopped with the first ANSI standard? C99 and C11 are great languages. VLAs, anonymous structs, variable initializers, atomics... they're not the C of the 80s and 90s. They still have the usual warts but the tooling is great and support is coming along for the newest features to most platforms. While the spirit of, "trust the programmer," might have been a historical accident there is some merit for its usefulness. Our chief problem as programmers is managing data: taking some source inputs, performing a transformation, and sending the output somewhere. That's true of video games, web applications, embedded sensors, etc. As a high-level language, C is one of the few that gives the programmer some control over how memory is mapped to the target platform and allows them to build the appropriate abstractions on that hardware. It's also a loaded weapon... humans make mistakes and inevitably those mistakes make it into our programs. When working in a language like C one must conduct ones self accordingly. I'm a fan of FP and ML-style languages. I'm looking forward to a day when we can have our cake and eat it too. It'd be nice to be able to define how memory should be handled for a particular application at the granularity of the target platform while still getting the safety guarantees. I like where Blow is going with his Jai language. It'd be neat to see more research in this area.

pcwalton 10y ago
> C99 and C11 are great languages. I think the amount of undefined behavior in C--and that undefined behavior is necessary to compensate for its design mistakes (e.g. signed overflow)--disqualifies it from being a "great language". Empirically, virtually every single large C program in existence depends on undefined behavior to continue working. And that UB is very difficult to spot [1]. > It'd be nice to be able to define how memory should be handled for a particular application at the granularity of the target platform while still getting the safety guarantees. > I like where Blow is going with his Jai language. It'd be neat to see more research in this area. You said that you wanted safety guarantees, but Jai is explicitly not about safety guarantees. In fact, being memory unsafe is one of the key design criteria behind the language. That's what differentiates it from for example Rust. [1]: https://news.ycombinator.com/item?id=11728324 https://news.ycombinator.com/item?id=11728324
- agentultra 10y ago
  I don't disagree wrt. UB. I've read somewhere that the reason C is so portable, despite not being designed that way, might be due to "underspecification." Regardless it's something one must be aware of. As for Jai, etc... right. I was conflating two things. Jai for keeping the spirit of C wrt "the programmer is in control." The other idea being FP languages with hardware-level capabilities.
  - catnaroek 10y ago
    > The other idea being FP languages with hardware-level capabilities. This won't happen until FP implementors work on bridging the gap between typed lambda calculi (ideal source languages) and the C machine model (ideal target machine). This needs: (0) A limited form of dependent types, tailored to express invariants of data structures, rather than arbitrary mathematical propositions. (1) Substructural types, so that use-once objects can be reclaimed eagerly and deterministically. (2) Designing abstractions so that their implementations have no overhead with respect to what a C programmer could have done manually. But FP people in general don't seem terribly interested in any of these. Instead they write compilers targeting JavaScript.
    - agentultra 10y ago
      With my limited experience in Agda I'm really excited about dependent types. I've been under the impression that there is some research in this area...
      - catnaroek 10y ago
        A language whose type level allows you to express arbitrary mathematical propositions can't possibly have as good inference as ML and Haskell have, because higher-order unification is known to be undecidable. Agda and Idris require manual type annotations for all let-bound identifiers. Coq requires all dependent pattern-matching blocks to be type-annotated. This is a real chore, and dependent types will never become mainstream unless their usability improves significantly. What I have in mind is one way to hopefully achieve that “significant usability improvement”: (0) Have dependent types, but restrict them to be first-order. This is good enough for programming purposes: invariants of data structures can almost always be expressed as first-order formulas. (1) Use known and proven type inference technology: generate a system of type-level equations, and solve them via first-order unification, which is known to be decidable and tractable in practice. But I don't see anyone in the FP community exploring this possibility.
vonmoltke 10y ago
> ... as if all development of C stopped with the first ANSI standard? For a significant portion of C developers and target platforms, it did. On my last program at my previous company I was required to use C89, in 2012, for portability reasons. The justification was political, not technical.
nickpsecurity 10y ago
"... as if all development of C stopped with the first ANSI standard?" The purpose of the text was to trace why the specific problems in C exist. Its proponents claimed all sorts of justifications and design tradeoffs. After digging through source papers, I found most of these were myths with two, real justifications: hardware constraints & personal preferences. What happened latter on in C didn't matter as core problems were due to the EDSAC, PDP-7, and PDP-11 hardware constraints plus personal tradeoffs of authors. The point is that (a) it wasn't actually designed that way for a good reason (just chopped due to constraints), (b) the possibly good justifications for chopping safety/maintenance no longer applied with better hardware, and (c) people should stop repeating misinformation that there was some grander reason they were there so we can adapt language to new constraints. We might get more improvements on C itself or alternatives as more C users understand there is no grand reason behind the root causes of problems: only due to constraints on hardware you can't buy any more. "They still have the usual warts but the tooling is great and support is coming along for the newest features to most platforms." C is bad at the foundation. Alternatives, esp variants on Wirth's stuff, was better within a decade or so. By then, people should be building on better foundations & improving C's. Some even did but little uptake over inertia & backward compatibility. Social & economic thing, not technical. "As a high-level language, C is one of the few that gives the programmer some control over how memory is mapped to the target platform and allows them to build the appropriate abstractions on that hardware." There's been safer alternatives that could do that at various points. I'll consider including them in a future version. " humans make mistakes and inevitably those mistakes make it into our programs. When working in a language like C one must conduct ones self accordingly." This is sort of a strawman that C proponents critically depend on. C makes many common operations unsafe by default where alternatives, esp like Modula-2, make it safer by default with ability to go UNSAFE if performance or low-level absolutely depend on it with that contained in a module. The reason these problems are in C language by default is nobody changed them. The reason they entered the language early on are the people who invented that philosophy & tech in BCPL had an EDSAC, next had a PDP-7, next had a PDP-11, and none of the three tried a safe subset of ALGOL like Hansen & Wirth did. Both of those built on PDP-11's. Hardware constraints, personal preferences, and not caring about safety/maintenance. That's it. Once you know this, there's no reason on modern hardware to do a clean-slate project in C if usable alternatives exist. Then someone mentions libraries or compilers. Many safe languages do a strong FFI for C or can compile to equivalent C code. So you still don't need C's problems at level you work with. Then someone mentions talent availability for C. The funny thing about that is that there's very little talent that can write robust, C apps esp under pressure of management to ship fast and including poorly-documented, 3rd-party libs. Only good counter-argument I've seen for using C was, ironically, in safety-critical from a NASA guy pointing out their people with years of C coding using a C subset w/ C testing rigs and four, static analyzers were collectively better bet than clean-slate language w/ less tooling on a project where absolutely everything has to be right. That was true but not the typical situation. ;) "It'd be nice to be able to define how memory should be handled for a particular application at the granularity of the target platform while still getting the safety guarantees." Stuff like that already exists and non-experts rewrote ext2 filesystem in it successfully: https://ts.data61.csiro.au/projects/TS/cogent.pml https://ts.data61.csiro.au/projects/TS/cogent.pml Currently using C as the output language given (a) compiler advantage as above and (b) they have the tooling to formally check it via that organizations' work on seL4 project. The part that verifies C is actually a simpler, formally-speced language/framework called Simpl that they embed C into. Myreen et al can go from specs to machine code directly with verified translation, which seL4 used IIRC. So, COGENT could probably go right to machine code via those without C at all. Outputing C is just very practical given their constraints and goals. I've always suggested modifying PreScheme to do what you said, though. It was a low-level, efficient Scheme meant as a C alternative which outputed C to leverage compilers & optimizations. It and Scheme48 were mathematically verified for correctness in VLISP project. One could add Oberon, SPARK or Rust style checks to PreScheme with ability to turn them off. Basic ones wouldn't be a lot of work at all given it's so small. https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme You might also find Habit interesting. It was designed by those behind the House operating system, a Haskell OS. They were designing a new language, Habit, that did things like bit control. They got poached onto a better project IIRC but published a bit on Habit: http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf So, there's you three, different approaches to the problem with functional/safe bent.

pcwalton 10y ago

> C99 and C11 are great languages. I think the amount of undefined behavior in C--and that undefined behavior is necessary to compensate for its design mistakes (e.g. signed overflow)--disqualifies it from being a "great language". Empirically, virtually every single large C program in existence depends on undefined behavior to continue working. And that UB is very difficult to spot [1]. > It'd be nice to be able to define how memory should be handled for a particular application at the granularity of the target platform while still getting the safety guarantees. > I like where Blow is going with his Jai language. It'd be neat to see more research in this area. You said that you wanted safety guarantees, but Jai is explicitly not about safety guarantees. In fact, being memory unsafe is one of the key design criteria behind the language. That's what differentiates it from for example Rust. [1]: https://news.ycombinator.com/item?id=11728324 https://news.ycombinator.com/item?id=11728324

agentultra 10y ago
I don't disagree wrt. UB. I've read somewhere that the reason C is so portable, despite not being designed that way, might be due to "underspecification." Regardless it's something one must be aware of. As for Jai, etc... right. I was conflating two things. Jai for keeping the spirit of C wrt "the programmer is in control." The other idea being FP languages with hardware-level capabilities.
- catnaroek 10y ago
  > The other idea being FP languages with hardware-level capabilities. This won't happen until FP implementors work on bridging the gap between typed lambda calculi (ideal source languages) and the C machine model (ideal target machine). This needs: (0) A limited form of dependent types, tailored to express invariants of data structures, rather than arbitrary mathematical propositions. (1) Substructural types, so that use-once objects can be reclaimed eagerly and deterministically. (2) Designing abstractions so that their implementations have no overhead with respect to what a C programmer could have done manually. But FP people in general don't seem terribly interested in any of these. Instead they write compilers targeting JavaScript.
  - agentultra 10y ago
    With my limited experience in Agda I'm really excited about dependent types. I've been under the impression that there is some research in this area...
    - catnaroek 10y ago
      A language whose type level allows you to express arbitrary mathematical propositions can't possibly have as good inference as ML and Haskell have, because higher-order unification is known to be undecidable. Agda and Idris require manual type annotations for all let-bound identifiers. Coq requires all dependent pattern-matching blocks to be type-annotated. This is a real chore, and dependent types will never become mainstream unless their usability improves significantly. What I have in mind is one way to hopefully achieve that “significant usability improvement”: (0) Have dependent types, but restrict them to be first-order. This is good enough for programming purposes: invariants of data structures can almost always be expressed as first-order formulas. (1) Use known and proven type inference technology: generate a system of type-level equations, and solve them via first-order unification, which is known to be decidable and tractable in practice. But I don't see anyone in the FP community exploring this possibility.

vonmoltke 10y ago

> ... as if all development of C stopped with the first ANSI standard? For a significant portion of C developers and target platforms, it did. On my last program at my previous company I was required to use C89, in 2012, for portability reasons. The justification was political, not technical.

nickpsecurity 10y ago

"... as if all development of C stopped with the first ANSI standard?" The purpose of the text was to trace why the specific problems in C exist. Its proponents claimed all sorts of justifications and design tradeoffs. After digging through source papers, I found most of these were myths with two, real justifications: hardware constraints & personal preferences. What happened latter on in C didn't matter as core problems were due to the EDSAC, PDP-7, and PDP-11 hardware constraints plus personal tradeoffs of authors. The point is that (a) it wasn't actually designed that way for a good reason (just chopped due to constraints), (b) the possibly good justifications for chopping safety/maintenance no longer applied with better hardware, and (c) people should stop repeating misinformation that there was some grander reason they were there so we can adapt language to new constraints. We might get more improvements on C itself or alternatives as more C users understand there is no grand reason behind the root causes of problems: only due to constraints on hardware you can't buy any more. "They still have the usual warts but the tooling is great and support is coming along for the newest features to most platforms." C is bad at the foundation. Alternatives, esp variants on Wirth's stuff, was better within a decade or so. By then, people should be building on better foundations & improving C's. Some even did but little uptake over inertia & backward compatibility. Social & economic thing, not technical. "As a high-level language, C is one of the few that gives the programmer some control over how memory is mapped to the target platform and allows them to build the appropriate abstractions on that hardware." There's been safer alternatives that could do that at various points. I'll consider including them in a future version. " humans make mistakes and inevitably those mistakes make it into our programs. When working in a language like C one must conduct ones self accordingly." This is sort of a strawman that C proponents critically depend on. C makes many common operations unsafe by default where alternatives, esp like Modula-2, make it safer by default with ability to go UNSAFE if performance or low-level absolutely depend on it with that contained in a module. The reason these problems are in C language by default is nobody changed them. The reason they entered the language early on are the people who invented that philosophy & tech in BCPL had an EDSAC, next had a PDP-7, next had a PDP-11, and none of the three tried a safe subset of ALGOL like Hansen & Wirth did. Both of those built on PDP-11's. Hardware constraints, personal preferences, and not caring about safety/maintenance. That's it. Once you know this, there's no reason on modern hardware to do a clean-slate project in C if usable alternatives exist. Then someone mentions libraries or compilers. Many safe languages do a strong FFI for C or can compile to equivalent C code. So you still don't need C's problems at level you work with. Then someone mentions talent availability for C. The funny thing about that is that there's very little talent that can write robust, C apps esp under pressure of management to ship fast and including poorly-documented, 3rd-party libs. Only good counter-argument I've seen for using C was, ironically, in safety-critical from a NASA guy pointing out their people with years of C coding using a C subset w/ C testing rigs and four, static analyzers were collectively better bet than clean-slate language w/ less tooling on a project where absolutely everything has to be right. That was true but not the typical situation. ;) "It'd be nice to be able to define how memory should be handled for a particular application at the granularity of the target platform while still getting the safety guarantees." Stuff like that already exists and non-experts rewrote ext2 filesystem in it successfully: https://ts.data61.csiro.au/projects/TS/cogent.pml https://ts.data61.csiro.au/projects/TS/cogent.pml Currently using C as the output language given (a) compiler advantage as above and (b) they have the tooling to formally check it via that organizations' work on seL4 project. The part that verifies C is actually a simpler, formally-speced language/framework called Simpl that they embed C into. Myreen et al can go from specs to machine code directly with verified translation, which seL4 used IIRC. So, COGENT could probably go right to machine code via those without C at all. Outputing C is just very practical given their constraints and goals. I've always suggested modifying PreScheme to do what you said, though. It was a low-level, efficient Scheme meant as a C alternative which outputed C to leverage compilers & optimizations. It and Scheme48 were mathematically verified for correctness in VLISP project. One could add Oberon, SPARK or Rust style checks to PreScheme with ability to turn them off. Basic ones wouldn't be a lot of work at all given it's so small. https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme You might also find Habit interesting. It was designed by those behind the House operating system, a Haskell OS. They were designing a new language, Habit, that did things like bit control. They got poached onto a better project IIRC but published a bit on Habit: http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf So, there's you three, different approaches to the problem with functional/safe bent.