@dekkzz76 Adding some more notes: the project I've migrated from Go to Common Lisp resulted in 50% less code (not using any macros!).
Also, since I've developed it entirely in LispWorks, I did some tests with other implementations and it worked in SBCL and ECL out of the box (CLISP didn't work because bordeaux-threads doesn't support it).
Here are the runtimes:
SBCL:
Evaluation took:
9.755 seconds of real time 1.033166 seconds of total run time (0.968865 user, 0.064301 system)
[ Real times consist of 0.019 seconds GC time, and 9.736 seconds non-GC time. ]
[ Run times consist of 0.019 seconds GC time, and 1.015 seconds non-GC time. ]
10.59% CPU
144 lambdas converted
1 page fault 100,349,712 bytes consed
ECL:
real time : 83.908 secs
run time : 29.092 secs
gc count : 4 times
consed : 662005840 bytes
(sort of disappointing)
LispWorks: User time = 2.220
System time = 0.118
Elapsed time = 9.028
Allocation = 60406728 bytes
1620 Page faults
GC time = 0.009
It seems LispWorks is the clear winner in terms of runtime/memory usage.
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.
I run across the 1988 paper "Design and Implementation of the UW Illustrated Compiler" about an educational compiler, implemented in Interlisp-D, for a simple block structured language. The system took advantage of Interlisp-D's GUI and environment to visualize the compiler's scanning, parsing, and code generation features and state.
@amoroso I'm using #mcclim to visualize #ecl compilation steps. The tool is not anywhere near being usable for anyone but me, yet it gives a good insight at what's going on and helped me to spot a few type propagation bugs.
As far as I remember cleavir has more complete tooling for visual inspecting of the compiler state, but I don't know details of that tooling.
@alexshendi@SDF@silverwizard@nuintari
It would make my life easiest if we were to use
irc.tilde.chat #anonradio but I shall try and join irc.libera.chat since that is where the #McCLIM and #ecl and @jackdaniel are ! I got a bit behind on things this week sorry.
for the #lispyGopherShow - tune in in about two hours, or earlier to catch @northernlights both on sdf commode chat and bytes willing, #anonradio on irc.libera.chat !
#meta#lispyGopherShow ( #lisp#gopher#climate#sm0lnet )
Next week, in theme with #McCLIM and #ECL development I will also be hanging around #irc , both ~chat and liberachat. If anyone knows any good channels for the show chat to hang out in, please do tell.
#oldcomputerchallenge Day 4
More tests with SBC and - oh no! ... it's #lisp again (and #emacs). Another probe to learn, understand and use ... (why #python interpreter is more friendly for me than #lisp).
if you know C well, which I kinda do, @jackdaniel 's #ecl compiler is amazing. There's a special form #'ffi:c-progn that lets you interleave C and lisp code, sharing variables. Though new C functionality must be 'compile-file -d in.
Then he tried JSCL, a Common Lisp to JavaScript compiler that is implemented in Common Lisp and so it can bootstrap itself with any standard Common Lisp compiler.
I learned about a lot of Common Lisp on the Web technologies I had never heard of before, it was well worth it to read.
I just built and installed ECL #CommonLisp (hompage) onto my computer, and after playing around with it for only a few minutes, I am quite impressed with it!
First off, the entire installation is only 40 MB, so this is definitely one of the more compact Common Lisp implementations I have ever seen.
It emits C code, native shared libraries, native static libraries, and native executables.
It uses libffi for C interoperability.
It provides ASDF, and the ability to install packages from QuickLisp
It implements Lisp standard processes on top of Pthreads
It provides some bindings to Qt4 for GUI programming
It implements all of CLOS
All of that in just 40 MB (not including Qt, which you need to install separately). The only drawback so far is that the documentation has some gaps in it.
But I definitely want to play around with #ECL some more. The trouble is most Common Lisp packages written nowadays only support SBCL. I would like to see how much of the Common Lisp ecosystem I can actually use through ECL. I wonder if I could maybe port something like the Lem text editor over to ECL instead of building it with SBCL, but that might prove impossible.
Anyway, my overall impression right now is that I have a very lightweight but powerful Common Lisp compiler at my disposal now that can easily be embedded into any C program I want, which is very exciting!
@ramin_hal9001@louis@screwtape
fwiw I'm looking at the #guix#ECL installation rn, and running
$ guix shell ecl
[env]$ cd $GUIX_ENVIRONMENT/bin
[env]$ du -h ecl
4.0K ecl
thats extremely impressive. I don't know if thats because the ecl binary primarily calls libraries (perhaps for fine grain modularity), or if its actually that small.
fwiw, with all it's deps included:
[env]$ cd $GUIX_ENVIRONMENT
[env]$ du . -h
20K ./lib/pkgconfig
180K ./lib
48K ./include
24K ./share/info
24K ./share/doc
20K ./share/man/man3
24K ./share/man
76K ./share
8.0K ./etc
320K .
in comparison:
$ guix shell chez-scheme
[env]$ cd $GUIX_ENVIRONMENT/bin
[env]$ du -h scheme
308K #scheme
actually, I realized I wasn't in the main folder in the store, because I have ecl installed. so ecl is actually:
24K ./bin
8.0K ./etc
0 ./include/ecl/gc/private
0 ./include/ecl/gc
28K ./include/ecl/impl
360K ./include/ecl
360K ./include
920K ./lib/ecl-21.2.1/encodings
9.4M ./lib/ecl-21.2.1
13M ./lib
4.0K ./share/doc/ecl-21.2.1
4.0K ./share/doc
136K ./share/info
8.0K ./share/man/man1
8.0K ./share/man
148K ./share
14M .
But Chez was correct! So #Chez is actually much smaller than #ECL
TIL: every run of #SBCL has the same initial *random-state*, so sequences of pseudo-random numbers are not so random. The solution is super simple: (setf *random-state* (make-random-state t)).
It makes sense considering what a #Lisp image is... but it's still pretty surprising compared to other programming languages. (And doesn't happen in #ECL or #clisp 😅)