I remember hearing that #Racket made some progress towards migrating to upstream #Chez, does anybody know what the status of that is? Racket users and users of software written in Racket would benefit immensely from this.
Chez is a powerful infrastructure in a ~500kb statically linked binary that approaches C in performance. Due to its low-level and bare bones compilation and build tools, you can also compile in only what you need. racket-minimal on #guix is ~160mb, which is great for what you get, but still 320x the size of Chez. Having Racket's ecosystem while being able to ship only chez + the compiled chez code of the libraries you import could allow for shipping sophisticate programs in only a few mb. Just saying.
while I think there is a lot of credibility to attributing #go's industry success due to the fact that its minimalism reduces ramp up for new team members while producing less complexity and more clarity/legibility, I think an under discussed factor at play is lines of code as a metric of success.
totally, minimalism at the language level enables innovation at the compiler level, and thus a rock solid infrastructure that does "one thing and does it well" ((cross)compiles a sufficiently expressive imperative language to lean fast static binaries). but if thats the reason to its success, then why isn't #chez just as successful? the obvious answer is that #go is backed by google, but so is #dart, which is successful soley due to flutter, and doesn't seem to really be adored anywhere, so it seems unsuccessful at the fandom level.
because like, what the hell is even going on there. it's a feature pile that most of its users seem to find annoying (including me, as I'm currently using it at work), but it has a powerful compiler infrastructure with native rendering capabilities that you can't find anywhere else. for this reason, I imagine projects targetting dart like #ClojureDart will start to take off, and dart will increasingly be a platform to target, similar to other successful JVM languages like clj & #kotlin (which is Google's official "first order" recommendation for Android dev today).
so I do think that go's success, as a language that its community really loves using, isnt just the solid infrastucture. I think its that it holistically captures a refined vision of the #unix philosophy that has includes insight from the longue duree of the innovations of plan9
@pfpoitras
they accomodate very different tastes; personally, Chez's repl is nearly perfect -- it can be used out-of-the-box without emacs and its still just as effective, due to its built in "expression editor" which Dybvig has refined since the 80s (theres a nice script containing the original from the 80s in the examples/ dir). SBCL you really need an editor + mode in my experience. then theres the debuggers. while I had a lot of fun with SBCL when I read the gigamonkeys book a few years ago, I really don't want a set of options popping up IN ALL CAPS whenever I err, but for a lot of people thats half the fun, and lack of that sort of system feels incomplete to them.
but Chez's debugger is just a whole other level. you can walk through every continuation of each frame on the stack, inspecting and mutating any value, down to the individual characters, fixnums, etc, all the way down to its binary representation if you so wish. Chez doesn't tell you what to do, or suggest what could be wrong, it instead seeks to expose you to as much possibility as possible, with a large set of tools to experiment with.
you can also create "new cafes", where you basically fork your current debugging environment to a new one for experimentation, and there no limit on how many to be jumping around. I've only scratched the surface tbh, but Chez's repl is one of the main things that has started drawing me away from Guile, and Guile's repl is my second favorite. but Guile is much easier to use; everything in #chez is much more advanced, as its whole philosophy is to expose modular components of features rather full fledged features.
for example, you don't just say "compile this file"; you have to program the compilation process yourself, saying use this run time, generate a boot sequence like this and then compile these programs for it, etc. which isn't as much work as it sounds, its just one of those things you have to learn how it all works. but that also makes it so you naturally think about novel places where you can run scheme. but you certainly have to be committed and already fairly versed in #scheme if you want to quickly become productive with it.
@rml as I already said, #chez uses Nanopass, that is a Scheme DSL where you specify: layers of intermediate code representations (IR); small and composable compilation pass on/between them.
Thanks to this approach, #chez source code is one of the shortest and more readable compilers on the planet, despite it produces very fast compiled code for Scheme that is a language difficult to compile in an efficient way.
#chez is a clear example that if you use the right paradigm (i.e. Nanopass DSL), then the problem became easier.
Its worth pointing out this great essay on #Chez's evolution from Dybvig. Probably the biggest takeway: optimize for the long term, choose your optimizations wisely, never try to squeeze out performance for short term gain.
did you ever wish you had the freedom to walk through every continuation involved in a function call as its transformed into various intermediate representations, with such fidelity that can you inspect the internals of any character in the process, and even mutate them and continue to run the program from a specific stack frame, dynamically at the repl? its very minimal and takes some learning to be effective with, but if that degree of introspection is your thing, what you want is #chez
just make sure to take the time to learn scheme pattern matching, which makes the language like quantum glue, and then I think you won't be so bothered by its lack of "features"
I just finished the first chapter of @d_christiansen's Functional Programming in #Lean, and I gotta say, theorem provers consistently win when it comes to pure fun. And Lean has been incredibly easy to dive into, find out where things are, and start... programming with, it really just feels like (or rather, is) another functional programming language, but with all the fanciness of dependent types.
on the topic of #Agda, I tried it a few winter holidays ago, reading Philip Wadler's PLFA, which is wonderful from the 1/3 I finished. it was a surreal experience compiling a book that proved the statements therein for 6 hours.
at some point after winter break, I switched distros, and never got around to recompiling the book, and so I never finished (I know I can just read the compiled version online, but I felt like reading the text from its literate agda files directly is a core part of the experience). I'll finish it one day, but I wonder if a #Chez backend would significantly reduce those compile times.
#lisp y #gopher show at 000UTC Wednesday (about 18 hours from now) on #aNONradio@SDF
lively chat will be as always in sdf.org #COMmode chat (I'll be in ~chat irc too)
Music this week will be from DJ Damaru's show (meditation + improvisational music), for people who haven't been catching the evolution revolution yet! https://archives.anonradio.net/#gef
I'm currently overworked and dealing with quasi-burnout (just a general feeling of exhaustion, but still functioning and enthusiastic), but once I'm feeling up to it I intend to dive into vulkan (I started a few months ago, but was derailed by gig work) with goal of implementing the REYES algorithm to start toying with the idea of an emacsen built with vulkan and #chez called μ-macs that replaces the traditional columns/rows divided buffer with the micropolygon subdivided plane, which can easily accommodate simple text buffers while also accommodating the rendering of any forms at any scale, seamlessly. If I want to hack my editor so that I can create click-and-drag arrows between code blocks in a plane with infinite zoom that also allows me to draw programmable vector graphic widgets, I should be able to; I want a meta-buffer that is as moldable in its contours as #lisp is in it's expressive capacities, and programmable graphical interfaces without a DOM. but I have to read #SDFF first, and also a vacation, which I haven't had in a couple years.
concerning the oft asked question "why would I choose a #scheme when there is #racket?" the obvious answer is that you need a scheme to start a racket, but a scheme can also become a conspiracy, which while a racket may aide, should it's ambitions grow, they will necessarily eventually resolve into conflict[0]. If what defines a hacker is a desire to hack with those who want to advance equality among users & hackers[1], a desire to conspire is immanent. The appeal of joining a racket is obvious[2], but those who chase their deepest desires acquire the highest valor[3].
--
[0] at which point you're likely to start getting into #chez[*]
[1] hackers
[2] while being called either a racketeer or a conspirator is bound to sound shady, I'll let you decide which sounds cooler
[3] if not often assuming the figure of the economically impoverished autistic legend
checking back in concerning attempt to do #sdff with #chez and the chez-mit library: I've discovered some bugs in (mit core), but I can't be bothered to debug and want to finally get started with this book without implementation distractions, so i'm just going to do the right thing and just use mit-#scheme
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!
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
For those who've put in the work and are utterly committed to the language, #crab seems like a good idea. For those who have had it with #rust, you should check out #chez, which will suffice for all but the most low-level needs (if you have the time, perhaps all of your low level needs), with comparable performance.
I think something the scheme community could learn from Haskell is to lean-in on it's prestige. I see so many people post about how they were never able to figure out how to use scheme in any practical way, and most schemers I've spoke to said it took them about a year to get really compfortable. But I think the #scheme community has traditionally advertised it as "so easy, you can learn it in an afternoon!", and so people, often times already coming from some other #lisp like #clojure, expect to be able to just pick it up, and when they fail to they think the language is lacking. But nobody comes to #Haskell with such expectations, and the Haskell community never advertised it as super easy and quick to learn. In my experience, Haskell has always been sold as "takes time to learn, but is worth it".
@otfrom sheer versatility. Clojure is pretty attached to the jvm in the sense that it's secondary implementations (cljs, cljr etc) tend to lose and gain platform-specific features afaict. So Clojure doesn't have near instant startup time, thus making it not fit for scripting (theres babashka, but afaik thats a subset of clojure in javascript). Also, the lack of tail-calls makes it very difficult to implement scheme's signature features (first class continuations etc) because you have to construct a trampoline, while most of Clojure's functionality is relatively easy to implement in Scheme. And Scheme has shown itself to be a better compilers platform than #Haskell, which i've heard described by it's advocates as "a programming language for authoring compilers". Scheme is even good for writing little kernels for your programs, it's incredible for co-routines and engines in general. So it's this massive range where it comes out top in it's class in so many fields (using #chez at least) which I think makes #scheme unique, special, and worth pursuing.
To be fair, I think Haskell will continue to fill the niche it filled ~10 years ago, around the time it started to get mainstream hype. Small teams of skilled devs delivering robust products that would normally require much larger teams to maintain will continue to prevail. Purely functional lazy programming was never bound for world domination in an economy which is antagnostic to curiosity, creativity and truths.
On the other hand, I have the feeling that we're going to see more and more Haskellers-turned-Rustaceans come to realize that #Rust does little to alleviate the primary barrier to Haskell's wider success -- fast and predictable turnaround time for projects developing cutting-edge technologies -- and will wind up going the same route as some major Haskell projects such as #Unison and #Idris have in recent years, which is to try #Chez Scheme, only to discover that it allows them to release blazing fast functional programs on a generic foundation where major breaking changes are practically non-existent, providing incredible flexibility while significantly reducing dependencies by dint of the ad-hoc tooling that falls out of the bottom of #scheme. Not to mention the joys that come from near-instant startup times, some of the fastest compile time you've ever encountered, fully-customizable interactive development and a surgical #debugger that rivals Haskell in scheer fun. Yesterdays naysayers will become tomorrow's enthusiastic bootstrappers. Or a at least a boy can dream.
That said, in all seriousness I don't think Scheme will ever reach the heights of Haskell's moderate commercial success. But I do think that projects built on Scheme, like Unison, will get a leg up and eventually surpass it, and interest in #lisp will only grow.
@nilmethod sbcl is generally faster than most schemes (but chez certainly gives it a run for its money), but #guile and #chez are incredibly fast in terms of start up and compile times. I read somewhere that chez bootstraps #idris in about 2 minutes, for example (I think #haskell took over 20 minutes when it was the implementation language).