Every language should be faster* than C in some way otherwise no-one would use it.
Scripting languages are faster to code in.
Fortran is faster at complex matrix maths.
Lisp is faster to code in and faster to run for a large set of computing problems.
C wins the trade-of of speed-to-create vs speed-of-execution for most system programming tasks but usually when compared to bare assembly code. But there are a large number of problems that it is horribly unsuited for. Hence we end up with c-programs with accidentally embedded lisp implementations.
* - where faster can also mean faster to code to a secure standard.
Correct me if I am wrong, but somewhere I read that a while back, Lisp implementations caught up to and surpassed Fortran implementations in terms of math speed... suggesting that Fortran's main strength was finally outdone.
> Hence we end up with c-programs with accidentally embedded lisp implementations.
See Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
And of course the famous corollary: Including Common Lisp.
Scripting languages are faster to code in.
Fortran is faster at complex matrix maths.
Lisp is faster to code in and faster to run for a large set of computing problems.
C wins the trade-of of speed-to-create vs speed-of-execution for most system programming tasks but usually when compared to bare assembly code. But there are a large number of problems that it is horribly unsuited for. Hence we end up with c-programs with accidentally embedded lisp implementations.
* - where faster can also mean faster to code to a secure standard.