array VS BQN

In some of the example programs written in KAP (my APL derivative), I tried to write it in a style that makes people unfamiliar with the array style more comfortable.

This code could of course have been written in a style similar to some of the more extreme examples, and they would have been significantly shorter in that case.

https://github.com/lokedhs/array/blob/master/demo/advent-of-...

This issue isn't directly related to BitSet. I have observed the same thing in my programming language interpreter that runs on the JVM (well, it's written in Kotlin multiplatform so it runs on JS and Natively as well).

I start the interpreter and measue the time it takes to all all then numbers below 1000000000.

The first time I run it after starting the interpreter it always takes 1.4 seconds (within 0.1 second precision). The second time I measure the time it takes 1.7, and for every invocation following that it takes 2 seconds.

If I stop the interpreter and try again, I get exactly the same result.

I have not been able to explain this behaviour. This is on OpenJDK 11 by the way.

If anyone wants to test this, just run the interpreter from here: https://github.com/lokedhs/array

To run the benchmark, type the following command in the UI:

    time:measureTime { +/⍳1000000000 }

I'm the opportunity to mention my project that implements a language that is inspired by, and is mostly compatible with APL. It has some major differences, such as being lazy evaluated and providing support for first-class functions.

It also supports defining syntax extensions which is used by the standard library to provide imperative syntax, which means you can mix traditional APL together with your familiar if/else statements, etc.

At this point there isn't much documentation, and the implementation isn't complete, so I'm not actually suggesting that people run out to try it unless they are really interested in APL. I just took this opportunity since APL is mentioned so rarely here.

https://github.com/lokedhs/array

There is an example of a graphical mandelbrot implementation in the demo directory, that may be interesting.

This post mirrors my feeling on this topic as well. Just like the author, I'm also working on a programming language which will not be used by a lot of people.

In fact, having a lot of users would make things complicated as I would have to stop making incompatible changes if I want to try something new.

Designing your own programming language is such a nice hobby, and something I believe a lot of programmers do. In fact, I would like to see links to other people's programming languages, just to see what people are playing around with at the moment.

Here is my project: https://github.com/lokedhs/array

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

Here is link number 1 - Previous text "BQN"