The software industry, especially in the realm of free software, has mostly settled on a pattern of using C++ for creating performance critical libraries, and creating Python binding to the C++ libraries for scripting. I was hoping Rust might come along and change all this, but it will take decades.
In the mean time, if you want to use C++ but not actually write C++, you can make use of the ECL Common Lisp compiler, which can compile Lisp to C++ code. This gives you all the best features of Common Lisp for programming with the universe of C++ code libraries available to you. You can use a C++ library and still have Common Lisp macros, garbage collection, high-level scripting, S-expressions as serialization, domain specific languages, a proper meta-object protocol that wraps C++ classes nicely, and wealth of choices for functional programming systems from the untyped lambda calculus all the way up the lambda cube to System-F and the Calculus of Constructs. This not only makes ECL a viable alternative to Python for scripting and app development, but objectively better than Python since you can actually turn your Common Lisp scripts into code that gets compiled into a larger C++ application.
With ECL I would have all sorts of C++ libraries available to me:
game engines like Unreal and Godot
3D modeling: FreeCAD, OpenSCAD, Blender
Machine learning, big data, and HPC with PyTorch, TensorFlow, OpenCV, OpenCL
I will continue to contribute to the Scheme and Haskell communities as much as I can. I will continue to pursue my dream of an Xfce-like desktop environment written in Scheme. But no matter how I look at it, I am going to more productive in the long run using ECL and C++.
I was hoping that the software industry would gradually shift over to better, more functional languages like Rust and Haskell. And I would love it if Scheme languages could ever begin to seriously replace Python as a scripting language. But realistically, I think I am going to change tack and meet the industry half way. I think I should probably start using ECL as my language of choice, as much as I would prefer Scheme or an ML-family language like Haskell.
@ramin_hal9001 Have you tried CFFI's recent (and undocumented) C2FFI feature [1]? It can produce Common Lisp bindings automatically (using LLVM under the hood) for SBCL, ECL, CCL, etc.
Conversely, there's sbcl-librarian [2], which allows you to write dynamic libraries in SBCL that can be called from C, C++, etc.
@rwxrwxrwx@ramin_hal9001 this l looks great. idk if it will draw me to CL, but I'm interested in working on something similar for scheme, and this gives me something to mull of over.
@rwxrwxrwx Common Lisp is still pretty new to me, so I did not know about this CFFI. Thanks for letting me know! This will definitely make it easier for me to interface with various libraries.
I wonder if GCC can do something similar with libffi? I should look into that.
I never used seriously ECL and CLASP, but only started some session and read some documentation.
IRRC: ECL and CLASP are in worst case condition also 20x times slower than SBCL on some pure Common Lisp code; ECL functions can be called directly from C, because the ECL run-time is very C-friendly and with minimal or non-existent overhead; CLASP is doing the same but with C++, thanks to its integration with the LLVM compiler; interaction between SBCL and C code has always some overhead because the two run-times are very different; I don't know if this overhead of SBCL can be reduced if you interact mainly with vectors of fixed-size integers and similar data-structures, but if you have an API with a lot of calls, you had to pay a price.
BTW, it's impressive starting an ECL or CLASP environment, with all access to C/C++ code, but having a friendly REPL. Python is slower and it does not give this interactivity.
@ramin_hal9001 I've been meaning to do a post asking what the best C++ interop is beyond Python, thanks for this. As someone who works in C++ quite a bit for work, I recognize that most of "the fun stuff" (graphics) that is high level enough to create weekend projects remains in C++, but the FFI is a nightmare.
I've just started exploring Chez's FFI, which provides quite sophisticated tools for working with (any) foreign binaries, but I've only just started exploring it.
@rml Guile and Chez are both fantastic at binding to C code, but C++ always gets tricky due to name mangling, which is a result of constraints with the ELF file format not being able to encode types and overloaded functions.
I have yet to try ECL for anything more than simple experiments, but I think the fact that ECL binds to C++ at the source code level, and at the linker level, that makes it much easier to interoperate with C++ code.
Add comment