4 ms·

The thing is, you will never replace C. Supplement it, extend it, yes, but not replace it The fact is, C is still probably the lowest level HLL still used. It'

The thing is, you will never replace C. Supplement it, extend it, yes, but not replace it The fact is, C is still probably the lowest level HLL still used. It's the lowest level you can be, while still providing the HL constructs we're all used to. There is always going to be code that wants or needs to be there. Code where anything further up either can't give the performance, or provides impedance to the design or actual goal. You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D.

lifthrasiir 10y ago
> You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D. There are several examples of language implementations that are built directly from machine code incrementally. (In that case, the "bootstrap" happens via an already-built compiler of the previous version, or of the same version in the different architectures.) Also, you don't strictly need C for the bootstrapping compiler... Rust's one was OCaml for example.
- qwertyuiop924 10y ago
  And what's OCaml written in? How about the assembler? If you really want to replace C, You'll need to be able to compile the language without ever having C on your system (at least, in theory). This is almost impossible, although you can do it, if you slowly work towards it.
  - ajarmst 10y ago
    That's not really fair. If you go far enough back in the ancestral compiler list on any language, you'll probably hit C. You'll definitely hit hit assembly and bare-metal machine code. Heck, at some point you might run into hand wire-wrapped microcode---but I don't think that's an argument that we should be using it. That's just an artifact of the history of operating system development, and the fact that C spent (is spending) a considerable period as the de facto standard for OS development. That it was first doesn't necessarily make it better. A few events turning out differently in history, and you'd be making the exact same arguments about lisp, BCPL or Fortran.
    - nickpsecurity 10y ago
      It is a weak claim. You'd hit Pascal for a whole family of them with FreePascal well-maintained, fast, and portable. The Wirth ones vary language-by-language. There are BASIC's written in BASIC, LISP's in LISP (or 1940's machine code or microcode), silicon implementations of Java (eg JOP), Hyde's HLA assembly, IBM's PL/S that's still around, Amiga-E in M68K assembly, and Hansen's simpler Edison language in machine code or Pascal one. So, yeah, C wasn't at the bottom of all kinds of past and present developments, many more complex than C. It being at bottom of many current ones is social and economic, not a technical necessity. One could just as easily target FreePascal, a low-level VM w/out C's built-in preferences, or a HLA on a specific ISA.
      - qwertyuiop924 10y ago
        I know full well: my point was that you cannot depend on that which you wish to replace: Targeting something that doesn't is a valid approach for doing so.
        nickpsecurity 10y ago
        Care to elaborate? You can depend on what you want to replace for bootstrapping. You can use tools written in it, compiled with it, or even hand-converted to assembly for first run. That it was a stepping stone doesn't undermine an argument to replace it in general or even say much about it. The common flaw in reasoning is that "If C was used at any point, then C is technically good, essential, or something similar." It can come down to something as simple as author's convenience, personal preference, or even timetable. Using vs replacing a C compiler fits into all three I imagine. :)
        qwertyuiop924 10y ago
        Okay. Let's imagine Zig does replace C: 20 years from now, nobody uses C, except in a few specialized fields, same as FORTRAN. However, every time somebody has to recompile Zig, they have to go get a C compiler. Furthermore, most people don't know C any more than they know FORTRAN, making the compiler hard to contribute to. I'm not saying C is technically good, or essential, I'm saying that you cannot be dependant on something you want to get rid of, because then you can't get rid of it.
  - nickpsecurity 10y ago
    Sooooo easy compared to a C compiler... https://speakerdeck.com/nineties/creating-a-language-using-only-assembly-language https://speakerdeck.com/nineties/creating-a-language-using-o... More powerful, safe platform results as well. ;) http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf Another one for gradually building an ML which incidentally results in one of best languages for writing compilers, including Ocaml. You never need C so long as there's an assembler on source or target machine.
  - sanxiyn 10y ago
    If you want to be pedantic, Caml was bootstrapped from Lisp, not C. Quoting from http://caml.inria.fr/about/history.en.html http://caml.inria.fr/about/history.en.html "The first implementation of Caml appeared in 1987. This implementation compiled Caml down to LLM3, the virtual machine of the Le_Lisp system."
deleted 10y ago
[deleted]
nickpsecurity 10y ago
"but not replace it" I've long proven you can on a per project basis for both system apps non-C languages and C apps with better, C variants. "What will you write your bootstrapping compiler in? :-D." Any language better than C for writing a compiler, esp Ocaml w/ design-by-contract, compiling to target assembler. Worked wonders for Esterel's SCADE. Optionally, any such language transpiling to any other HLL on target system, including C w/ safety checks & no undef behavior. Working wonders for COGENT language team. Or go Wirth-style with a better-than-C (esp Component Pascal) to P-code compiler plus P-code interpreter for target hand-written in assembly. Simple backend + interpreter got Pascal/P on 70 architectures. Any are easier than a whole compiler for complex language (or C) in C using a C compiler. For doubters: https://embed.cs.utah.edu/csmith/ https://embed.cs.utah.edu/csmith/
- qwertyuiop924 10y ago
  Fair 'nuff on the compiler stuff. I was talking about replacing C globally, however, and that's not happening any more than we're replacing FORTRAN.
  - nickpsecurity 10y ago
    "I was talking about replacing C globally" I gave up on that when I noticed the COBOL and Windows situations. ;)
    - qwertyuiop924 10y ago
      Well, yeah, but that's what Zig seems to be trying to do. And as various tech comes up for replacement, it may one day be possible.
Joof 10y ago
I'll probably write it in Haskell or possibly ML. The Haskell compiler is written in Haskell, so there's nothing to C here. OTOH, I'm not sure if C needs replacing. It models state machines fairly well. Sure, we could use more systems languages like rust, but at best they replace C++ in some circumstances.
- spectral64 10y ago
  But isn't Haskell's runtime (RTS) written in C?
  - pjmlp 10y ago
    Nothing prevents it to be rewritten in Haskell. It wasn't been done just because no one cared to do it.
  - Joof 10y ago
    Hmm you may be right. I'd say rust, but LLVM is written in C (and writing a compiler in Ocaml or Haskell is so much nicer.) That leaves assembly and god knows what else in my repertoire. Not that it matters once it's bootstrapped though.
posterboy 10y ago
at hundreds of pages defining the standard, it's not low level at all, sadly. The apparent simplicity is deceiving at first, IMHO. Low level doesn't mean simple, but yet because of the desire for portability, it's rather abstract. It can't even check for a carry flag. It's not hard to imagine a language that could. Coming from microcontrollers, that is a huge disappointment. That is just the an example. Is there more?
- qwertyuiop924 10y ago
  It's lowlevel, that's why there's so much spec. And much of it is just defining that behaviour is implementation defined. And as I said, it's as lowlevel as an HLL can be. I wish we could check the carry flag. You could totally write a C library for that, I bet, by mixing in some asm, and using conditional compilation. Language extension!
  - versteegen 10y ago
    GCC since 5.0 and Clang since longer ago than that support (the same) set of builtin functions to check carry and overflow bits: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins http://clang.llvm.org/docs/LanguageExtensions.html#checked-a...
versteegen 10y ago
> It's the lowest level you can be, while still providing the HL constructs we're all used to. I disagree completely. A language much better than C will come along in its niche, and I'll be switching. C isn't low level enough. It has too much undefined behaviour (and tries to be too portable), each instance of which denies you access to real machine behaviour. Signed ints don't even wrap around! Effectively, C does not even support twos-complement signed integers, as exist on all modern computers since decades ago, without a special compiler flag! You have to resort to tonnes of compiler-specific extensions to get things like leading-zero-count, SIMD, and computed-goto. Even with GCC's zillion extensions that were added for people who have to do really low level work, C is still hopeless for writing maximum-performance VMs, that's why Mike Pall wrote the LuaJIT2 interpreters (one for each architecture) in assembly. Here's one of his explanations why C shouldn't be used for such a thing [1]. I've also tried writing a high performance interpreter in C, and I found that I wasted 80% of my time trying to get the C compiler to output the sequence of instructions I wanted. Next time, maybe I'll just use assembly and save myself a lot of trouble. Secondly, C is not high-level enough. A low level language like C needs a powerful macro system to let you abstract away the details of your object system or whatever. C's preprocessor has many flaws [2] and is one of the worst in existence. A good macro facility allows compile-time generation of code in a readable (or at least type safe) way, like D and Lisp do. C and C++ users don't realise they have the preprocessor equivalent of a Blub language [3]. Sure, C++ is an extension of C with high-level features, and was a good attempt, but it's too complex and C++'s template meta-programming just about the only compile-time codegen solution worse than C's preprocessor. [1] https://web.archive.org/web/20160209102431/http://article.gmane.org/gmane.comp.lang.lua.general/75426 https://web.archive.org/web/20160209102431/http://article.gm... [2] Read any rant, e.g. http://c2.com/cgi/wiki?CeePreprocessor http://c2.com/cgi/wiki?CeePreprocessor [3] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- qwertyuiop924 10y ago
  Yes, C's preprocessor is weak, but that's a quality of life thing, not a necessity by any stretch. And as for C not being low-level enough, that was my point - C is as low level as you can be, before you become unportable.
_ph_ 10y ago
You can bootstrap in any language that is widely available, so today that could be Javascript even. The biggest advantage of C as a language is, that a simple compiler is very easy to write. But I would bootstrap from Lisp (Scheme). A naive interpreter can be easily implemented in assembly and then you have a nice high level language for implementing the target system.

lifthrasiir 10y ago

> You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D. There are several examples of language implementations that are built directly from machine code incrementally. (In that case, the "bootstrap" happens via an already-built compiler of the previous version, or of the same version in the different architectures.) Also, you don't strictly need C for the bootstrapping compiler... Rust's one was OCaml for example.

qwertyuiop924 10y ago
And what's OCaml written in? How about the assembler? If you really want to replace C, You'll need to be able to compile the language without ever having C on your system (at least, in theory). This is almost impossible, although you can do it, if you slowly work towards it.
- ajarmst 10y ago
  That's not really fair. If you go far enough back in the ancestral compiler list on any language, you'll probably hit C. You'll definitely hit hit assembly and bare-metal machine code. Heck, at some point you might run into hand wire-wrapped microcode---but I don't think that's an argument that we should be using it. That's just an artifact of the history of operating system development, and the fact that C spent (is spending) a considerable period as the de facto standard for OS development. That it was first doesn't necessarily make it better. A few events turning out differently in history, and you'd be making the exact same arguments about lisp, BCPL or Fortran.
  - nickpsecurity 10y ago
    It is a weak claim. You'd hit Pascal for a whole family of them with FreePascal well-maintained, fast, and portable. The Wirth ones vary language-by-language. There are BASIC's written in BASIC, LISP's in LISP (or 1940's machine code or microcode), silicon implementations of Java (eg JOP), Hyde's HLA assembly, IBM's PL/S that's still around, Amiga-E in M68K assembly, and Hansen's simpler Edison language in machine code or Pascal one. So, yeah, C wasn't at the bottom of all kinds of past and present developments, many more complex than C. It being at bottom of many current ones is social and economic, not a technical necessity. One could just as easily target FreePascal, a low-level VM w/out C's built-in preferences, or a HLA on a specific ISA.
    - qwertyuiop924 10y ago
      I know full well: my point was that you cannot depend on that which you wish to replace: Targeting something that doesn't is a valid approach for doing so.
      - nickpsecurity 10y ago
        Care to elaborate? You can depend on what you want to replace for bootstrapping. You can use tools written in it, compiled with it, or even hand-converted to assembly for first run. That it was a stepping stone doesn't undermine an argument to replace it in general or even say much about it. The common flaw in reasoning is that "If C was used at any point, then C is technically good, essential, or something similar." It can come down to something as simple as author's convenience, personal preference, or even timetable. Using vs replacing a C compiler fits into all three I imagine. :)
        qwertyuiop924 10y ago
        Okay. Let's imagine Zig does replace C: 20 years from now, nobody uses C, except in a few specialized fields, same as FORTRAN. However, every time somebody has to recompile Zig, they have to go get a C compiler. Furthermore, most people don't know C any more than they know FORTRAN, making the compiler hard to contribute to. I'm not saying C is technically good, or essential, I'm saying that you cannot be dependant on something you want to get rid of, because then you can't get rid of it.
- nickpsecurity 10y ago
  Sooooo easy compared to a C compiler... https://speakerdeck.com/nineties/creating-a-language-using-only-assembly-language https://speakerdeck.com/nineties/creating-a-language-using-o... More powerful, safe platform results as well. ;) http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf Another one for gradually building an ML which incidentally results in one of best languages for writing compilers, including Ocaml. You never need C so long as there's an assembler on source or target machine.
- sanxiyn 10y ago
  If you want to be pedantic, Caml was bootstrapped from Lisp, not C. Quoting from http://caml.inria.fr/about/history.en.html http://caml.inria.fr/about/history.en.html "The first implementation of Caml appeared in 1987. This implementation compiled Caml down to LLM3, the virtual machine of the Le_Lisp system."

deleted 10y ago

[deleted]

nickpsecurity 10y ago

"but not replace it" I've long proven you can on a per project basis for both system apps non-C languages and C apps with better, C variants. "What will you write your bootstrapping compiler in? :-D." Any language better than C for writing a compiler, esp Ocaml w/ design-by-contract, compiling to target assembler. Worked wonders for Esterel's SCADE. Optionally, any such language transpiling to any other HLL on target system, including C w/ safety checks & no undef behavior. Working wonders for COGENT language team. Or go Wirth-style with a better-than-C (esp Component Pascal) to P-code compiler plus P-code interpreter for target hand-written in assembly. Simple backend + interpreter got Pascal/P on 70 architectures. Any are easier than a whole compiler for complex language (or C) in C using a C compiler. For doubters: https://embed.cs.utah.edu/csmith/ https://embed.cs.utah.edu/csmith/

qwertyuiop924 10y ago
Fair 'nuff on the compiler stuff. I was talking about replacing C globally, however, and that's not happening any more than we're replacing FORTRAN.
- nickpsecurity 10y ago
  "I was talking about replacing C globally" I gave up on that when I noticed the COBOL and Windows situations. ;)
  - qwertyuiop924 10y ago
    Well, yeah, but that's what Zig seems to be trying to do. And as various tech comes up for replacement, it may one day be possible.

Joof 10y ago

I'll probably write it in Haskell or possibly ML. The Haskell compiler is written in Haskell, so there's nothing to C here. OTOH, I'm not sure if C needs replacing. It models state machines fairly well. Sure, we could use more systems languages like rust, but at best they replace C++ in some circumstances.

spectral64 10y ago
But isn't Haskell's runtime (RTS) written in C?
- pjmlp 10y ago
  Nothing prevents it to be rewritten in Haskell. It wasn't been done just because no one cared to do it.
- Joof 10y ago
  Hmm you may be right. I'd say rust, but LLVM is written in C (and writing a compiler in Ocaml or Haskell is so much nicer.) That leaves assembly and god knows what else in my repertoire. Not that it matters once it's bootstrapped though.

posterboy 10y ago

at hundreds of pages defining the standard, it's not low level at all, sadly. The apparent simplicity is deceiving at first, IMHO. Low level doesn't mean simple, but yet because of the desire for portability, it's rather abstract. It can't even check for a carry flag. It's not hard to imagine a language that could. Coming from microcontrollers, that is a huge disappointment. That is just the an example. Is there more?

qwertyuiop924 10y ago
It's lowlevel, that's why there's so much spec. And much of it is just defining that behaviour is implementation defined. And as I said, it's as lowlevel as an HLL can be. I wish we could check the carry flag. You could totally write a C library for that, I bet, by mixing in some asm, and using conditional compilation. Language extension!
- versteegen 10y ago
  GCC since 5.0 and Clang since longer ago than that support (the same) set of builtin functions to check carry and overflow bits: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins http://clang.llvm.org/docs/LanguageExtensions.html#checked-a...

versteegen 10y ago

> It's the lowest level you can be, while still providing the HL constructs we're all used to. I disagree completely. A language much better than C will come along in its niche, and I'll be switching. C isn't low level enough. It has too much undefined behaviour (and tries to be too portable), each instance of which denies you access to real machine behaviour. Signed ints don't even wrap around! Effectively, C does not even support twos-complement signed integers, as exist on all modern computers since decades ago, without a special compiler flag! You have to resort to tonnes of compiler-specific extensions to get things like leading-zero-count, SIMD, and computed-goto. Even with GCC's zillion extensions that were added for people who have to do really low level work, C is still hopeless for writing maximum-performance VMs, that's why Mike Pall wrote the LuaJIT2 interpreters (one for each architecture) in assembly. Here's one of his explanations why C shouldn't be used for such a thing [1]. I've also tried writing a high performance interpreter in C, and I found that I wasted 80% of my time trying to get the C compiler to output the sequence of instructions I wanted. Next time, maybe I'll just use assembly and save myself a lot of trouble. Secondly, C is not high-level enough. A low level language like C needs a powerful macro system to let you abstract away the details of your object system or whatever. C's preprocessor has many flaws [2] and is one of the worst in existence. A good macro facility allows compile-time generation of code in a readable (or at least type safe) way, like D and Lisp do. C and C++ users don't realise they have the preprocessor equivalent of a Blub language [3]. Sure, C++ is an extension of C with high-level features, and was a good attempt, but it's too complex and C++'s template meta-programming just about the only compile-time codegen solution worse than C's preprocessor. [1] https://web.archive.org/web/20160209102431/http://article.gmane.org/gmane.comp.lang.lua.general/75426 https://web.archive.org/web/20160209102431/http://article.gm... [2] Read any rant, e.g. http://c2.com/cgi/wiki?CeePreprocessor http://c2.com/cgi/wiki?CeePreprocessor [3] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

qwertyuiop924 10y ago
Yes, C's preprocessor is weak, but that's a quality of life thing, not a necessity by any stretch. And as for C not being low-level enough, that was my point - C is as low level as you can be, before you become unportable.

_ph_ 10y ago

You can bootstrap in any language that is widely available, so today that could be Javascript even. The biggest advantage of C as a language is, that a simple compiler is very easy to write. But I would bootstrap from Lisp (Scheme). A naive interpreter can be easily implemented in assembly and then you have a nice high level language for implementing the target system.