| 23 Sep 2023 |
 gandercrews#0 | could you elaborate? | 16:33:28 |
 zjcurtis#0 | Erlang is primarily cool because of the virtual machine it runs on. Which mostly is supervision + green threads + scheduling. Soooo, maybe it's easier to make CBQN like that, than it is to adapt BEAM/OTP to BQN | 16:34:22 |
| gandercrews#0 | i am not a BEAM expert, but I'm not sure how feasible that is. I'm sure you could get some similar features into cbqn if theyre also a priority for dzaima, but a message oriented, soft-real time scheduler seems... an enormous undertaking.
there is also https://github.com/lunatic-solutions/lunatic, but last I checked it was limited to wasm32 and simd-128. | 16:37:59 |
| gandercrews#0 | the advantage of the port driver, is that there is a previous example (gen_q), that works, that is used in production. it would just take some time, energy, and asking questions on a few different mailing lists/chat groups. | 16:39:56 |
| zjcurtis#0 | Yeah I don't think it's a small task. | 16:42:34 |
| gandercrews#0 | I havent tried adapting minotaur to help compile rsbqn, if it vastly improved simd without a lot of developer work adapting rsbqn to run as a nif might be feasible (see also https://github.com/rusterlium/rustler/pull/232). however barring that I think cbqn as a port driver or port is far and away the path that would yield the best results with least amount of developer fragmentation or work. | 16:43:12 |
| gandercrews#0 | https://github.com/tessi/wasmex is something else to consider. | 16:44:36 |
| gandercrews#0 | * I havent tried adapting minotaur to help compile rsbqn, if it vastly improved simd without a lot of developer work, adapting rsbqn to run as a nif might be feasible (see also https://github.com/rusterlium/rustler/pull/232). however barring that I think cbqn as a port driver or port is far and away the path that would yield the best results with least amount of developer fragmentation or work. | 16:44:59 |
| gandercrews#0 | other weird things I considered, was using rsbqn as a nif to just generate erlang versions of bqn programs. it would be very difficult, and im not exactly sure how it would work, you would lose out on performance, but you would be able to run bqn programs on the BEAM. | 16:49:14 |
| gandercrews#0 | * other weird things I considered, was using rsbqn as a nif/build plugin to just generate erlang versions of bqn programs. it would be very difficult, and im not exactly sure how it would work, you would lose out on performance, but you would be able to run bqn programs on the BEAM. | 16:49:43 |
| gandercrews#0 | anyhoo gonna go for a walk. will be back on later, or just ping me on discord or matrix. | 16:50:52 |
| gandercrews#0 | also https://github.com/gordonguthrie/pometo was a previous attempt, it was started around the same time as BQN and I kept suggesting it be built around bqn and not apl, but oh well. I think some life things came up with Gordon. | 16:54:17 |
| gandercrews#0 | btw, rsbqn could be adapted as a nif, with gc, in an afternoon or two. if/when the scheduler improvements are merged it would also respect the scheduler. wont be nearly as fast, and message passing would take some more time, but it would be feasible. also not feature complete. | 17:05:00 |
|  zard03z#0 changed their profile picture. | 17:45:15 |
|  .jtacoma joined the room. | 19:48:39 |
| 24 Sep 2023 |
|  anlesvavor joined the room. | 01:43:39 |
 parker | anlesvavor i do hold the opinion that BQN is """better""" than APL because i personally find its syntax much easier to read | 01:55:21 |
| parker | but i will also admit APL has a ton of history and you can find more resources on it due to its 60 year head start | 01:56:16 |
| parker | this is all measured with the time proven, completely concrete measuring device called "my subjective opinion" | 01:57:19 |
 electronegative#0 | For what it's worth, I will offer my counter-opinion anlesvavor, to me BQN's symbols are less easy to remember because it tries to create conformity of shape depending on syntactic role (so all 2-modifiers are forced to be circles, for example, thus making each one of them less distinctive)
So it's a preference thing really, there are some things I like in BQN but others I don't | 01:57:46 |
| electronegative#0 | on the other hand, I love everything in my language, therefore it is the Perfect Language | 01:59:23 |
| anlesvavor | rak1507
depends what you want to do ¯\_(ツ)_/¯
Is there actual stuff in which one has clear advantage/tools than de other? The only thing that I've read from BQN is that it was designed so it "supports" FP as well | 01:59:37 |
| anlesvavor | Hmm, so what I bring home with me is that I definitely should taking a look at both | 02:01:42 |
 rak1507 | APL (or at least dyalog) has a lot more stuff in the language, both primitives and libraries/tools due to history | 02:01:46 |
| parker | i've had a good time with FP in BQN, but my opinion is extremely biased b/c i haven't learned any of the other languages | 02:01:46 |
| rak1507 | but you're right that BQN is better for FP | 02:02:03 |
| parker | i will also say that namespaces in BQN are so good | 02:02:23 |
| parker | i love them | 02:02:27 |
| rak1507 | BQN is more coherently designed imo but for me I like being able to quickly plot things or easily use regex (both of these might be in bqn now - it's evolving quickly) and stuff like that | 02:04:19 |
 miku.rb | im the same way regarding doing things quickly or easily, so APL or J is really easy in that regard. BQN is a little much to learn imo (maybe im just a noob), but upon spending a couple years with J, i still think its a worthwhile first array lang | 04:00:31 |
