A tree farm (at least the type that provide pulp for paper) is just a type of forest. Anyway, where I'm from, paper most definitely comes from forests (mostly second-growth) not anything you would call a "tree farm".
If you're implying all program languages are derived from C, that's simply false. Lisp is based on the lambda calculus and predates C, as one easy counter-example.
If you're implying that all languages run on top of C, that's also false. Theoretical Lisp Machines [0] have been envisioned which do not run C anywhere, and many languages (rust, go, etc) can be built into unikernals that run on real hardware with no C anywhere in the mix.
As far as I can tell, your statement is both pointless and wrong in even a generous interpretation of it.
Show me a lisp which is used by enough people to fill a conference in 2018 that isn't implemented in C. Show me a lisp machine which was manufactured any time in the past 10 years.
Steel Bank Common Lisp and Clozure Common Lisp are both implemented mostly in Lisp with some C code thrown in. And the European Lisp Symposium always has a large share of Common Lisp programmers.
CLOC tells me there's 28391 lines of C and 426525 lines of Lisp in there. Also remember that Lisp has, on average, higher code density than C thanks to advanced macro usage.
The runtime is written in C. That's the important bit. Just because the compiler, standard library, etc, isn't - doesn't mean it's not based on C. You cannot use SBCL without a C compiler.
The installation scripts are written in bash. That's the important bit. Just because the compiler, standard library, etc, isn't - doesn't mean it's not based on bash. You cannot use SBCL without a bash shell. /s
Of course you can use SBCL without a C compiler - you simply use a precompiled version. You can't build SBCL without a C compiler.
Shell scripts just slap commands together. You could just be a human interpreter reading the source and get the job done. C is a much more fundamental requirement of SBCL. Much more so than in the way SCBL depends on Python, for example (e.g. it doesn't).
Listen, I get that in the ivory tower of lisp you don't like looking at the little C bricks at the bottom, but the fact is that they exist and C is a hugely important language upon which the entire modern world of computing is built.
Sure, all of us execute stuff on kernels that are written in either C or C++ or C# or Objective-C, utilizing runtimes that are written in the same languages and calling APIs that are defined by the C application binary interface. That family of languages isn't going anywhere and choosing C instead of raw assembly is often chosen out of practical reasons, such as code maintainability.
Still, I find it hard to put an equality sign between "X has a runtime written in C" and "X is written in C".
The runtime for sbcl is just the garbage collector and parts of the OS interface. It's not like the JVM (or e.g. GNU clisp) where the runtime is interpreting code.
The OS interface for any program that is targeted at *nix is likely to be written at least partly in C, because POSIX is very hostile to non-C languages, which leaves us with the garbage collector.
If the GC's implementation language is the most important thing for an implementation then every language implemented mostly in C++, but using bdwgc for garbage collection is actually implemented in C and assembly.
This doesn't really sound sane to me. In this particular case, it would mean that if you throw away SBCL's compiler, SBCL's standard library, SBCL's extensions, and replace them with something completely different, you still get the same Lisp implementation because all of the aforementioned elements aren't a part of what you call the implementation.
The ones based on Java run on the JVM, which is always written in C :) The ones written in Lisp, well, at the bottom it's C again. I haven't seen a popular lisp yet with a meaningful amount of assembly in lieu of C.
I have some of these exotic Lisp Machines from the 80s which run no C code by default and where the C compiler is optional and written in Lisp. ;-) Obviously exotic and outdated. An alternate world.
> I haven't seen a popular lisp yet with a meaningful amount of assembly in lieu of C.
There are plenty to choose from, implement fully in Java like jikes, partially implemented in Java and C++ like OpenJDK, implemented in Java and C like MicroEJ, and lots of other ones to chose from.
Then there is project Metropolis on the OpenJDK, which targets to replace Hotspot with Graal, thus reducing the amount of C++ code on the runtime.
> Theoretical Lisp Machines [0] have been envisioned which do not run C anywhere
I have one at home. It's not theoretically, but factually. About 10000 Lisp Machines had been sold between the late 70s and early 90s. Which probably adds to $500+ million in sales - then.
They actually can run C, but that's usually optional.
Okay, I'll amend my position from "Everything is based on C", to "Everything is based on C except for a handful of LISP machines that nobody cares about but a handful of fundamentalists".
At which point someone who collects antique UNIVACs will tell me I'm wrong, too.
C is not the first programming language out there, you know. And for its first decade it wasn't even the most popular. There are still architectures in production and use that you'd struggle to find a conformant C compiler for.
It's really bizarre how you expect the world to revolve around it.
Point me to a compiler or interpreter, any of them, that isn't either written in C or written in something that was written in C. And of course, whatever you play with, it's running on an operating system written in C.
If programming is turtles all the way down, C is the bottom turtle, standing on the solid ground of Von Neumann architecture.
The point is, C is utterly pervasive. Everything that we think is different from C is made from C.
I'm also pretty sure that some are written in C++, whose implementations are usually also written in C++, and which (while closely related to C) is not C.
> And of course, whatever you play with, it's running on an operating system written in C.
That's obviously not the case if what you are playing with is an OS written in not-C. It's actually not entirely true in plenty of cases, because operating systems that use C range from almost-entirely C (with some assembly) to C-among-other-things (e.g., z/OS and it's mix of PL/X, HLASM, and C/C++.)
> If programming is turtles all the way down, C is the bottom turtle
I’m pretty sure the bottom turtle is native machine code and/or processor microcode.
I think the point that he is making is that most popular modern implementations of assemblers, Java compilers/JVM's, Ruby and Python interpreters are written in C, or in a language which itself was bootstrapped from C, eg. C++.
I guess the point is that the other languages are based on C. From your list CPython, CRuby and the GNU assembler are written in C. Not sure about Java.
Edit: not necessarily agreeing, there must be some languages that do not rely on C.
C++ is not C (it was once implemented as a preprocessor in front of a C compiler, but that's not th same as being C, and it's now more likely to implemented as a self-hosting compiler.)
