I think the main thing I want is a language which has full shell interactivity. I need to write programs to and from unix |, and most of what I do is reading streams/files/or sockets/REST
and these things seem like the least on the APL-like communities' list of priorities
or if they're pertinent, not really mentioned or emphasized anywhere
@nathanrogers dzaima/BQN does some of that. stdout works of course, command-line arguments are good, stdin might be kind of clunky. I don't think it does sockets but I never understood those.
well, I would say in python I interact directly with the shell. I call unix programs, execute other scripts, start processes, divert data flow from open streams in the environment
I mean in the most general sense, interacting with the operating environment
Regarding project organization, I think BQN is fairly strong (compared to ordinary languages: J and Dyalog are clearly miles worse). It uses namespaces to organize things, which is very clean. They're not well documented yet though. See Exports.
like can I unix pipe a program written in a given language to and from other pipes, can I write a program which orchestrates the operating system to monitor and manage all manner of these kinds of tasks
can I SSH to another environment and do the same thing there
and of course, REST, and elegant JSON/Dictionary literal syntax
@nathanrogers to include your program in a pipe, all you need is being able to read from stdin and write to stdout. dyalog can't do that. almost all programming languages can.
Yeah, ngn/k sounds pretty usable for what you want, if the lack of documentation isn't a problem for you. BQN doesn't have a dictionary type, and you probably shouldn't try to use namespaces to replace it. I've been thinking it should provide a dictionary class with a probably system-backed implementation, so it creates an object (namespace) that has functions like Set and Get exposed.
@nathanrogers just curious: do you ever need things like starting a process and read()-ing and write()-ing to its stdin stdout in small chunks? or is k's \ returning list of strings sufficient?
@dzaima Usually the reason you'd use a dictionary is for performance, and in that case you probably want it to be mutable. But I haven't though too much about the system-provided class idea and maybe there are other strategies that are better.
Obviously you can have a class that makes an immutable dictionary, but it could be hard to allow modifying that dictionary (to make a different dictionary) with good performance.
@rak1507 getting item ⍬ of a scalar currently always is equal to ⊃. That doesn't work if ⍬ is a valid map key. Solvable by enclosing the key as ngn said, but that's ugly
@rak1507 I think a lot of the reason for that is that existing array languages don't do objects well. It's starting to feel natural to me to write BQN code that mixes arrays and OOP.
It's not really that different from variables versus primitives. Generally the variables (including functions) are the important parts of the program that show what's being done where, while the primitives are glue that shuffles all the data around. There are more primitives than variables but they take up less weight in the program.
@rak1507 But why is mixing objects with array programming inherently bad? They shore up a lot of the weaknesses of the (particularly tacit) array style. They give you well-controlled access to mutability and help organize code.
I think they are a good fit but array programmers historically haven't understood how to use objects. Or closures for that matter.
@nathanrogers Once you're taking an argument to specify the format, which is presumably a string, I think it stops making sense to use a primitive, and it should be a system or library function.
@rak1507 Yes, I use a pure functional style for programs that work with a few large arrays. But why should an array language only be good for array programming?
I think the pithy lisp quip "better to have 100 functions for 1 data structure, than 10 functions for 10" is applicable here. writing functions that operate on a singular data representation is a strong approach. The strength of array languages is it makes this point all too obvious... the weakness of array languages is that there is no other way
But there's also the idea that functions are an antipattern because you can just directly interact with your data. so should you write functions, or whole programs instead... then it gets all kinds of abstract and nobody is having that conversation anyway
@rak1507 I don't think that applies here. Namespaces are a feature I added for structuring programs before I ever tried OOP with them. So BQN supports OOP with literally no design effort.
@Marshall I was responding to 'But why should an array language only be good for array programming?', to me the answer is 'because that's the only sane reason anyone would ever use one for'
@Marshall Why would anyone use BQN (or any other array language) over well established languages if not for a niche purpose best suited for array programming?
@rak1507 the alternative being what, never being able to use array-oriented programming in any of your code? (unless you're happy with mixing multiple languages together i guess)
@rak1507 BQN essentially embeds Lisp minus macros, so similar reasons apply. It's combinators are really nice as well. And nearly every program is going to use arrays a fair amount so having array operations is great even if you're not working with arrays exclusively.
@dzaima (if BQN didn't have such harsh restrictions on modifier characters, I'd definitely go for something equivalent in BQN. ((m⌸)x also reads key x from m))
@rak1507 I'm writing up a document on how you can use OOP in BQN; should be done in a few days. The in-progress Singeli compiler uses objects a lot; here is a stack class.
@nathanrogers yes, and more. ; is the universal separator. in () it separates list items. in [] it separates indices or arguments. in {} it separates statements.
also, it's equivalent to a newline
@nathanrogers @ is just the verb form of application. x@y ←→ x[y] ←→ x y
it seems that all the educational progress of the past... idk, century, has bred an entire generation of people incapable of articulating their thoughts. Brilliant!
and that isn't a dig, that's just an observation that, like "i hate math", "I can't write" has become almost... a humble-brag