Lisp is inspiring at first glance, but when you need to solve complex problems like references, pointers, macros, byte-compilation and native compilation it just is not expressive enough like C, C++, or Rust. Neither is Javascript. Lisp could not replace all other languages
I seriously can't downvote your comment hard enough.
> references
Everything in Lisp is passed by copied references (when talking in C++ terms), so that's kind of a solved problem.
> pointers
You don't have raw pointers in CL since it's a memory-managed language, unless you're dealing with foreign code, and then there's support for handling these in a meaningful way (see CFFI).
> macros
Seriously? The CL macro system with quote-unquote and the full language being available has been good enough to be an inspiration for syntactic macro systems in multiple other languages, such as Rust or Elixir.
> byte-compilation
You only compile to bytecode if you cannot compile to native code. You can see it in implementations like ECL (if GCC is not present) and CLISP (if not built to use GNU Lightning).
> native compilation
SBCL and CCL and ECL and Clasp and LispWorks and ACL all do that, it's a solved problem. Or do you mean that writing compilers in Lisp is impossible since the language is not expressive enough, at which point you can see the source code for Lisp compilers which is frequently written in Lisp?
> Neither is Javascript.
That's the only part of your comment that I think makes any sense.
> Lisp could not replace all other languages.
Who even posed the statement that it should? Are you trolling?
This is entirely inaccurate and a fundamental misunderstanding of Lisp, both as a language and as an ecosystem. Have you seen [0], for example? It's how to leverage the native assembler of a Common Lisp compiler to build a small JIT-like compiler in Common Lisp.
Did you know Lisp has a disassembled built-in, with the standard library function DISASSEMBLE [1]?
Why would Lisp support these things like "native compilation" are supposedly out of scope?
Never mind that Lisp solved references, pointers, macros, byte-compilation and native compilation before the calendar flipped from 1969.
Lisp was compiled by around 1960.
Peter Landing, in 1964, presented the SECD machine, a kind of bytecode based on Lisp-like lists, directly usable for Lisp implementations, in "The Mechanical Evaluation of Expressions". Numerous Lisps have historically had some kind of "Lisp Assembly Language" (LAP) as an alternative or in addition to native compilation.
ZetaLisp, in 1981, the variant of MacLisp running on Lisp machines, featured locatives, which allow the address of a location to be passed around, for simulating reference parameters or members.
What do you mean? Many lisps have these features, in fact lisps in general are well-regarded for their macro systems. I don't think any programming language can replace all other languages but of all options, I feel lisps which allow you to safely and cleanly extend the language to better reflect the problem domain cast an unusually wide shadow.
I'm saying that it's hard to build a basic lego block with another lego block. You have to use plastic, heat and a mold.
That's why we have a wide range of programming languages at different levels, and why it's common for people to say "high level" or "low level" languages.
It's unclear to me what your suggesting, or what question your asking really.
