Is it true that “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp?”
>>1
A dedicated C-based program will be much faster
in most cases, due better optimizations - however it will take much longer to write.
for example, this minikanren runs inside scheme;
If it was translated to C code parser, and that parser was
run vs a pure Scheme program the C parser will win on performance
and bugs will be caught by static analysis tools if desired.
The scheme program will be transpiled to C code with all the scheme
cruft/overhead since its automated, not hand-written.
https://github.com/webyrd/miniKanren-with-symbolic-constraints/blob/master/mk.scm
>>1
It depends on the domain:
1. High-level stuff will resemble
lisp or whatever domain its in(e.g. logic) superficially,
providing minimal functionality developed as throwaway code
to solve something specific and
being hard to debug(e.g. function pointers, nested macros) vs
high-level stuff that is meant to be extensible, generic and composable.
C API will not be pretty to use vs parsing LISP: it is however much
likely to be faster in its dedicated task.
2.Mid-level stuff will resemble object systems from C++/java/ada.
There will be equal or better functionality, but much buggier due
exposing low-level primitives. The flexibility and speed will be competitive
with mid-level languages.
3.Low-level C has no competitors and its what your high-level languages
compile to most of time.
Low-level stuff is easy to debug/optimize/refactor.
Its possible to make higher-level abstraction based on low-level
stuff, which entails creating a complex high-level system with all
the disadvantages of C in #1.
>>1
What if C programmers don't want to 'accidentally implement LISP'
but some specific subset of it, that is practically useful?
https://github.com/FrozenVoid/C-headers/blob/main/lambda.h
>>2
Even C's performance will suffer once you bring the level of abstraction up to the point where you can comfortably explore and solve problems across your whole problem domain.
I could write a fast sudoku solver in C, but its functionality would be only a fraction of a similar program in prolog.