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".
@rml from my attempts to get into scheme, it’s never been the language itself that’s been a blocker, but the lack of modern libs, tooling and ecosystem. I don’t even mind spending time learning a language, and It’s admittedly been a while, but last time I tried to port an app of mine to scheme I had to compile C code to get TLS support in the HTTP client, and that’s about the last thing I’d like to spend time doing. I still like scheme, but I too wish I could use it for something practical.
@rml I appreciate that, although I’m currently too busy with other things (ie work 😅) to get back to scheme. For the next time I do though, I’d love to know about the best options for getting things done in 2023, including dialects, tooling, dependency management, development environment, documentation resources and libraries, and so on :)
@rml
If you were only interested in computers as a brute-force calculating tool, or interested only in the business side of software, you aren't interested in Lisp because it lost out to languages like Python, JavaScript, C/C++. So I think any Lisp will only attract people who are interested in lambda calculus and/or programming language theory, and/or maybe people interested in dependent typing, like anyone who has run across the work of Dan P. Friedman.
I assume it is not just me that the reason Scheme is appealing is because it is a well-designed minimal Lisp, and just being able to understand, from a pure computer science perspective, the implications of what a "well-designed, minimal Lisp" even means has already narrowed down the pool of potential converts to a tiny minority.
But the fragmentation is still the biggest problem. The absolute first question I had when I wanted to get started with Scheme was, "which implementation should I use?" And immediately it becomes clear that once you have picked one, it isn't easy to just switch your code over to some other implementation if you feel like the one you picked first is wrong. So there is soooo much pressure to pick the right implementation on your first try. That alone I think scares too many people away. I didn't run away because I was already committed to the idea mastering a "well-designed, minimal Lisp."
@ramin_hal9001 the thing is, I would say this is starting to change with r6 and #r7rs implementations, and #akku does a pretty job of working out the compatibility between different implementations (but the guix package needs some fixing... on my TODOs).
but I agree about the pressure to pick the right one, it drove me mad, but I also think that the idea that getting used to multiple schemes is impossible, and it should even be encouraged to work with a few of them, because once you've navigated a couple, they're all kind of the same at root. but I think people should stick to one for their first year.
it's primarily just the #r5rs implementations that differ wildly. I think theres this mythology that r5rs was this legendary, impeccable standard, and that the process went astray after that, but the truth is that #r6rs really was a massive improvement, and r7rs-large will be something like r6rs (creating an r7rs compatability later for r6rs schemes is a matter of defining a module and a few identifier-syntax macros). problems with post-r5rs are primarily social, rather than technical imo.
@svetlyak40wt@ramin_hal9001 I think chez gives SBCL a pretty solid run for it's money in terms of speed these days. and I'd say guile is about on par with SBCL in terms of features. but yeah, the Common Lisp ecosystem is magical.
> Lisp will only attract people who are interested in lambda calculus and/or programming language theory, and/or maybe people interested in dependent typing
I use Lisp because it offers me computing freedom unlike anything else. I don't care about lambda calculus or programming theory. It'd be nice to have better support for dependent types but it's not crucial.
26% of my system packages are Lisp (mostly Emacs Lisp), and I wish it was 100%. This 0.26 number will certainly increase.
I use Lisp because it offers me computing freedom unlike anything else. I don't care about lambda calculus or programming theory.
26% of my system packages are Lisp (mostly Emacs Lisp), and I wish it was 100%.
I'll admit I was maybe over-generalizing and I didn't mean to exclude you or anyone who honestly appreciate the aesthetics or the pragmatic features of Lisp. But it does make me curious, when you say "computing freedom," what features of Lisp make it more liberating for you personally than some other more popular high-level language such as Python or JavaScript?I suppose you use #Guix OS with Shepherd? That is a good way to use Guile Scheme for a large portion of your operating system, in particular the package management and the init system. Then use Emacs on top of that and you have most of your day-to-day computing tasks covered by Lisp. You could probably also use the Nyxt browser, although the core of it is still WebKit, which is not Lisp.
@ramin_hal9001@rml
> what features of Lisp make it more liberating for you personally than some other more popular high-level language such as Python or JavaScript?
Lisp offers “Freedom 1” (“the freedom to study how the program works, and change it”) in its fullest. Any function definition is a single M-. away to study, and it can be changed at any time, instantly. OODA loop is as short as it gets. I'm sure Emacs users read and change the code of the program they are running more than any other social group in the world.
Patch the object system, alter the thing that defines local functions, extend the syntax that defines code transformers — all with immediate effects, of course — all that would probably beyond my hopes, had I settled with more popular languages. (And I had to do all the things I mentioned, due to bugs or missing features.) How about something less fancy, such as redefining a class? Looks like Python has problems even with that. This is extremely limiting.
> Then […] have most of your day-to-day computing tasks covered by Lisp.
Smartphone use aside, that's the case already. I have to run some daemons written in C, and the system depends somewhat heavily on Python and Perl but that's it. I just never leave Emacs, except when it crashes.
@akater@ramin_hal9001 out of curiosity, if youre trying to increasethe percentage of your lisp based software, and are a free software advocate, why not guix? Its like the emacs of Linux distros, and its one of the most interesting codebases I've ever been in.
@rml
Yes, I also recommend you try Guix OS, and it's "Shepherd" init system. But it definitely takes time to learn how to use it if you have never used Nix or Guix before.
@akater
Lisp offers “Freedom 1” (“the freedom to study how the program works, and change it”) in its fullest.
@ramin_hal9001@rml
> you might be referring to Lisp's "image based programming" model. This is where Lisp basically freezes itself when an exception is thrown, then you can make changes to the code and resume execution
Image-based, yes. Condition system has nothing to do with this. Functions can be recompiled without dealing with it.
Erlang is famous, yes. One active member of our local Emacs community uses Elixir and seems to enjoy it, and claims they even use macros fairly often. Maybe it would be possible and beneficial to have such concurrency in a Common Lisp implementation (or in Emacs) but I have enough life goals already. 🙂
@w96k@akater@ramin_hal9001 it's worth pointing out #LFE, lisp flavored Erlang, which might be the nicest Lisp 2 I've played with. Been meaning to find a project to do with it, been having some ideas for a kind of minimal + extensible #activitypub implementation where every user has a configuration file, but its still fuzzy.
My experiences with elixir have been pretty good. Its like python in the sense that you can figure out everything at the repl and can just jump into code and everything is obvious. And the beam is a great system. I have an old C++ programmer's allergy to the JVM, but the #beam is like a vintage spaceship from a more sophisticated age.
> like python in the sense that you can figure out everything at the repl
😏 Why would a Lisper consider a comparison with Python's “repl” as favorable?
My experience with Python boils down to a single script I wrote for a one-time use but when I see someone dealing with Python interactively, it certainly doesn't look as smooth compared to the workflow I'm used to. A fairly well-known exposition by mikelevins confirms this: https://lisp-journey.gitlab.io/blog/how-are-lisp-repls-different-from-python-or-ruby-repls/
@akater@ramin_hal9001@w96k while I agree that python repls don't really compare to lisp repls (but they do have basic `apropos' functionality), one thing I have to hand to python is that its dead simple figure out and navigate. I've had many python gigs in the past without ever attempting to "learn python", and everything seems to be exactly where you expect to find it. Thats partially due to the code-as-pseudocode philosophy, but mostly due to standardizing around the status quo. but still, I dont think anyone would honestly argue that onboarding developers to lisp projects is smoother than python projects. On the contrary, I think Lisp requires more mature developers for successful onboarding, much like haskell, and so lisp teams usually consist of a few people who actively carved out a niche.
@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.
@rml
I'm not currently programming, but when I was, it seemed to me that practical use of a language was mostly constrained by social structures within which one programmed; if your job/OSS hobby/school/whatever didn't currently use (for example) scheme, use came with costs like convincing coworkers to learn more in-depth scheme, having onboarding scripts for setting up working scheme environments, and so forth. Without those things, spending a year on in-depth knowledge is a waste.
@llewelly I mean, I think if you can grok scheme you can pick up other languages very quickly on the go. but yeah it's not a language for getting a job, but neither was haskell until around ~2015. but people who learned haskell I think generally fare well in their careers in the long term, because they get a deeper, more general perspective on how to compose software, and I think scheme is similar but the perspective tends more to building and composing tools in particular.
@rml agreed in part but #scheme is difficult to utilize in pragmatic contexts because implementations are so vast and disparate.
Because of that, it's difficult if not impossible to make tool chains and linters and idioms and ecosystems that aren't just for one scheme.
R7RS is only just getting around to bridging bits of R6RS back in, and even that is through the SRFI process, which is plagued by poor documentation practices that focus on standardization prose over e.g. how and when to use an API.
But I think this definitely makes a clear point. Scheme is simple enough to implement and learn in a weekend, but it's not easy in the slightest when you get into actually building something practical. And god help you if you want libraries for modern web stuff (auth, ORM, container management), you're definitely left with "build it myself."
Add comment