sbcl VS BQN

But sometimes, there are other incompatible licenses, even for open source software. Sometimes, even if you could build a derived work under GPL, nobody wants to maintain that fork when they could keep using a more-permissive one. So, for example, SBCL is under BSD and public domain licenses, so it doesn't link against Readline. Which makes it really unpleasant to use directly -- if you're used to REPLs from things like Ruby or Python, one where you can't even hit left-arrow while editing a line just seems stupid.

SBCL apparently *does* support cross-compilation of SBCL itself, if this https://github.com/sbcl/sbcl/tree/master/crossbuild-runner is what I think it is. I wonder how much that is used in practice...

Has an obvious answer? See https://github.com/sbcl/sbcl/graphs/contributors

If you like Lisp languages, Emacs is great, Steel Bank Common Lisp (SBCL) is great, Guile Scheme is great.

More information about SBCL is available at .

sbcl --dynamic-space-size 3072 --no-userinit --non-interactive --eval '(load #p"/home/bhaskar/Downloads/asdf-3.3.5/build/asdf.lisp")'/Downloads/asdf-3.3.5/build/asdf.lisp")' This is SBCL 2.1.4, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information.

You can go to https://github.com/sbcl/sbcl -> Actions -> Windows and enter e.g. branch:sbcl-2.2.0 into the "Filter workflow runs" textfield. This will lead you to https://github.com/sbcl/sbcl/actions/runs/1638267807. From there you can download a Windows installer for SBCL 2.2.0.

See e.g. CMUCL and its latter day fork SBCL, type inferencing native lisp compilers (which also had a lot of influence on the direction of various other Lisp and other language compilers).

The APL family of languages (I suggest BQN) can be written quite easily with pencil and paper.

The best solution for general problems of this kind would be an array processing language (BQN is my personal favorite). However, when it comes to games there are only a few of those with bindings in mainstream languages, and their use may not be straightforward.

If someone were to write a reddit post asking "what can BQN do that Haskell can't?" then one thing that I can say is that "while both are turing complete languages and one can implement anything the other can, in Haskell you have a very strong type system that bqn simply does. not. have, which allows for (a) self-documenting code, (b) easy refactoring, and (c) easy future proofing and debugging... meanwhile BQN allows for orders of magnitude more concise source code that is simply impossible in Haskell. You can write a program in bqn 15 lines that would take 200 in Haskell"

Stories please! What did the closures do to you?

Hopefully this won't be seen as too combative, but I feel like there are a few people in the array community giving me some pretty strong conclusions that they don't really have the experience to back up (Aaron wrote[0] 17 lines of array compiler, and says the low-abstraction approach he used is the only way to develop sustainably. Cool. I wrote[1] 350 lines of array compiler following his style, and I disagree[2]). At the same time, my experience only goes so far (there's no way I would have invented the array style compiler!), and clearly you arrived at these conclusions somehow. So is there a chance you'd share the observations that led you that way?

On my end, I was actually introduced to a little object-oriented programming in J when Henry suggested using it for a simulation project. I used it, but I don't think I really got it—just a weird way to organize data. And then in college I had to learn objects-only Java. Not good. But later I worked some with Node.js, and its module system was pretty nice: no name conflicts, easy to share code! Some way into BQN development, I figured out (with some help from a Common Lisp programmer) a way to add modules with an APL-y syntax, and something magic happened. I got objects[3] too! I think I've done about as much OOP in BQN as anywhere else, and I feel like I understand it a lot better now.

So, this is my experience with Lisp-family features and APL. Fits like a glove, programming is easier and more fun. I mix and match array, functional, and object-oriented styles however I want. Did I lose coherence? When I translate my old J code it comes out shorter and cleaner and without exec (".) everywhere. But I still don't get why I should want the language I use to not support mutability rather than just default to immutability. Did I fail to understand something in J when I had the chance?

[0] https://github.com/Co-dfns/Co-dfns

[1] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn

[2] https://mlochbaum.github.io/BQN/implementation/codfns.html

[3] https://mlochbaum.github.io/BQN/doc/oop.html

The array-handling characteristics of APL (or more recently BQN) can be ergonomically emulated in libraries, (usually with greater readability.) The higher-order functional programming characteristics of APL-languages are present in most modern high-performance languages, e.g. Rust, C++. Also things like Futhark exists.

BQN is too new for your criteria, but it's got more hype than any APL family language in recent memory. I'd be interested to see how it fares in a few years.

I used BQN for the solutions. I'm a general fan of array languages. Many BQN users were doing AoC, and the days which seem most similar have to be the ones where more builtins are common. BQN gives a small set of basic, powerful tools which can solve any problem, and raku is vast and sprawling with tons of convenient things to program with. The philosophies are quite different.

I've been enjoying programing in BQN recently, the documentation/error messages are better than other array languages I've tried. I think it helped me find different solutions to problems for advent of code this year that I wouldn't have seen when I had a similar problem in Rust/Python.

BQN