@screwtape
I'm not sure what to make of this Lisp & C article, but it's at least somewhat interesting.
@dougmerritt @screwtape also assuming the worst case scenario in which CL was not good enough for producing the final product, in any case CL was good enough for an initial prototype of the idea (one of the selling point of CL) and moreover the C implementation and the KC3 language took advantage from some of the CL programming language idea.
BTW, PicoLisp followed the contrary path. The author wrote a simple but efficient interpreter, with fast C FFI, a builtin DBMS and an efficient management of external entities. And he used it in projects for his customers.
@screwtape
@screwtape Up to date, I used Racket, Guile and CL (SBCL). I never used PicoLisp and never ECL.
Lisp is the "lambda-calculus" of real-world programming languages, because there is nothing you can remove from it, but you can express nearly anything with it.
PicoLisp is like Lisp, but also with a minimally, useful and composable run-time: C friendly; GC friendly; DBMS and external entities friendly; OOP system like Self but not heavy as CLOS; etc.. In this sense, it is brilliant. When you really need very advanced features, you can use external data-structures, defined in C libraries.
CL is a full-batteries included, industry complete (live) system to use in production. Many features are implemented (or defined) using the core Lisp language, so it is still elegant enough. But it is not obviously a minimalistic language.
ECL is a CL, but with a run-time optimized for calling C functions. There is for sure some intersection with PicoLisp domain.
Probably, PicoLisp is an example that you can map the Lisp philosophy to the embedding/scripting world, in a elegant and charm way.
Instead, ECL is an example that you can compile CL to different type of run-times. So CL is a flexible language also from the point of view of the target run-time.
It is difficult to choose between ECL and PicoLisp. But I don't see a problem of fragmentation... (next post)
... I don't see a problem of fragmentation, because Lisp is born to be fragmented. Also assuming to use only ECL, there can be an ECL with a set of macro supporting the PicoLisp way, and this is still a fragmentation. Every CL DSL is a fragmentation.
PicoLisp specifies in details also its run-time, while in ECL there are less details. PicoLisp removed many features from an hypotetical CL implementation, both for simplifying the run-time, but also as design choice, for making more clear what to use as calls to the C-world. Every advanced data structure must be a C library. In ECL you can be tempted to use CL libraries, instead.
But the most important aspect: one of the problems of fragmentation, is code reuse. But in an embedded context, usually the majority of code reuse is in the called C functions. Not in the business rules specified using PicoLisp or ECL.
I don't. Picolisp has a lot of aspects to it that will turn people attached to Common Lisp features right off.
It feels closer to Forth than to Common Lisp.
I would feel less out of sorts moving to Interlisp than to Picolisp.
So as others have said, Lisp culture is already fragmented, and those that prefer Picolisp were probably already off doing their own thing away from Common Lisp.
@mzan
I definitely have some great picolisp friends.
Do you worry about even picolisp bifurcating lisp programming culture that has been somewhat continuously intact inside common lisp conforming implementations ? Why not use embeddable common lisp?
@dougmerritt