Dev experience and learning curves

It’s been a minute, but I’m back after having spent a bit of time trying to get started with Goblins to prototype some ideas I’ve discussed here.

Maybe it’s because I’m not (yet) intimately familiar with Goblins and how OCapN etc. work under the hood, so take this with a grain of salt, please: getting started with Guile and Goblins is not easy.

I say this as a person who has been developing professionally for 20+ years, knows the Lisp basics, runs Arch Linux as my daily driver, has an embarrassingly heavily customized Neovim/terminal setup, and has used Nix in the past to manage system level packages.

Going through the Goblins manual, I went through the initial steps to install Guile and guile-goblins. Guile is available on Arch, which was great! Goblins was not, so I considered my options (install via Guix or build from source) and went with Guix. I installed Guix while carefully reading its Arch wiki page to avoid borking my system with a new competing package manager.

Once Guix was installed and configured some 30-45 minutes later, it was time to install Goblins. So I ran guix pull and guix install guile-goblins and proceeded to wait for Guix to apparently download and install its entire universe. I don’t know how long it took, because I ended up walking away from my laptop to work on something else and coming back much later. I may have even had to run it more than once before it all succeeded. All the while, I’m wondering if I should have used guix shell and wrote a manifest to ensure I was setting up a well isolated dev environment. Or set up a Guix profile to keep things clean and organized. I don’t know. Guix is still new to me.

Then, because I didn’t particularly feel like learning Emacs after all that, I spent another couple hours trying and failing to set up Conjure in Neovim—which I’d previously set up to work with Python and Clojure without much pain—to properly communicate with a Guile REPL socket.

Anyway. That’s a decent bit of grumbling, for which I apologize. But the point is hopefully clear: if a person such as myself tried and mostly gave up before even getting through the Goblins tutorial, how does Spritely expect for these tools to gain decent adoption without an implementation in a language ecosystem that more developers are willing and able to use, and that enables some sense of productivity in, say, a couple hours that are not mostly spent just trying to install and run the core dependencies?

Are there limitations to the underlying concepts that make Lisp a necessary choice? If so, are there other, more common (heh) Lisp variants that have a lower barrier to entry? Or can the concepts be eventually implemented in a language like Python, JavaScript, Go or Rust but I’m just here a few years too early to see that on the horizon?

Forgive the rant; hopefully y’all still see the underlying concern and can talk me down with logic and some missing context. :black_heart:

Hi @winds0rhum,

Sorry for the delayed reply. Thanks for the feedback! We generally agree that the experience could be easier! We’re working on it.

Regarding Linux distributions, we would like to see more distros packaging Goblins. For Arch, there’s a guile-goblins package in the AUR but it is quite out-of-date. Have you tried it? It would be great if an Arch user could upgrade it to the latest version! We like to use Guix for development here at Spritely, but we do not see it as a prerequisite for getting Goblins. Seems like that was the biggest source of pain in your report. You could also download a Goblins source release tarball and compile it from source manually, which would also avoid using Guix.

Regarding editors, it is true that the Lisp hacking experience outside of Emacs isn’t as good as it should be. This is because most Lisp developers like Emacs because it’s a Lisp system. I don’t have any specific recommendations for Vim, but our own Jessica Tallon recently released a VSCode extension for Scheme. We’d love to see more non-Emacs editor integrations that we can recommend to our potential users.

Overall, Spritely is still in the relatively early days of development. Our early adopters are people that are okay with some rough edges and ideally like Emacs. As our tech stack matures, our focus will shift more towards usability and tooling. We want to make it possible to learn Goblins by simply visiting an interactive web page and onboard from there, but we’re not there yet.

We get asked why we use Scheme and not a more mainstream language fairly often. The biggest reason is that Scheme is an excellent language for computer science research. We are a research institute, after all, and we want to propagate ideas just as much as we want to ship implementations of those ideas. Scheme provides many of the essential foundations for a secure computing environment, specifically lexical scope, first-class functions, and higher-order functions. The origin of Scheme was an exploration of the relationship between the Actor model and the Lambda calculus at MIT and it turns out it’s still good for this purpose! Furthermore, Scheme’s powerful macro system allows for experimental domain-specific programming language design without having to invent an entirely new language. Of the alternative languages you listed, JavaScript is the most suitable alternative but it’s not without it’s problems. Our friends over at Agoric use JavaScript for their capability security system and we’re slowly working towards our systems being interoperable via the Object Capability Network.

Hope this helps explain some things!

1 Like